Phân loại lỗi là sản phẩm thực sự: chạy các tác nhân AI trên mã giao thức của Ethereum

Ghi chú từ nhóm Bảo mật Giao thức của Tổ chức Ethereum về việc chạy các tác nhân AI phối hợp trên mã giao thức thực tế, bao gồm cách chúng tôi tổ chức công việc, những gì trụ vững được sau khi xem xét kỹ lưỡng, và những gì các nhóm phát triển client cùng các nhà nghiên cứu bảo mật có thể học hỏi từ đó. Bài viết này là một bài độc lập; các bài viết sau sẽ đi sâu hơn vào từng client cụ thể.

Những gì chúng tôi đã chạy và điều làm chúng tôi ngạc nhiên

Tại nhóm Bảo mật Giao thức của Tổ chức Ethereum, chúng tôi đã và đang chạy các tác nhân AI phối hợp trên các loại hệ thống mà mạng lưới phụ thuộc vào, như phần mềm hệ thống, mã mật mã học và các hợp đồng bắt buộc phải chính xác. Các tác nhân này đã tìm ra những lỗi thực sự. Một lỗi hiện đã được công bố: một lỗi panic có thể kích hoạt từ xa trong gossipsub của libp2p, một phần cốt lõi của lớp mạng ngang hàng mà các client đồng thuận Ethereum chạy trên đó, đã được sửa và công bố dưới dạng CVE-2026-34219 với sự ghi nhận dành cho nhóm.

Việc các tác nhân tìm ra lỗi không phải là điều đáng ngạc nhiên. Điều đáng ngạc nhiên là công sức bỏ ra để tìm kiếm chúng lại rất ít, trong khi phần lớn công sức lại dành cho việc phân biệt các lỗi thực sự với những lỗi chỉ có vẻ như là thật.

Bài viết này dành cho các nhóm phát triển client và các nhà nghiên cứu bảo mật muốn thực hiện điều tương tự. Nó bao gồm cách chúng tôi tổ chức các tác nhân, tiêu chuẩn mà một ứng viên lỗi phải vượt qua trước khi được tính là một phát hiện thực sự, và những thói quen giúp giữ cho kết quả luôn đáng tin cậy.

Các nhóm ở những nơi khác cũng đang hội tụ về cùng một công thức. Nhóm Frontier Red Team của Anthropic đã xây dựng một tác nhân viết các bài kiểm thử dựa trên thuộc tính và tìm thấy các lỗi thực sự trên toàn bộ hệ sinh thái Python. Cloudflare đã chạy một mô hình tiên tiến thông qua một bộ công cụ nghiên cứu bảo mật trên chính các hệ thống của họ. Mọi người đều đi đến cùng một vòng lặp: hướng một mô hình có năng lực vào một cơ sở mã, để nó tìm kiếm và phân loại những gì trả về. Vì vậy, câu hỏi thực sự là làm thế nào để thực hiện điều này mà không bị chìm ngập trong những thông tin nhiễu nghe có vẻ rất tự tin.

Một lưu ý trước: các công cụ dành cho việc kiểm toán bằng tác nhân thay đổi rất nhanh và bất kỳ thiết lập cụ thể nào cũng sẽ lỗi thời chỉ trong vài tuần. Vì vậy, bài viết này cố tình tập trung vào các phương pháp, vốn có tính lâu dài, thay vì các công cụ. Việc công bố lỗ hổng là một chủ đề riêng biệt và có thể sẽ được trình bày trong một bài viết riêng.

Tác nhân là một công cụ tìm kiếm, không phải là một cơ chế kiểm chứng

Một tác nhân được hướng vào một cơ sở mã là một công cụ tìm kiếm, rất giống với một fuzzer. Sự khác biệt nằm ở những gì được trả về. Một fuzzer cung cấp cho bạn một sự cố (crash) và một dấu vết ngăn xếp (stack trace). Một tác nhân cung cấp cho bạn nhiều hơn thế, bao gồm một bản báo cáo (chuỗi lệnh gọi, nhận định về tác động, mức độ nghiêm trọng được đề xuất) và các tạo tác để chứng minh cho điều đó, chẳng hạn như một bằng chứng khái niệm mà bạn có thể chạy trên mã thực tế.

