Tại sao những phát hiện mức độ thấp lại nói nhiều hơn về cuộc kiểm toán của bạn so với các lỗi nghiêm trọng Nhiều công ty kiểm toán tập trung vào số lượng lỗi Nghiêm trọng được phát hiện như thể con số này không chỉ là tiếng ồn mà không có bối cảnh: các cuộc kiểm toán trước đó, đánh giá đồng nghiệp, mức độ bao phủ thử nghiệm, độ phức tạp của mã, số dòng và nhiều chỉ số khác. Đây là hình thức bán hàng thấp nhất, không khác gì so với việc so sánh chất lượng ổ USB chẳng hạn bằng chiều dài của nó tính bằng milimét. Để đưa ra một lựa chọn thay thế, trước tiên chúng ta phải khẳng định tính chính xác của một số tuyên bố hỗ trợ: - Xác suất tiêm lỗi ngẫu nhiên không có thiên lệch về tác động cao hơn (các nhà phát triển không liều lĩnh hơn trong mã có rủi ro cao, thường thì ngược lại). - Các phương pháp toàn diện giống nhau được sử dụng để phát hiện các lỗi có mức độ nghiêm trọng khác nhau cũng sẽ phát hiện các vấn đề nghiêm trọng (điều ngược lại không đúng). - Có yêu cầu cao hơn nhiều để một lỗi ngẫu nhiên đủ điều kiện là nghiêm trọng (thường nó sẽ bị rào cản bởi các điều kiện không thể đạt được, hoặc chạm vào chức năng không quan trọng). - Từ thống kê cơ bản: tỷ lệ lấy mẫu cao hơn tương quan với độ lệch/biến thiên kỳ vọng thấp hơn và do đó là một phép đo chính xác hơn. Hãy định nghĩa một báo cáo kiểm toán là kết quả của việc lấy mẫu chất lượng của một mã nguồn. Chúng ta suy luận rằng số lượng Nghiêm trọng thực tế (không bỏ sót) kỳ vọng là thấp hơn nhiều so với số lượng Thấp, và độ lệch kỳ vọng xung quanh nó cao hơn nhiều (do mẫu nhỏ hơn). Nói cách khác, số lượng Nghiêm trọng không cho chúng ta biết nhiều về số lượng Nghiêm trọng bị bỏ sót. Vì vậy, thật bất ngờ, một báo cáo 1 Nghiêm trọng, 10 Thấp lại đáng tin cậy hơn so với báo cáo 10 Nghiêm trọng, 1 Thấp khi mọi thứ khác đều bằng nhau. Mặc dù thực tế là phần lớn các nhân viên bán hàng sẽ thích hiển thị cái sau như một chỉ số về chất lượng. Điểm mấu chốt là một chỉ số tần suất cao là công cụ tốt hơn để đo lường các kết quả tần suất thấp. Các nhà xây dựng Web3, lần tới khi các công ty vẫy bạn số lượng Nghiêm trọng/Cao và X tỷ đô la được bảo đảm, bạn biết nơi nào để tập trung tìm kiếm tín hiệu thực sự. Các kiểm toán viên Web3, hãy nhận ra rằng không có công thức bí mật nhất quán nào để tìm tất cả các Nghiêm trọng mà không tìm kiếm các Thấp - mỗi Thấp không được điều tra đầy đủ là một Nghiêm trọng tiềm năng - và hãy dành sự chú ý tốt nhất của bạn cho từng dòng. Khách hàng của bạn sẽ cảm ơn bạn vì điều đó. Mức độ thấp được định nghĩa là những sai sót lập trình cụ thể không dẫn đến các tác động cấp cao hơn. Không bao gồm định dạng, thực hành tốt nhất và các phát hiện không cần thiết.

Một lỗ hổng nghiêm trọng trong git đã được phát hành ngày hôm qua, có thể bị kích hoạt khi git clone từ repo không đáng tin cậy. Đó là vector lý tưởng để xâm nhập vào các kiểm toán viên và đánh cắp tiền thưởng / tiền kiểm toán của họ. Hãy vá hệ thống của bạn trước khi báo giá cho bất kỳ khách hàng mới nào! Và hãy chuẩn bị cho những người ghé thăm trong hộp thư của bạn trong những tuần tới...

