AI vá lỗi xong rồi — nhưng nó còn thay đổi những gì?

Khi AI ngày càng nhanh trong việc tìm ra lỗ hổng bảo mật, câu hỏi đặt ra không còn là "có tìm được lỗi hay không" mà là "bản vá có thực sự an toàn hay không". Trail of Bits vừa công bố hai plugin mới giúp đưa việc vá lỗi bằng AI agent vào một quy trình chuẩn mực hơn, đồng thời chỉ ra những rủi ro hồi quy mà ít người để ý.

Nhóm nghiên cứu đã rà soát lại toàn bộ các bản vá do kỹ sư của họ viết trong khuôn khổ sáng kiến Patch the Planet (phối hợp cùng OpenAI) và được maintainer merge lên nhánh chính. Kết quả: trong hơn 130 PR, có tới 21 lỗi hồi quy được xác nhận — 16 lỗi chức năng, một lỗi hiệu năng và bốn lỗi ở khâu build/test. Đáng chú ý là không có lỗi nào phá vỡ lớp bảo vệ bảo mật, nhưng con số này đủ để thấy bài toán chất lượng bản vá đang nóng lên.

Vì sao bản vá bằng AI dễ sinh lỗi mới?

Theo định nghĩa trong bài, hồi quy (regression) là một khiếm khuyết mới do thay đổi mã nguồn gây ra, làm hỏng hành vi vốn đúng và được hỗ trợ, trên một đường thực thi mà người dùng hoặc kẻ tấn công thực sự có thể chạm tới.

Quá trình rà soát của Trail of Bits diễn ra khá "ồn ào": một agent tìm các hồi quy tiềm năng, xác nhận từng cái bằng một proof-of-concept (PoC) chạy trước và sau khi thay đổi, rồi chuyển kết quả cho kỹ sư người thật xem xét. Trong một lần chạy, hệ thống đưa ra 58 ứng viên và có 21 cái đúng — tức độ chính xác khoảng 36%. Vì mỗi agent lại tiếp cận theo cách khác nhau, mỗi lần chạy lại sinh thêm một đống ứng viên mới để con người ngồi lọc.

Từ đó nhóm rút ra hai kết luận: muốn ít hồi quy hơn thì cần một cách viết bản vá chuẩn, với cùng bộ kiểm tra áp dụng mỗi lần; và muốn bắt được những hồi quy còn sót thì cần một cách kiểm tra chuẩn, có quy tắc rõ ràng về việc thế nào mới tính là hồi quy.

"Không có checklist cố định nào bắt được mọi hồi quy cả" — nhóm tác giả viết, nên họ thu thập lại dấu vết hoạt động của agent từ các phiên vá lỗi và dùng chính những bài toán mà phiên bản trước làm sai để kiểm thử phiên bản sau.

Sơ đồ vòng phản hồi tạo và đánh giá bản vá

Bốn nguyên tắc thiết kế plugin

Hai plugin patching-bugs và regression-hunt được xây dựng dựa trên bốn nguyên tắc chính:

• Hướng dẫn tối giản nhưng có quan điểm rõ ràng. Agent được tự do hành động, chỉ ghi lại đúng những phán đoán của Trail of Bits về thế nào là bản vá tốt, thế nào là hồi quy thật.
• Các bước dạng module. Không cần chạy cả plugin từ đầu đến cuối, các kỹ năng nhỏ có thể dùng chung hoặc tách riêng.
• Schema vào/ra chặt chẽ. Mỗi bước nhận và trả về một schema xác định gồm luận điểm, phiên bản mã nguồn, kiểm tra bắt buộc, bằng chứng thô và các câu hỏi mở. Điều này giúp các bước kiểm tra chéo kết quả của nhau thay vì tin tưởng vào phần tóm tắt.
• Proof-of-concept chạy thật cho mọi kết luận. Mọi kết luận phải dựa trên PoC chạy trên một instance đang hoạt động của dự án, truy cập qua chính các giao diện mà người dùng thật sẽ dùng. Không có PoC chạy thật thì kết quả bị coi là chưa kết luận.

Quy trình hoạt động của regression-hunt

regression-hunt: giảm 25% cảnh báo sai

Plugin regression-hunt hoạt động theo trình tự: liệt kê các hồi quy tiềm năng bằng cách lần theo phần mã đã thay đổi (diff) qua các hàm gọi đến các giao diện thực tế; tái hiện từng ứng viên trên bản triển khai thật; chạy lại PoC bằng một agent có ngữ cảnh mới; và cuối cùng là "thẩm định" xem bằng chứng thu được có đủ để kết luận hay không.

Điểm cốt lõi nằm ở việc định nghĩa hồi quy rất chặt. Gánh nặng chứng minh đặt lên vai agent: nó phải chứng minh rằng nghi vấn không phải là dương tính giả, không phải bản vá dở dang, không phải lỗi tiềm ẩn hay lỗi có sẵn từ trước. Chỉ khi vượt qua tất cả các "cổng" này, plugin mới báo cáo là hồi quy.

