Cứ vài tuần lại có vendor tuyên bố AI coding agent giờ “viết được code bảo mật” hay “tự động vá lỗ hổng”. Tôi đã ngừng tin những tuyên bố này ngay lập tức, vì phần lớn được đo trên benchmark tổng hợp mà model gần như đã học thuộc. Innodata vừa ra mắt thứ khác biệt: một benchmark xây từ hàng nghìn CVE thật, từng bị khai thác trong lịch sử, được replay như tấn công sống nhắm vào bản sao cô lập của phần mềm có lỗ hổng, trải rộng Python, TypeScript, JavaScript, Rust, C, và Go.

Phương pháp luận mới là phần thú vị. Kỹ sư bảo mật của Innodata lấy từng lỗ hổng thật, dựng lại thủ công trong môi trường offline cô lập, rồi chạy lại đúng cuộc tấn công gốc. Patch của AI agent chỉ được tính là thành công nếu cuộc tấn công không còn hiệu quả và phần mềm vẫn hoạt động đúng. Đây là tiêu chuẩn khó hơn hẳn so với “linter hài lòng” hay “unit test pass” — phần lớn lỗ hổng bảo mật không bị hai thứ đó bắt được.

Con số quan trọng

Khi được chỉ rõ vị trí lỗ hổng, model open-weight tốt nhất vá được tối đa 23% lỗi. Không có gợi ý — không biết bug nằm đâu, đây là kịch bản thực tế của một agent bảo mật quét codebase — con số đó thấp hơn nữa trước khi fine-tune: 18.4%. Sau một vòng fine-tune trên một phần dữ liệu của bộ suite, tỷ lệ vá thành công không gợi ý tăng lên 41.2%.

Dừng lại một giây để ngẫm điều này. Ngay cả với fine-tuning riêng cho nhiệm vụ này, trên một benchmark model được huấn luyện hướng tới, khả năng tự vá lỗ hổng thật không gợi ý cũng chỉ đạt trần khoảng 41%. Đó là trần cho một model được tune đúng theo phân phối của bài test. Codebase production của bạn, chạy framework và pattern mà dữ liệu huấn luyện không phủ tới, sẽ nằm dưới mức đó.

Vì sao điều này quan trọng cho cách bạn chạy code review

Tôi từng chứng kiến các team bắt đầu đối xử với fix bảo mật do AI tạo ra giống như code tính năng do AI tạo — lướt qua, chạy CI, merge nếu xanh. Đó là sai lầm đặc biệt nghiêm trọng với patch bảo mật, vì lý do mà benchmark này làm rõ: test pass không đồng nghĩa lỗ hổng đã được đóng lại. Một patch có thể khiến triệu chứng báo cáo biến mất (crash được fix, lỗi bị suppress) trong khi con đường khai thác thực sự vẫn mở, hoặc tạo ra một biến thể hẹp hơn nhưng vẫn khai thác được của cùng lỗ hổng. Phương pháp chấm điểm của Innodata — replay đúng cuộc tấn công vào đúng patch — là cách nghiêm ngặt duy nhất để biết sự khác biệt, và đó không phải thứ pipeline CI của bạn làm mặc định.

Cụ thể, đây là những gì tôi sẽ thay đổi trong workflow của team dựa trên dữ liệu này:

1. Đưa patch bảo mật do AI tạo qua lane review khác với PR tính năng. Không phải một checkbox đóng dấu qua loa — mà là một reviewer thứ hai thực sự có bối cảnh bảo mật, hoặc một lượt quét lại SAST/DAST nhắm cụ thể vào nhóm CVE mà patch tuyên bố đã fix.

2. Đừng tin “lỗ hổng đã được fix” từ chính agent đã viết ra fix đó. Tự đánh giá là tín hiệu yếu nhất ở đây. Nếu agent nói “đã vá”, hãy xác minh bằng scanner độc lập hoặc bước replay-exploit — đúng nguyên tắc Innodata dùng để xây benchmark, chỉ là ở quy mô của bạn.

# Pattern xác minh tối thiểu cho patch bảo mật do AI tạo
git diff main --stat  # kiểm tra phạm vi: patch có đụng nhiều hơn cần thiết không?
semgrep --config=p/security-audit ./src  # lượt static pass độc lập
# nếu có PoC hoặc bản tái hiện CVE, replay nó vào bản build đã patch
./repro-exploit.sh --target ./build/patched

3. Theo dõi tỷ lệ vá thành công theo nhóm CVE trong nội bộ. Nếu agent của bạn xử lý ổn patch SQL injection nhưng gặp khó với lỗi loại race-condition (một khoảng trống phổ biến — race condition đòi hỏi suy luận về thứ tự thực thi, không chỉ pattern-matching với hình dạng code đã biết là xấu), đó chính là tín hiệu nên định tuyến một số nhóm bug về review chỉ-con-người.

4. Xem “41.2% sau fine-tuning” là trần, không phải sàn, khi vendor chào bạn một công cụ bảo mật AI. Hỏi họ đang trích dẫn benchmark nào, và liệu nó có giống phương pháp replay-tấn-công của Innodata hay chỉ là tỷ lệ pass của static-analysis nhẹ nhàng hơn. Khoảng cách giữa hai con số đó thường chính là khoảng cách giữa marketing và thực tế.

Kết luận thành thật

AI coding agent thực sự hữu ích như một lượt xử lý đầu cho việc khắc phục bảo mật — phân loại, gợi ý hướng đi, soạn thử một patch — và thực sự rủi ro nếu được xem là thẩm quyền cuối cùng. Dữ liệu ở đây không phải lý lẽ chống lại việc dùng chúng; mà là lý lẽ chống lại việc gỡ bỏ điểm kiểm tra con người xác minh rằng fix thực sự đóng được lỗ hổng. 41% thành công không gợi ý, trên một benchmark đã được tune có lợi cho model, là lý do đủ tốt để giữ điểm kiểm tra đó thêm một thời gian nữa.