Hóa ra bạn có thể kiếm được phần thưởng 5 chữ số trong các cuộc thi mà không cần thực sự phát hiện ra bất kỳ vấn đề nào, chỉ cần một bộ não bán chức năng là đủ. Trong cuộc thi OP Fault Proofs tháng 3 năm 2024, các nhà phát triển đã sửa một vấn đề nghiêm trọng một ngày trước khi nó bắt đầu nhưng không hợp nhất nó vào. 🔗 Chỉ cần nhìn vào nhật ký cam kết công khai, bạn đã ghi điểm cao 🔗 🔗 Cuối cùng đã trở thành một phần thưởng $16680: Đây chỉ là một trong nhiều mẹo để tìm ra các lỗi trong phạm vi mà không cần thực sự tìm kiếm chúng. Luôn cố gắng làm việc thông minh, không phải chăm chỉ.

Quyết định thử Cantina vào tháng 10 năm ngoái, 8 tháng sau, kết quả cuối cùng cũng đã có... Hàng chục phát hiện cá nhân trong cuộc kiểm toán Java đầu tiên và vượt trội hơn các anh em trong bảng xếp hạng Cantina hàng đầu từ 3-7 lần cảm thấy khá tốt, không thể phủ nhận. Thật đáng tiếc là trải nghiệm sau kiểm toán lại tệ đến mức tôi đã thề sẽ không quay lại nền tảng đó. *cảnh báo về việc phàn nàn hợp lý* - Thời gian giải quyết 8 tháng, tính đến thời điểm viết - phần thưởng vẫn chưa được gửi. - Hàng chục giờ đã dành để kháng cáo và bảo vệ các bài nộp trước các phán quyết sai. - Đếm được ~ 104 sai sót trong việc đánh giá (trùng lặp sai, rõ ràng không hợp lệ, mức độ sai) đã được sửa. Còn nhiều cái chưa được sửa. - Mất giá trị khoảng ~$110,000 do việc giải quyết mất 7 tháng hơn so với dự kiến và token OP giảm xuống còn ~50 cent. Chắc chắn, khi tham gia vào các giải thưởng không phải USD, sự biến động là một rủi ro chấp nhận được. Nhưng 8 tháng với các giám khảo không đủ năng lực và không thể kết thúc một cuộc thi không nằm trong mô hình rủi ro của tôi. Trong những ngày đánh giá C4, tôi có thể xử lý 1000 phát hiện trong chưa đầy một tuần (một mình), OP-Java chỉ có 360 và nhiều giám khảo. Không có gì ngạc nhiên khi Cantina không công bố kết quả trên mạng xã hội, khác với 5 cuộc thi khác đã hoàn thành trong tuần này, chắc chắn không thể là trường hợp họ muốn tránh báo chí xấu hoặc làm nổi bật sự thống trị của TrustSec, đúng không? Thật đáng tiếc khi chúng ta phải tiếp tục thảo luận về các hành vi sai trái của nền tảng phần thưởng thay vì các lỗi nghiêm trọng, nhưng không còn lựa chọn nào khác ngoài việc giữ mọi người có trách nhiệm. Một bài viết phân tích kỹ thuật không phàn nàn cho các phát hiện cá nhân sẽ sớm được đăng tải.

Hãy tưởng tượng một thế giới mà việc nói rằng các nhà nghiên cứu không nên bị lạm dụng lại là một quan điểm gây tranh cãi.. Đó là điều xảy ra khi một công ty với nguồn tiền vô hạn xuất hiện và mua chuộc để chiếm ưu thế trên thị trường. Việc áp đặt các chính sách khai thác lên các nhà nghiên cứu đơn giản trở thành trạng thái Nash mới.