Tất cả những điều đó làm cho kết quả trở nên dễ đọc và dễ tin cậy, đặc biệt nhất là bằng chứng khái niệm có thể chạy được. Vì vậy, đừng đếm số lượng ứng viên lỗi mà một tác nhân tạo ra. Hãy đếm xem có bao nhiêu trong số đó thực sự là lỗi thật.

Cách thức tổ chức công việc

Chúng tôi chạy song song nhiều tác nhân trên cùng một mục tiêu. Chúng phối hợp thông qua chính kho lưu trữ, với trạng thái được chia sẻ trong hệ thống kiểm soát phiên bản và không có quy trình trung tâm nào phân phát công việc. Một tác nhân ghi lại một nhận định ở nơi mà các tác nhân khác có thể nhìn thấy, thực hiện công việc và commit.

Chúng tôi học được cách tiếp cận này từ bài viết của Anthropic về việc xây dựng một trình biên dịch C với một đội ngũ các tác nhân, vốn cũng phối hợp theo cách tương tự. Không cần phải xây dựng hay duy trì một bộ điều phối trung tâm nào, và cũng ít có khả năng xảy ra lỗi hơn.

Các vai trò được tạo ra bởi công việc được khám phá:

• Trinh sát (Recon) biến một bề mặt tấn công thành các giả thuyết cụ thể, có thể kiểm thử được. Không phải là "kiểm toán bộ giải mã" mà là "trường dữ liệu này được tin cậy vượt qua điểm này; đây là thuộc tính mà nó nên giữ, cách nó có thể bị phá vỡ, và bằng chứng để giải quyết điều đó."
• Săn lùng (Hunting) lấy một giả thuyết, theo dõi đường dẫn mã và cố gắng xây dựng một trình tái tạo lỗi.
• Lấp đầy khoảng trống (Gap-filling) xem xét những gì đã được chấp nhận và những gì bị từ chối, viết loạt giả thuyết tiếp theo và theo dõi mức độ bao phủ để các tác nhân không tiếp tục đi vào lối mòn cũ.
• Xác thực (Validation) kiểm tra lại từng ứng viên một cách độc lập, loại bỏ các bản sao trùng lặp và đưa ra quyết định.

Chúng tôi không phát minh ra quy trình này. Cloudflare cũng mô tả các giai đoạn tương tự: trinh sát, săn lùng song song, xác thực độc lập, loại bỏ trùng lặp, báo cáo, và bài viết của họ đã giúp định hình quy trình của chúng tôi.

Dưới đây là hình ảnh của một ứng viên trước khi nó được tính là một phát hiện thực sự:

mục tiêu:      thành phần và điểm đầu vào mà kẻ tấn công thực sự có thể tiếp cận
bất biến:      thuộc tính phải được giữ nguyên
cơ chế:        cách thức cụ thể mà nó có thể bị làm cho phá vỡ
thành công:    bằng chứng có thể quan sát được: một lỗi panic, một sự đình trệ, một đầu vào không hợp lệ được chấp nhận
trình tái tạo: một tạo tác độc lập chạy trên mã thực tế
khử trùng lặp: một khóa, để hai tác nhân không theo đuổi cùng một thứ

Lược đồ này tồn tại là có lý do. Nó bắt buộc phải có một nhận định cụ thể, có thể kiểm thử được và một định nghĩa rõ ràng về việc hoàn thành. Một tác nhân phải viết ra một bằng chứng có thể quan sát được sẽ không thể thoái thác bằng câu "điều này trông có vẻ rủi ro."

Có thể tái tạo hoặc nó không hề tồn tại

