Các mồi nhử RedHerring giúp giảm việc phát hiện lỗ hổng tự động tới 60%

Các nhà nghiên cứu bảo mật từ lâu đã cho rằng thách thức lớn nhất trong việc tự động phát hiện lỗ hổng là tìm ra lỗi ngay từ đầu. Một bài báo được công bố vào ngày 28 tháng 9 năm 2026 bởi nhà nghiên cứu Dongdong She lật ngược giả định đó: nút thắt thực sự không phải là phát hiện ra một điểm yếu có thể tồn tại, mà là chứng minh rằng điểm yếu đó là có thật. Sự khác biệt này, được mô tả trong một nghiên cứu mới với tiêu đề “Cheap to Hypothesize, Costly to Verify: The Defense Surface of Agentic Vulnerability Discovery” (Dễ để đưa giả thuyết, Tốn kém để xác minh: Bề mặt phòng thủ của việc phát hiện lỗ hổng do tác nhân AI thực hiện), đưa ra cả một vấn đề và một giải pháp có thể thay đổi cách các tác nhân AI săn lùng lỗi phần mềm.
Những điểm rút ra chính
Các tác nhân LLM tự trị có thể tạo ra số lượng lớn các giả thuyết về lỗ hổng, nhưng chỉ có đủ ngân sách để xác minh một phần trong số đó, tạo ra cái mà bài báo gọi là “bất cân xứng giữa giả thuyết và xác minh”.
RedHerring, một công cụ phòng thủ mới, cấy vào các kho mã những mồi nhử được chứng minh an toàn chắc chắn, trông giống như các lỗ hổng thật nhưng thực ra là những ngõ cụt.
Trên 33 dự án OSS-Fuzz, 70 phiên đánh giá và năm mô hình AI, RedHerring đã cắt giảm số lỗ hổng thực được phát hiện từ 38,7% xuống 60,4%.
Các tác nhân tiêu tốn từ 30,6% đến 51,5% số token hoàn thành, và ước tính từ 32,5% đến 49,9% thời gian chạy của họ, để theo đuổi các mồi nhử thay vì các lỗi thật.
Ngay cả khi các tác nhân được cho biết có thể có mồi nhử, RedHerring vẫn cắt giảm việc phát hiện lỗ hổng thực 37,2% so với nền tảng đã được thông tin.
Thách thức của việc khám phá lỗ hổng tự động
Cốt lõi, bài báo lập luận rằng khám phá lỗ hổng tự động là một bài toán “đếm số lượng” với một trần cứng. Các tác nhân LLM tự trị có thể tạo ra hàng chục giả thuyết lỗi hợp lý trong vài phút, nhưng chỉ một phần hữu hạn trong số đó mới thực sự được kiểm tra trước khi ngân sách cho việc tính toán, thời gian hay tiền bạc cạn kiệt. Sự chênh lệch giữa việc đoán thì dễ còn xác nhận thì khó nằm ở trung tâm của toàn bộ nghiên cứu.
Bất cân xứng giữa giả thuyết và xác minh trong các tác nhân LLM
Bài báo mô tả khoảng cách này như một “bất cân xứng giữa giả thuyết và xác minh”: việc hình thành một lý thuyết về nơi một lỗi có thể tồn tại là rẻ, nhưng chứng minh nó thông qua phân tích khả năng truy cập (reachability), thực thi thực sự và xây dựng một bản proof-of-concept chạy được thì lại tốn kém hơn rất nhiều. Chính sự lệch chi phí này khiến “cảm giác ban đầu” của một tác nhân — “thứ này có vẻ dễ bị tổn thương” — gần như luôn nhanh hơn để tạo ra so với bằng chứng cần thiết để xác nhận.
Giới hạn tài nguyên trong xác minh lỗ hổng
Vì việc xác minh tiêu tốn nhiều tài nguyên hơn đáng kể so với việc tạo giả thuyết, nên khám phá tự động trở thành một quá trình “xác minh chọn lọc bị giới hạn bởi tài nguyên” như bài báo gọi. Trên thực tế, điều đó có nghĩa là một tác nhân làm việc trong một ngân sách cố định phải chọn xem lộ trình nào đáng để theo đuổi và lộ trình nào bị bỏ lại. Ý chính của bài báo là quá trình chọn lọc này cũng có thể bị người phòng thủ thao túng — chuyển nỗ lực xác minh thành một “bề mặt phòng thủ” độc đáo như họ mô tả.
Giới thiệu RedHerring: Một cơ chế phòng thủ dựa trên mồi nhử mới
RedHerring là công cụ được xây dựng dựa trên hiểu biết đó. Nó hoạt động bằng cách gieo vào một kho mã các mồi nhử được chứng minh là an toàn một cách chắc chắn—nghĩa là chúng không thể bị khai thác thực sự—nhưng được thiết kế để giống hệt kiểu mối dẫn mà một tác nhân chuyên săn lỗ hổng sẽ muốn theo đuổi.
Thiết kế và cơ chế của các mồi nhử an toàn
Mỗi mồi nhử ghép một chuỗi lỗ hổng bắt nguồn từ CVE — kiểu mẫu mã được biết là thường xuất hiện trước các khai thác ngoài đời — với một “cầu nối giả” mà bài báo gọi tên, khiến đầu mối nguy hiểm, hay “điểm nhận” (sink), luôn không thể đạt được một cách vĩnh viễn. Nói cách khác, mồi nhử tạo ra một dấu vết rất thuyết phục nhưng thực chất không dẫn tới bất kỳ điều nguy hiểm nào. RedHerring cũng tinh chỉnh từng mồi nhử cho đúng kho mã mục tiêu cụ thể để nó hòa nhập như logic chương trình bình thường thay vì lộ rõ như một cái bẫy. Bước thích nghi này quan trọng: một mồi nhử trông chung chung hoặc “lạc quẻ” sẽ dễ bị tác nhân loại bỏ hơn nhiều.
Hiệu quả xác minh thông qua chứng chỉ riêng
“Chiêu” thật của phương pháp phòng thủ là xác minh bất xứng. Người phòng thủ nắm một chứng chỉ riêng cho phép họ xác nhận rằng một mồi nhử an toàn gần như ngay lập tức. Một tác nhân tấn công, chỉ dựa trên kho mã đã được phát hành và không có quyền truy cập chứng chỉ đó, phải đối mặt với một bài toán tính toán cực kỳ khó để chứng minh điều tương tự. Khoảng chênh lệch này chính là thứ “ngốn” ngân sách xác minh giới hạn của tác nhân — truy đuổi một lỗi mà người phòng thủ đã biết là giả, nhưng tác nhân lại không có cách hiệu quả để loại trừ.
Đánh giá hiệu quả của RedHerring
Những con số đằng sau RedHerring cho thấy chiến thuật này hoạt động hiệu quả vượt xa sự tò mò mang tính chứng minh ý tưởng. Khi được thử nghiệm trong các điều kiện gần với thực tế thay vì một môi trường đồ chơi, RedHerring tạo ra các mức giảm trong việc tìm ra lỗi thành công—đáng kể và nhất quán—trên nhiều mô hình AI khác nhau.
Giảm số lỗ hổng thực sự được phát hiện
Trên 33 dự án OSS-Fuzz, 70 phiên đánh giá và năm mô hình khác nhau được thử nghiệm với ngân sách tương đương, RedHerring đã giảm số lỗ hổng thực được phát hiện trong khoảng từ 38,7% đến 60,4%. Phân tích quỹ đạo hỗ trợ kết quả đó cho thấy các tác nhân dành từ 30,6% đến 51,5% số token hoàn thành của họ, và ước tính từ 32,5% đến 49,9% tổng thời gian chạy, để xác minh các mồi nhử thay vì theo đuổi các lỗi thật. Nói theo cách thực tế, đó là khoảng một phần ba đến một nửa ngân sách làm việc của tác nhân bị chuyển hướng để đuổi theo thứ vốn dĩ không thể khai thác ngay từ đầu.
Hiệu quả ngay cả khi tác nhân biết có mồi nhử
Một trong những kết quả đáng chú ý nhất đến từ việc thử nghiệm điều gì xảy ra khi yếu tố bất ngờ bị loại bỏ. Khi các tác nhân được thông báo rõ rằng có thể có mồi nhử trong kho mã, họ đã điều chỉnh chiến lược tìm kiếm cho phù hợp. Dù vậy, RedHerring vẫn giảm số lỗ hổng được phát hiện đi 37,2% so với nền tảng đã được thông tin trước đó. Phát hiện này quan trọng vì nó cho thấy khả năng phòng thủ không dựa vào bí mật để hoạt động — sự bất cân xứng nền tảng giữa việc giả thuyết rẻ và xác minh tốn kém vẫn được giữ nguyên ngay cả khi tác nhân biết bẫy tồn tại.
Vì sao điều này quan trọng đối với kiểm thử an ninh do AI điều khiển
Hệ quả vượt xa một bài báo nghiên cứu đơn lẻ. Khi các tác nhân dựa trên LLM được đưa vào các chương trình bug bounty, các pipeline fuzzing liên tục và việc rà soát mã tự động, thì động lực tìm kiếm tương tự bị ràng buộc bởi tài nguyên sẽ áp dụng ở mọi nơi mà tác nhân hoạt động trong một ngân sách. Việc biến chính nỗ lực xác minh thành một bề mặt phòng thủ mang lại cho các nhà duy trì phần mềm một “đòn bẩy” mới: thay vì chỉ làm cứng mã để chống bị khai thác, họ còn có thể làm cho quá trình tìm kiếm trở nên tốn kém hơn và kém tin cậy hơn đối với một kẻ tấn công tự động. Cách nhìn lại này — coi tính chọn lọc của một tác nhân như một điểm yếu có thể khai thác — có thể là ý tưởng dễ chuyển giao nhất của bài báo, vì nó không phụ thuộc vào bất kỳ kiến trúc mô hình đơn lẻ hay cơ sở mã cụ thể nào.
Bài viết được tạo với sự hỗ trợ của trí tuệ nhân tạo và được nhóm biên tập xem xét.