Mỗi ngày trôi qua, chúng tôi ngày càng nhận ra rằng @cantinaxyz là một thực thể khai thác và là một yếu tố tiêu cực đối với không gian này. Một tuần đã trôi qua kể từ khi bài viết xuất sắc của @jack__sanford về vô số thiếu sót của cuộc thi Cork và không có dấu hiệu nào về một phản hồi sớm. Với lượng chú ý mà bài viết đó nhận được, nếu họ có thể đưa ra một sự biện hộ, họ chắc chắn sẽ làm như vậy, tức là im lặng là một sự thừa nhận tội lỗi. Tuần này, đơn đề xuất thưởng Cantina của chúng tôi, mà họ đã đồng ý cho thấy một khoản lỗ vốn bị giới hạn cho một nhà điều hành blockchain với xác suất cao, đã được giải quyết trong hòa giải với mức độ thấp. Sau khi đọc hàng chục báo cáo Spearbit/Cantina và hàng trăm bản tóm tắt thưởng, khoản lỗ tiền tệ ở bất kỳ mức nào cũng không bao giờ dưới mức độ trung bình, vì vậy họ rõ ràng đang truyền đạt quan điểm của nhà tài trợ theo một tâm lý "khách hàng luôn đúng" như họ vẫn thường làm. Thực tế, họ thậm chí không che giấu việc này. Theo tài liệu của họ, họ mặc định theo Quan điểm của Khách hàng. Tôi đoán chỉ trong những trường hợp nghiêm trọng nhất họ mới từ chối quan điểm của khách hàng. Và nếu khách hàng đơn giản phớt lờ hòa giải của họ thì sao? Trên bất kỳ nền tảng nào khác (ví dụ: @immunefi) mà chúng tôi đã làm việc, việc không tôn trọng hòa giải là lý do để ngay lập tức loại bỏ khách hàng. Trên Cantina, khách hàng có quyền thực hiện 5 vụ lừa đảo thưởng mỗi năm. Vâng, bạn đọc đúng đấy. Chúng tôi cũng mới phát hiện rằng chương trình Fellowship của họ có một điều khoản độc quyền cực kỳ nghiêm ngặt. Các Fellow không thể nộp bất kỳ thứ gì cho các nền tảng thưởng khác, hoặc thông báo cho các dự án trực tiếp, ngay cả khi hàng triệu đô la đang gặp rủi ro. Thay vào đó, kiến thức nhạy cảm và quan trọng về thời gian này phải được chia sẻ với Cantina, người quyết định cách tiến hành. Họ là ông chủ, họ quyết định mọi thứ, hãy cúi đầu hoặc rời đi. Chúng tôi có nhiều ví dụ về cách xử lý thái quá trên Cantina, nhưng sẽ để lại cho một ngày khác. Hiện tại, chúng tôi muốn nâng cao nhận thức, giống như các thành viên cộng đồng hàng đầu khác, rằng các kiểm toán viên nên bỏ phiếu bằng chân của họ khi nói đến nơi họ dành thời gian quý báu để săn lùng. Một nền tảng bảo mật mất cân bằng và thiên vị các dự án hơn là các thợ săn thưởng sẽ làm suy yếu toàn bộ quy trình white-hat và khuyến khích các nhà nghiên cứu kiếm được giá trị của họ thông qua các phương tiện ít đạo đức hơn! Hãy cùng nhau làm việc như một cộng đồng để củng cố các tổ chức có tính toàn vẹn cao, minh bạch và tích cực hơn là những kẻ bắt nạt trong ngành.

- Giữ số dòng mã thay đổi trạng thái dưới 500 - Sử dụng mẫu ++counter cho các khóa ánh xạ - Không hỗ trợ token gốc - Giữ máy trạng thái ở chế độ mở thông qua các enum trạng thái - Tỷ lệ kiểm tra/số dòng mã là 1:1 - Định dạng mỗi dòng mã với một thước kẻ Xem này, thắng trò chơi không khó như vậy.

Là một người kỳ cựu trong ngành công nghiệp cuộc thi kiểm toán, tôi sẽ cho bạn biết cách các thỏa thuận như thế này được thực hiện. > Hãy tuân thủ quy trình với tiền bạc và thực hiện 3+ cuộc kiểm toán hợp tác > Biết rằng mã nguồn có lẽ không có lỗi nghiêm trọng > Muốn gửi tín hiệu đến cộng đồng, nhà đầu tư và các bên liên quan khác rằng bạn quan tâm đến bảo mật > Không có ý định chi thêm tiền cho bảo mật > Nền tảng "Cuộc thi" có giải pháp > Thiết lập một cuộc thi rug đảm bảo rằng các phần thưởng High/Crit sẽ không được mở khóa > Làm cho phần thưởng Med cực kỳ nhỏ > Nếu tìm thấy High thì giảm nhẹ sự nộp bài nếu không khách hàng sẽ không hài lòng (nhớ Euler?) > Cả nền tảng "Cuộc thi" và bạn đều được quảng bá miễn phí > SRs bị rug nhưng bạn không quan tâm > Lặp lại nhưng làm cho thông báo cuộc thi rug tiếp theo thậm chí còn lạc quan hơn.