Có một quy tắc quan trọng hơn bất kỳ quy tắc nào khác. Một ứng viên không phải là một phát hiện thực sự cho đến khi có một tạo tác độc lập tái tạo lại được lỗi đó trên mã thực tế, và nó phải chạy được đối với một người không phải là người đã viết ra nó.

Trình tái tạo lỗi không đọc bản báo cáo và nó không quan tâm mô hình nghe có vẻ tự tin đến mức nào. Nó chỉ có thể chạy được hoặc không.

Phần lớn giá trị của nó nằm ở những kết quả dương tính giả mà nó bắt được. Ba trong số đó xuất hiện lặp đi lặp lại, và mỗi trường hợp đều là do tác nhân được thông qua vì một lý do sai lầm:

• Một lỗi panic chỉ xảy ra trong bản dựng gỡ lỗi. Nếu biên dịch và chạy nó theo cách phần mềm thực sự được phát hành, giá trị chỉ đơn giản là quay vòng. Không có gì bị sập cả. Nó trông giống như một sự cố, nhưng thực tế không phải vậy.
• Một trình tái tạo xây dựng thủ công một giá trị nội bộ nào đó, một giá trị mà không có đầu vào thực tế nào có thể tạo ra được, bởi vì mọi đường dẫn mà kẻ tấn công kiểm soát đều đã từ chối nó từ trước. Lỗi này chỉ "tái tạo" được đối với một hàm mà không có thành phần nào có thể tiếp cận được gọi nó theo cách đó.
• Trong công việc xác minh hình thức, một bằng chứng được thông qua nhưng không mang ý nghĩa như bạn mong muốn. Tuyên bố đó hiển nhiên đúng bất kể mã thực hiện điều gì, hoặc nó yếu hơn thuộc tính mà bạn muốn nắm bắt. Trình xác minh được thỏa mãn, nhưng định lý không ràng buộc hành vi mà bạn thực sự quan tâm.

Không có điều nào trong số này là mới. Nó giống hệt như một bài kiểm thử được thông qua vì nó thực sự không kiểm tra bất cứ điều gì. Điểm mới ở đây là khối lượng. Một tác nhân viết ra phiên bản vô dụng nhanh ngang với phiên bản thực sự, và cũng với sự tự tin tương đương. Vì vậy, việc kiểm tra phải được tự động hóa. Bạn không thể trông cậy vào việc tác nhân tự phát hiện ra lỗi của chính nó.

Tỷ lệ tín hiệu trên nhiễu chiếm phần lớn công việc

Hầu hết các ứng viên đều sai, trùng lặp hoặc nằm ngoài phạm vi. Đó không phải là vấn đề của phương pháp; đó là cách nó hoạt động. Mục tiêu là loại bỏ nhanh chóng những ứng viên sai và củng cố những ứng viên thực sự bằng bằng chứng khó có thể chối cãi.

Mỗi ứng viên sống sót sẽ trải qua hai đợt kiểm tra độc lập. Một kẻ tấn công thực sự có thể tiếp cận nó trong một cấu hình bình thường không? Và kẻ tấn công phải trả giá bao nhiêu để thực hiện điều đó, so với thiệt hại mà mạng lưới phải chịu nếu cuộc tấn công thành công? Một lỗi mà bất kỳ nút ngang hàng đơn lẻ nào cũng có thể kích hoạt sẽ rất khác so với một lỗi đòi hỏi quyền truy cập đặc biệt hoặc một lượng tài nguyên khổng lồ.

Mọi thứ đều được kiểm tra đối chiếu với một danh sách liên tục cập nhật về những gì đã được biết đến, đã được sửa hoặc đã bị từ chối. Nếu không có danh sách đó, các tác nhân sẽ liên tục khám phá lại cùng một vấn đề đã đóng và báo cáo nó lặp đi lặp lại.