Nếu dự án có sẵn tài liệu mô hình mối đe dọa (threat model), hệ thống điều phối sẽ chủ động truyền tài liệu này làm ngữ cảnh chung cho từng bước, buộc mỗi agent phải đối chiếu lại trước khi kết luận.

Kết quả thử nghiệm trên tập 21 hồi quy đã xác nhận: regression-hunt cho ra ít hơn 25% cảnh báo sai so với một agent Codex thông thường được yêu cầu "review PR tìm hồi quy", với khoảng tin cậy 95% từ 14% đến 38%. Cái giá phải trả là một số hồi quy đã biết bị xếp vào diện "biên" — plugin nhận ra có thể có vấn đề nhưng không gom đủ bằng chứng để khẳng định chắc chắn.

patching-bugs: đúc kết từ hàng nghìn phiên làm việc

Plugin patching-bugs là bản chưng cất những thực hành tốt nhất mà Trail of Bits rút ra từ hàng nghìn phiên làm việc của kỹ sư với Codex. Ngoài các khả năng quen thuộc như tái hiện lỗi trên môi trường thật và đánh giá đối kháng độc lập, plugin này nhấn mạnh ba điểm:

• Chứng minh ba nhánh (three-arm proof): chạy cùng một kịch bản tái hiện trên ba trạng thái — mã gốc phải lỗi, mã đã vá phải chạy đúng, và khi gỡ bỏ bản vá hoàn toàn thì phải lỗi trở lại. Việc "hồi sinh" lỗi bằng cách gỡ bản vá là bằng chứng mạnh mẽ rằng chính bản vá đã sửa được lỗi, chứ không phải môi trường hay bài test thay đổi.
• Sửa theo bất biến (invariant-guided repair): bản vá cố gắng sửa cái bất biến bảo mật bị vi phạm ở gốc rễ thay vì chỉ vá đúng một ca lỗi cụ thể, nhờ đó có thể áp dụng cho các biến thể khác của cùng một lớp lỗi.
• Tích hợp phân tích hồi quy: plugin bắt buộc phải chạy regression-hunt để mọi bản vá đều đi qua cùng một quy trình kiểm tra sai sót.

Quy trình vá lỗi của patching-bugs

Hai tệp "kim chỉ nam" cho mọi dự án

Điều đáng chú ý là hai plugin này hoạt động tốt hơn hẳn khi kho mã nguồn có thêm hai tài liệu:

• THREAT_MODEL.md — cho agent biết thế nào được tính là lỗ hổng hay hồi quy: tài sản nào quan trọng, ranh giới tin cậy nằm ở đâu, cấu hình nào được hỗ trợ, và bằng chứng nào là cần thiết cho một báo cáo lỗi hợp lệ.
• PATCHING_GUIDELINES.md (hoặc AGENTS.md) — cho agent biết dự án muốn bản vá được viết thế nào: cách build và test, độ lớn của bản vá, đặt bản vá ở đâu, cách trình bày thay đổi đề xuất và bài test hồi quy phải chứng minh được điều gì.

Trong dự án Patch the Planet với GPAC, các kỹ sư của Trail of Bits đã viết hẳn một mô hình mối đe dọa và một kỹ năng vá lỗi riêng cho dự án, ghi lại cách maintainer của GPAC muốn lỗi được tái hiện ra sao. Các dự án Liboqs và validator.js cũng đã công bố mô hình mối đe dọa theo hướng dẫn này.

Góc nhìn cho cộng đồng mã nguồn mở Việt Nam

Với các nhóm phát triển phần mềm và dự án mã nguồn mở tại Việt Nam, câu chuyện này mang lại vài gợi ý thực tế. Thứ nhất, dùng AI để vá lỗi không còn là chuyện "bấm nút là xong" — chất lượng bản vá phụ thuộc rất nhiều vào việc dự án có tài liệu hóa bối cảnh bảo mật và quy ước code hay không. Thứ hai, nguyên tắc PoC chạy thật trên môi trường thật rất đáng học hỏi: một bản vá không có bằng chứng tái hiện được trước và sau khi sửa thì chưa thể coi là đáng tin.

Cuối cùng, khi AI đẩy tốc độ phát hiện lỗ hổng lên rất cao, kỹ thuật kiểm tra hồi quy bài bản sẽ trở thành kỹ năng bắt buộc của đội ngũ bảo mật, chứ không chỉ là việc của riêng các dự án lớn.

Cả hai plugin đều đang được các kỹ sư Trail of Bits sử dụng trong công việc Patch the Planet. Nhóm cho biết sẽ tiếp tục thu thập dữ liệu sử dụng thực tế, xây dựng bộ đánh giá cho patching-bugs, phân tích dữ liệu dấu vết agent ở mức chi tiết và làm plugin linh hoạt hơn — ví dụ cho phép maintainer chọn giữa việc tối giản bộ bản vá hay nới lỏng quy tắc của regression-hunt để phát hiện nhiều ứng viên hơn.