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ỉ.