Tỷ lệ chấp nhận thay đổi rất nhiều tùy theo từng mục tiêu, và bản thân sự thay đổi đó cũng rất hữu ích. Chạy công cụ này trên các đoạn mã đã trưởng thành, được kiểm toán kỹ lưỡng và hầu như không có gì sống sót, điều này vẫn rất đáng để biết. "Chúng tôi đã tìm kiếm kỹ lưỡng và không thấy gì" là một kết quả thực sự. Chạy nó trên các đoạn mã ít được khám phá hơn, hoặc trên các đoạn mã đã được xác minh hình thức, nơi một bằng chứng được máy kiểm tra bao phủ một mô hình và mã byte được triển khai chỉ được giả định là khớp với nó, thì sẽ có nhiều lỗi lọt qua hơn.

Chúng tôi không phải là những người duy nhất nhận thấy rằng việc phân loại lỗi mới là phần khó khăn. Bài học chính của Cloudflare là một phạm vi hẹp sẽ mang lại hiệu quả tốt hơn so với việc quét trên diện rộng. Tác nhân kiểm thử dựa trên thuộc tính của Anthropic đã tạo ra khoảng một nghìn báo cáo ứng viên, sau đó sử dụng phương pháp xếp hạng và đánh giá của chuyên gia để thu hẹp xuống một nhóm hàng đầu có độ chính xác khoảng 86%. Việc tạo ra lỗi là phần dễ dàng. Tôi sẽ không công bố các con số của riêng chúng tôi ở đây; vì khi gắn với một mục tiêu cụ thể, chúng sẽ nói lên nhiều điều về mục tiêu đó hơn là về phương pháp.

Những gì các tác nhân làm tốt và những điểm chúng gây hiểu lầm

Có sự thổi phồng theo cả hai hướng, vì vậy đây là một danh sách rõ ràng về những gì các tác nhân làm tốt và những điểm chúng gây hiểu lầm.

Sự phân chia này thậm chí không ổn định từ nhiệm vụ này sang nhiệm vụ khác. Stanislav Fort, khi thử nghiệm một loạt các mô hình trên các lỗ hổng thực tế, gọi đây là một biên giới lởm chởm, hay nói cách khác, một mô hình có thể khôi phục toàn bộ chuỗi khai thác trên một cơ sở mã nhưng lại thất bại trong việc theo dõi luồng dữ liệu cơ bản trên một cơ sở mã khác. Bạn không thể cho rằng một kết quả tốt có nghĩa là kết quả tiếp theo cũng sẽ như vậy, đó là một lý do khác khiến mỗi ứng viên đều phải được kiểm tra riêng biệt.

Hàng cuối cùng là hàng quan trọng nhất. Một phiên làm việc của tác nhân đơn lẻ rất giỏi trong việc suy luận một lần và rất tệ đối với các lỗi kéo dài qua một chuỗi các bước, trong đó mỗi bước đều hợp lệ và chỉ có thứ tự là sai. Đối với những trường hợp đó, tác nhân không phải là công cụ tìm kiếm. Công việc của nó là đề xuất những chuỗi nào đáng để chạy qua một bộ công cụ kiểm thử có trạng thái. Nếu được sử dụng theo cách đó, nó hoạt động rất tốt. Nếu được sử dụng như một sự thay thế cho bộ công cụ kiểm thử, nó sẽ bỏ lỡ những lỗi đắt giá nhất, những lỗi chỉ xuất hiện qua một chuỗi các bước.

Giữ cho mọi thứ trung thực

Một vài thói quen sẽ đảm nhận phần lớn công việc trong việc làm cho các phát hiện của tác nhân trở nên đáng tin cậy, và không có thói quen nào trong số đó là phức tạp.

