30 giờ. 16 người. 390 kho mã. 4.962 vấn đề. 720 lỗi nghiêm trọng. Đó là con số tôi đọc được từ chiến dịch AI Bitcoin Security Campaign. Một chiến dịch quét bảo mật mã nguồn mở do nhà phát triển Calle tổ chức. Nghe có vẻ ấn tượng. Tôi dừng lại ở dòng báo cáo viết: mỗi giờ làm việc, mỗi người tìm ra 2,3 lỗi nghiêm trọng hoặc cao. Tôi bấm máy tính. 720 chia cho 16 người, chia cho 30 giờ, bằng 1,5. Không ai ra 2,3. Có thể họ tính theo giờ làm việc hiệu quả, nhưng bài báo không nói. Một bản tin bảo mật với số liệu không khớp là một dấu hiệu xấu.
Chiến dịch này có mười sáu chuyên gia bảo mật tham gia. Họ nhận tài trợ từ OpenSats, OpenCode và một nhà cung cấp dịch vụ AI. Mục tiêu là quét 390 kho mã nguồn mở liên quan đến Bitcoin trong vòng 30 giờ. Kết quả công bố: 4.962 phát hiện, trong đó 720 vấn đề được xếp loại nghiêm trọng hoặc cao. Với các trường hợp nghiêm trọng, nhóm nghiên cứu gửi bằng chứng khai thác cho người bảo trì. Nhiều người bảo trì đã phản hồi xác nhận. Điều đó giúp kết quả không bị coi là rác thải. Nhưng tôi vẫn không ăn mừng.
Hãy đặt chiến dịch vào bối cảnh. Trước khi AI phổ biến, một công ty an ninh như Trail of Bits thường dành từ một đến bốn tuần để audit một dự án vừa. Ở đây, 16 người xử lý 390 dự án trong 30 giờ. Tức là mỗi giờ họ quét trung bình 13 dự án. Đó là một sự thay đổi lớn về quy mô. Nhưng quy mô không đồng nghĩa với chất lượng. Trong bảo mật, tôi học được rằng con số phát hiện chỉ là khởi đầu. Điều duy nhất đáng tin là lỗi đã được xác nhận và vá. Bài báo không đưa ra con số đó. Vì vậy, toàn bộ chiến dịch này mới chỉ là một bước khởi đầu, không phải một chiến thắng.
Bây giờ nói về con số. 4.962 phát hiện chia cho 30 giờ bằng 165,4 phát hiện mỗi giờ. Bài báo làm tròn thành 166. Tôi chấp nhận. Nhưng 720 lỗi nghiêm trọng chia cho 16 người, chia cho 30 giờ, chỉ bằng 1,5. Vậy con số 2,3 từ đâu ra? Nếu muốn có 2,3, bạn cần tổng thời gian làm việc là 313 giờ, tương đương mỗi người chỉ làm việc hiệu quả 19,6 giờ. Có thể các chuyên gia dành thời gian cho việc khác như điều phối, chờ AI chạy, hoặc viết báo cáo. Cũng có thể họ chỉ tính những giờ ngồi trước màn hình và không tính thời gian chờ. Nhưng dù thế nào, một con số công bố thiếu minh bạch sẽ làm giảm độ tin cậy. Trong giới bảo mật, chúng tôi gọi đó là thiếu nghiệp vụ. Tôi không thể dựa vào một báo cáo mà tôi phải tự suy diễn cách tính.
Ai đó có thể giải thích con số 2,3 bằng cách giả định rằng các chuyên gia không dành toàn bộ 30 giờ cho việc quét. Họ có thể dành thời gian để viết báo cáo, trao đổi với nhau, hoặc chờ mô hình AI xử lý. Giả sử làm việc hiệu quả 19,6 giờ mỗi người, thì 2,3 là chính xác. Nhưng điều đó cũng có nghĩa là hiệu suất quét thực tế thấp hơn tuyên bố. Một điều nữa: nếu AI tự động chạy quét ra hàng nghìn kết quả và con người chỉ phân loại, thì con số phát hiện phản ánh AI nhiều hơn là con người. Nếu vậy, bài báo nên ghi rõ đâu là phần của AI, đâu là phần của con người.
Câu hỏi tiếp theo: trong 4.962 phát hiện, bao nhiêu phần trăm là thật? Slither và Mythril, hai công cụ static analysis phổ biến nhất, có thể báo cáo hàng trăm cảnh báo chỉ để tìm ra một vài lỗi thực sự. AI cũng có thể như vậy. Thậm chí tệ hơn, vì mô hình ngôn ngữ lớn thường tạo ra những giải thích rất thuyết phục cho những kết luận sai. Nhưng tín hiệu xác nhận từ người bảo trì cho thấy có giá trị. Khi họ nhận được bằng chứng khai thác và xác nhận lỗi, điều đó có nghĩa là ít nhất một phần trong 720 là thật. Tuy nhiên, tôi chưa thấy ai công bố tỉ lệ chấp nhận. Trong kinh nghiệm của tôi với các nền tảng bug bounty như Immunefi, ngay cả một chuyên gia giỏi cũng chỉ có tỉ lệ accepted khoảng 50%. Vậy 720 lỗi nghiêm trọng, sau khi con người kiểm tra, còn lại bao nhiêu? Không ai biết. Bài báo không nói.
Điểm tôi đánh giá cao là chiến lược prompt đa dạng. Có một chi tiết trong báo cáo nói rằng mỗi nhà nghiên cứu sử dụng các prompt khác nhau, và họ tin rằng điều này giúp phát hiện những điểm yếu mà một phương pháp duy nhất có thể bỏ sót. Nghe quen thuộc. Trong học máy, đây là nguyên lý ensemble. Kết hợp nhiều mô hình yếu, mỗi mô hình có một góc nhìn khác nhau, sẽ cho kết quả mạnh hơn một mô hình đơn lẻ. Áp dụng vào bảo mật, nó có nghĩa là: nếu bạn hỏi AI theo một cách duy nhất, bạn sẽ nhận được một loại câu trả lời duy nhất. Nếu bạn hỏi theo 16 cách khác nhau, bạn sẽ mở rộng vùng phủ sóng. Đây là một insight quan trọng. Tôi sẽ dùng nó trong bot phân tích của mình. Nhưng tôi vẫn muốn biết họ đã xây dựng pipeline như thế nào. Rõ ràng, không phải chỉ có prompt. Chắc chắn có bước tiền xử lý mã nguồn, trích xuất chức năng, chạy thử. Những bước này quyết định chất lượng hơn là prompt. Bài báo giữ im lặng.
Tôi cũng thấy thiếu một thứ quan trọng: danh sách các dự án bị ảnh hưởng. Nếu bạn tìm thấy 720 lỗi nghiêm trọng trong 390 dự án, bạn nên công bố tên các dự án. Không phải để bêu xấu. Để người dùng biết và tự bảo vệ. Nếu không, người dùng vẫn gửi tiền vào những hệ thống đã được biết là lỗi. Giữ im lặng có thể khiến các maintainer yên tâm, nhưng nó khiến người dùng mù thông tin. Trong một thị trường giảm như hiện tại, ẩn thông tin là một sai lầm. Người dùng cần dữ liệu để quyết định rút tiền hay ở lại. Họ không cần một chiến dịch PR.
Thiếu danh sách dự án bị ảnh hưởng là một lỗ hổng truyền thông. Trong thị trường giảm, người dùng đang hoảng sợ. Họ cần biết liệu ví họ đang dùng có nằm trong danh sách đó không. Một kho mã nguồn mở có thể không phải là một sản phẩm bạn đang dùng trực tiếp, nhưng nó có thể là thư viện mà ví của bạn phụ thuộc. Nếu không công bố tên, người dùng không thể rút lui. Họ bị bỏ lại trong bóng tối. Điều đó nuôi dưỡng tin đồn và FUD. Bảo mật không chỉ là kỹ thuật, nó còn là quản lý thông tin.
Bây giờ, tôi muốn kể cho bạn một câu chuyện cá nhân. Năm 2017, tôi 26 tuổi, vừa có bằng tiến sĩ mật mã. Tôi đặt 10 ETH vào một dApp được quảng cáo rất rầm rộ trên EOS. Tôi không tin whitepaper. Tôi clone mã nguồn từ GitHub về, tự đọc. Tôi phát hiện một lỗi reentrancy trong hàm rút tiền. Tôi viết báo cáo năm trang, gửi đến đội ngũ phát triển. Họ không trả lời. Hai tháng sau, hợp đồng bị hack. Tôi mất 10 ETH. Bài học tôi nhận được không phải là đừng tin ICO. Bài học là: phát hiện lỗi không có giá trị nếu không ai vá. Chiến dịch AI này có thể tìm thấy hàng nghìn lỗi, nhưng nếu các maintainer không hành động, tất cả chỉ là một danh sách dài. Một chiến dịch AI quét được 4.962 lỗi không phải là bằng chứng AI giỏi. Nó là bằng chứng mã nguồn xung quanh Bitcoin đang rất bẩn. Và một hệ sinh thái bẩn cần người dọn, không cần người đếm rác.
Trong ba tháng làm bug bounty trên Immunefi, tôi gửi tám báo cáo. Hai từ Avalanche, một từ Polygon. Ba trong số đó được chấp nhận. Tôi đã kiểm tra rất kỹ trước khi gửi. Vậy mà tỉ lệ accepted của tôi vẫn thấp. Điều đó cho tôi biết: ngay cả một phát hiện đáng tin cậy cũng cần thời gian để xác minh. AI có thể đưa ra 720 lỗi nghiêm trọng, nhưng con người sẽ mất nhiều tuần để xác nhận chúng. Số lượng không phải là giá trị. Giá trị là số lỗi đã được xác nhận và sửa.
Nói về kinh tế. Nếu AI quét có thể giảm thời gian audit từ vài tuần xuống vài giờ, các công ty audit truyền thống sẽ phải thay đổi. Mô hình cũ: một báo cáo dài 100 trang, đóng dấu, giao cho khách hàng. Mô hình mới: hệ thống giám sát liên tục, cập nhật theo thời gian thực, chi phí thấp hơn. Điều này tốt cho ngành, nhưng nó cũng tạo ra một thách thức. Những người mới vào nghề sẽ dựa vào AI và không học được cách đọc mã nguồn một cách tỉ mỉ. Tôi mất nhiều năm để đọc từng dòng code, từng hàm, từng sự phụ thuộc. Thời gian đó không bao giờ lãng phí. Vì vậy, tôi không nghĩ AI sẽ thay thế con người. Tôi nghĩ AI sẽ thay thế những con người lười biếng, và nó sẽ nâng cao những người biết dùng nó như một công cụ.
Các công ty audit truyền thống có thể phản ứng bằng cách tích hợp AI vào quy trình của họ. Nhưng họ cũng phải thay đổi mô hình thu phí. Nếu một chiến dịch 30 giờ có thể làm được việc mà trước đây cần nhiều tuần, khách hàng sẽ không trả tiền cho một báo cáo dài. Họ sẽ trả tiền cho sự đảm bảo liên tục, cho việc theo dõi các rủi ro mới, và cho việc phản hồi nhanh khi có lỗ hổng. Tôi nghĩ ngành audit sẽ hướng tới mô hình bảo hiểm kỹ thuật hơn là báo cáo một lần.
Đến đây, tôi muốn nói điều ngược lại với số đông. Mọi người nhìn vào 4.962 và vỗ tay: AI đang bảo vệ Bitcoin. Tôi nhìn vào 4.962 và giật mình: một kẻ tấn công cũng có thể dùng chính chiến lược này, cùng AI, cùng prompt đa dạng, và tìm ra những điểm yếu trước khi lập trình viên kịp vá. Thậm chí, một khi chiến dịch công bố chi tiết kỹ thuật, những kẻ xấu sẽ có cẩm nang. Đây là lý do tôi tin rằng công bố số lượng mà không công bố chi tiết, không công bố tiến trình vá, là một hành động vô trách nhiệm. Nó tạo ra cảm giác an toàn giả tạo. Tôi nhắc lại: audit không chạy, tiền bay. Nếu không có hành động ngay sau khi quét, những gì bạn nhận được chỉ là tổn thất.
Vậy, tôi đề xuất một cách đọc khác cho bản tin này. Lần tới khi ai đó khoe một chiến dịch AI quét tìm được hàng nghìn lỗi, đừng vội hỏi AI thông minh đến đâu. Hãy hỏi: bao nhiêu lỗi được xác nhận? Bao nhiêu lỗi đã được vá? Dự án nào còn rủi ro? Maintainer nào đang phản hồi? Nếu không có câu trả lời, bạn chỉ đang nhìn vào một màn khói. FOMO? Kỹ thuật mới nói. Nhưng kỹ thuật không tự vá lỗi. Hành động sau kỹ thuật mới nói. Tôi vẫn sẽ tự mình audit. Không phải vì tôi ghét AI. Mà vì tôi biết rằng, trong một thị trường giảm, sự sống còn của bạn không đến từ những con số đẹp. Nó đến từ những dòng code sạch, những bản vá đã ký, và một quy trình bảo mật có trách nhiệm. Đừng tin một con số trên blog. Hãy tự kiểm tra. Nếu bạn không tự kiểm tra được, hãy tìm người làm được. Nhưng đừng ngồi im và tin rằng AI sẽ cứu bạn.