Cảnh báo ⚠️: Không phải là một bài viết mới về tiền thưởng Chúng tôi, những kiểm toán viên, đều thích tập trung vào những lỗi nghiêm trọng và giữ công việc không liên quan đến kỹ thuật ở mức tối thiểu. Ai quan tâm đến giấy tờ và các cuộc họp khi bạn vừa tìm ra một cách mới để rút tiền từ hợp đồng DeFi? Nhưng mọi thứ nên được thực hiện một cách điều độ, và quá thường xuyên chúng tôi thấy các nhà nghiên cứu độc lập hoàn toàn bỏ qua việc ký kết thỏa thuận cơ bản với khách hàng. Đây là điều mà chúng tôi cũng đã làm trong những tháng đầu của TrustSec - kết nối với khách hàng trên TG / discord, thảo luận về đội ngũ, giá cả và thời gian, và chỉ cần bắt đầu. Cảm giác trơn tru và không có ma sát, vậy vấn đề là gì? Như với nhiều thứ, nó hoạt động tốt cho đến khi không còn nữa. Khi bạn quản lý hơn 50 cuộc kiểm toán mỗi năm, bạn bắt đầu gặp phải các trường hợp ngoại lệ. Và khi bạn làm vậy, việc làm rõ mọi thứ trước sẽ tránh được rất nhiều ma sát tại các điểm nhạy cảm tiềm năng trong dòng thời gian kiểm toán. Thấy đấy, mục đích của một thỏa thuận dịch vụ không phải là nó có thể được kiện tụng tại một tòa án cách xa hàng ngàn dặm từ vị trí hiện tại của bạn. Chắc chắn, trong trường hợp xấu nhất, có thể là như vậy. Nhưng chủ yếu nó được thực hiện để sắp xếp kỳ vọng từ cả hai phía, một cách để buộc hai bên nói về các chi tiết mà họ sẽ không làm. Dưới đây là một vài kịch bản đã xảy ra và nên được xử lý rõ ràng: - Khách hàng chưa sẵn sàng với cam kết cuối cùng trước ngày bắt đầu. - Vì lý do không lường trước, một hoặc nhiều kiểm toán viên không có sẵn cho một phần hoặc toàn bộ thời gian kiểm toán. - Phạm vi cuối cùng yêu cầu thời gian xem xét lâu hơn, tăng chi phí. - Tranh luận về công cụ và định dạng nào được sử dụng để đếm SLOC cuối cùng. - Khách hàng giới thiệu chức năng mới để xem xét trong kiểm toán sửa lỗi. - Yêu cầu thanh toán chỉ được gửi sau khi báo cáo được giao. - Khách hàng muốn hủy kiểm toán chỉ với thông báo trước 24 giờ. - Khách hàng muốn gửi thanh toán trên blockchain mà họ ưa thích. - Phản đối về việc báo cáo được công bố sau một thời gian chờ đợi chấp nhận được. Ngoài việc làm rõ cách xử lý các kịch bản này, một thỏa thuận cũng cung cấp cho kiểm toán viên sự bảo vệ quan trọng: - Miễn trừ bất kỳ trách nhiệm nào đối với lỗi và khai thác bị bỏ sót. - Duy trì quyền sở hữu trí tuệ đối với các công cụ, khái niệm tấn công được phát triển trong quá trình kiểm toán (trong phạm vi pháp luật cho phép). - Sắp xếp cho các khoản thanh toán trước, phí hủy bỏ và v.v. - Đáp ứng các yêu cầu thẩm định, KYB và khung pháp lý. Điều này có liên quan đến thuế, tuân thủ và yêu cầu nguồn gốc của quỹ. Vì những lý do đó, chúng tôi nhanh chóng nhận ra rằng dành thêm một chút thời gian trước khi đặt lịch là rất đáng giá, và chúng tôi khuyến khích mọi kiểm toán viên điều hành một doanh nghiệp hợp pháp làm điều tương tự.

Vào cuối năm 2024, TrustSec đã phát hiện một lỗi đồng thuận trong client Optimism của @OPLabsPBC. Trong trường hợp xấu nhất, op-node có thể có cái nhìn sai về trạng thái L2, gây ra sự chia tách chuỗi từ các client khác. Để cảm ơn nghiên cứu của chúng tôi, OP Labs đã hào phóng trao tặng chúng tôi một khoản tiền thưởng $7.5k. Hãy xem tất cả chi tiết trong bài viết kỹ thuật dưới đây!