• Nguồn gốc rõ ràng trên mọi tạo tác: cái gì đã tạo ra nó, với bối cảnh nào, trên phiên bản nào. Một phát hiện phải là thứ mà bạn có thể chạy lại sau nhiều tháng.
• Tính tất định ở những nơi quan trọng: một môi trường, một cách để biên dịch và chạy, để từ "tái tạo" mang cùng một ý nghĩa trên mọi máy tính, chứ không chỉ trên máy tính nơi nó được tìm thấy.
• Các chuẩn mực, không phải kịch bản: hãy cho các tác nhân biết điều gì là quan trọng, các bất biến và tiêu chuẩn cho một phát hiện thực sự, thay vì một quy trình được đánh số. Các tác nhân bị kịch bản hóa quá mức sẽ hỏng theo cùng một cách mà các bài kiểm thử bị chỉ định quá mức gặp phải, chúng tiếp tục làm theo các bước ngay cả khi các bước đó không còn ý nghĩa. Một nghiên cứu về các tệp ngữ cảnh của kho lưu trữ cũng phát hiện ra điều tương tự: các yêu cầu bổ sung làm giảm tỷ lệ thành công của nhiệm vụ và tăng chi phí lên hơn 20%, và các tác giả khuyên nên giữ ngữ cảnh ở mức yêu cầu tối thiểu.
• Con người đưa ra quyết định cuối cùng: các tác nhân chỉ đề xuất. Chúng không quyết định điều gì là thực sự, điều gì là bản sao của một vấn đề đã biết, hoặc điều gì sẽ được công bố và khi nào.

Nút thắt cổ chai đã dịch chuyển

AI không thay thế nhà nghiên cứu bảo mật. Nó chỉ dịch chuyển công việc. Thời gian trước đây từng được dùng để đưa ra và theo đuổi các giả thuyết giờ đây được dành cho việc đánh giá chúng ở quy mô lớn, bao gồm việc xây dựng cơ chế kiểm chứng, chạy phân loại lỗi, duy trì danh sách các vấn đề đã biết và xử lý việc công bố lỗ hổng.

Nút thắt cổ chai không hề biến mất. Nó đã chuyển từ việc tìm kiếm lỗi sang việc tin tưởng vào các kết quả, đây là một vị trí tốt hơn cho nó, bởi vì đó là nơi mà phán đoán của con người thực sự có ý nghĩa. Nhưng nó vẫn là một nút thắt cổ chai, và việc phớt lờ điều đó là cách khiến bạn cuối cùng lại đưa ra một kết luận sai lầm rằng "mọi thứ đều ổn."

Những thực tiễn giúp cho công việc này hiệu quả không phải là mới. Các lỗi có thể tái tạo, các cơ chế kiểm chứng thực sự và việc phân loại lỗi cẩn thận cũng chính là những thực tiễn đã biến fuzzing từ một chủ đề nghiên cứu thành một tiêu chuẩn thực hành trong mười lăm năm qua. Các công cụ là mới. Nhưng các thực tiễn thì không.

Các công cụ tiếp tục thay đổi nhanh đến mức nào vẫn là một câu hỏi mở. Nicholas Carlini, một người cẩn trọng và từng là một người hoài nghi, lập luận rằng trường hợp tăng trưởng theo cấp số nhân là đáng để xem xét nghiêm túc, ngay cả khi ông vẫn giữ các thanh sai số rộng cho nó. Nếu khía cạnh tạo ra lỗi tăng nhanh như vậy, thì khía cạnh đánh giá cũng phải tăng theo, nếu không khoảng cách giữa những gì được tạo ra và những gì thực sự được xác minh sẽ chỉ ngày càng nới rộng.

Đối với các hệ thống mà Ethereum phụ thuộc vào, đó mới là phần quan trọng. Các tác nhân cho phép chúng ta bao quát được nhiều phạm vi hơn so với việc làm thủ công. Đổi lại, chúng đòi hỏi sự đánh giá cẩn thận hơn, trên một đống lớn hơn nhiều các nhận định nghe có vẻ rất tự tin. Đó là một sự đánh đổi đáng giá, miễn là bạn nhớ rằng sự đánh giá mới là sản phẩm thực sự.