Những yếu tố ảnh hưởng đến khả năng phát hiện lỗ hổng của AI coding agent

Khả năng tìm lỗ hổng của các AI coding agent như Claude Code không cố định. Cùng một repository và cùng một model, kết quả vẫn có thể khác nhau đáng kể tùy vào rào chắn an toàn, quyền truy cập, phạm vi yêu cầu, công cụ được sử dụng, ngân sách thực thi và cách chúng ta định nghĩa đầu ra.

1. Rào chắn an toàn và quyền thực thi

Yếu tố đầu tiên là các cơ chế an toàn của hệ thống. Tuy nhiên, cần phân biệt hai lớp khác nhau:

• Safety guardrails quyết định loại yêu cầu an ninh mạng nào model được phép hỗ trợ.
• Permission và sandbox quyết định agent được đọc file nào, chạy lệnh nào, truy cập mạng hay môi trường nào.

Một yêu cầu kiểm tra phòng thủ hợp lệ vẫn có thể cho kết quả kém nếu agent không được đọc đủ repository, không thể chạy build, test, dependency scanner hoặc công cụ phân tích tĩnh. Trong Manual mode, Claude Code mặc định bắt đầu với quyền chỉ đọc và phải xin phép đối với nhiều thao tác; sandbox cũng có thể giới hạn filesystem và network. Vì vậy, đôi khi thứ làm giảm chất lượng scan không phải model “không biết”, mà là model không có đủ quyền hoặc dữ liệu để kiểm chứng giả thuyết. Claude Code Security documentation

2. Mức độ hiểu code và ngân sách suy luận

Để phát hiện một lỗi bảo mật thực sự, agent thường phải:

1. Xác định entry point.
2. Theo dõi luồng dữ liệu từ source đến sink.
3. Hiểu authentication, authorization và trust boundary.
4. Kiểm tra các lớp validation hoặc sanitization trung gian.
5. Xác định điều kiện khai thác.
6. Tự phản biện để loại bỏ false positive.

Với repository lớn, đây là một bài toán tìm kiếm rất rộng. Agent phải cân bằng giữa độ sâu phân tích, thời gian phản hồi, số lượt sử dụng công cụ, giới hạn context và ngân sách token.

Khi ngân sách không đủ hoặc không có tiêu chí hoàn thành rõ ràng, agent có xu hướng ưu tiên những đường dẫn dễ đọc và các lỗi dễ nhận diện. Điều này không hẳn là “lười” theo nghĩa con người, mà là một dạng early stopping: agent đã tìm được một số kết quả có vẻ đủ để trả lời và không có chỉ dẫn buộc nó phải tiếp tục chứng minh độ bao phủ.

Context window cũng không đồng nghĩa với khả năng hiểu toàn bộ codebase cùng lúc. Lịch sử cũ có thể được compact thành bản tóm tắt; các chi tiết quan trọng như điều kiện kiểm tra quyền hoặc quan hệ giữa hai module có thể bị giảm độ nổi bật. Claude Code context window

3. Model, chế độ suy luận và cấu hình agent

Không phải mọi model hoặc cấu hình chạy đều có khả năng phân tích bảo mật như nhau. Kết quả còn phụ thuộc vào:

• Phiên bản model.
• Mức effort hoặc reasoning budget.
• Giới hạn số lượt agent được phép thực hiện.
• Giới hạn thời gian và token.
• Có cho phép agent chia nhỏ nhiệm vụ hay không.
• Cơ chế compact context.
• Chiến lược chọn và sử dụng công cụ.

Một agent bị giới hạn ở vài lượt thường chỉ đủ khả năng triage. Một cuộc audit cần nhiều vòng đọc code, hình thành giả thuyết, truy vết và kiểm chứng.

4. Skills và công cụ thực sự được sử dụng

Có skill mạnh không có nghĩa là skill đó chắc chắn được sử dụng. Claude có thể tự chọn skill dựa trên mô tả và ngữ cảnh, nhưng cũng có thể bỏ qua nếu nó cho rằng yêu cầu có thể được giải quyết bằng cách đọc code thủ công.

Tài liệu Claude Code xác nhận rằng skills có thể được model tự động gọi khi phù hợp, nhưng cũng có thể được người dùng gọi trực tiếp bằng tên. Chất lượng phần mô tả của skill ảnh hưởng đến khả năng nó được chọn; skill cũng phải được load đúng và có quyền sử dụng các công cụ cần thiết. Claude Code Agent Skills

Do đó, nếu muốn một quy trình có thể lặp lại, prompt nên chỉ định rõ:

• Skill hoặc workflow phải sử dụng.
• Công cụ cần chạy.
• Scenario áp dụng từng công cụ.
• Cách xử lý khi công cụ không chạy được.
• Yêu cầu đối chiếu kết quả tool với phân tích thủ công.

Nếu không, agent có thể đọc một số file bằng Read, Grep hoặc search thủ công. Cách này tiêu tốn nhiều token nhưng vẫn dễ bỏ sót những đường dẫn ít nổi bật.

5. Phạm vi và độ rõ ràng của yêu cầu

“Kiểm tra security cho repository này” là một yêu cầu quá rộng. Security có thể bao gồm:

• Authentication và session management.
• Authorization, IDOR và privilege escalation.
• Injection.
• SSRF, XSS, CSRF và deserialization.
• Secrets và cryptography.
• Dependency hoặc supply-chain risk.
• Race condition và business-logic abuse.
• Cloud/IaC, container và CI/CD.
• Multi-tenant isolation.
• Logging, privacy và data exposure.

Nếu không có threat model, phạm vi và tiêu chí hoàn thành, agent phải tự đoán người dùng muốn gì. Để phản hồi trong thời gian hợp lý, nó thường ưu tiên các low-hanging fruit như hard-coded secret, SQL injection trực tiếp, cấu hình nguy hiểm hoặc thiếu validation rõ ràng. Sau khi tìm được vài vấn đề, nó có thể kết luận scan mà chưa kiểm tra các nhóm lỗi khó hơn như broken authorization hoặc business logic.

6. Chất lượng context về hệ thống

Source code không phải lúc nào cũng thể hiện đầy đủ hành vi thật của hệ thống. Agent cần biết thêm:

• Ứng dụng được triển khai như thế nào.
• Thành phần nào tiếp xúc Internet.
• Người dùng và attacker model là ai.
• Dữ liệu nào nhạy cảm.
• Những trust boundary quan trọng.
• Cấu hình production có khác local hay không.
• Các biện pháp kiểm soát nằm ngoài repository, chẳng hạn API gateway, WAF hoặc IAM.

Thiếu những thông tin này, agent có thể đánh giá quá cao một vấn đề đã được chặn ở tầng hạ tầng, hoặc bỏ sót một vấn đề chỉ xuất hiện trong cấu hình production.

7. Khả năng build, chạy và kiểm chứng

Đọc code chỉ tạo ra giả thuyết. Chất lượng finding tăng đáng kể khi agent có thể:

• Build ứng dụng.
• Chạy unit và integration test.
• Tạo test case hoặc proof of concept an toàn.
• Kiểm tra dependency và cấu hình.
• Quan sát runtime behavior.
• Truy vết dữ liệu qua nhiều service.
• Thử bác bỏ finding trước khi báo cáo.

Anthropic mô tả Claude Code Security là một quy trình nhiều giai đoạn, trong đó mỗi finding được xem xét lại để chứng minh hoặc bác bỏ trước khi trình cho người dùng. Điều này cho thấy “tìm thấy đoạn code đáng ngờ” và “xác nhận một lỗ hổng có thể khai thác” là hai mức chất lượng khác nhau. Anthropic: Claude Code Security

Nếu môi trường không chạy được, dependency thiếu hoặc test không phản ánh production, kết quả sẽ thiên về suy đoán và có nhiều false positive hơn.

8. Cấu trúc và tiêu chuẩn của đầu ra

Output mơ hồ thường dẫn đến quá trình scan mơ hồ. Nếu chỉ yêu cầu “liệt kê security issues”, agent có thể trả về một số nhận xét chung và coi nhiệm vụ đã hoàn thành.

Một finding tốt nên bắt buộc có:

• CWE hoặc nhóm lỗ hổng.
• Severity và confidence.
• File, dòng code và execution path liên quan.
• Source, sink và trust boundary.
• Điều kiện tiên quyết để khai thác.
• Tác động thực tế.
• Bằng chứng hoặc test tái hiện.
• Những biện pháp kiểm soát đã kiểm tra.
• Hướng khắc phục.
• Phân biệt rõ giữa confirmed, likely và needs verification.

Khi schema đầu ra chặt chẽ, agent buộc phải làm nhiều việc hơn để chứng minh từng finding, thay vì chỉ nêu các đoạn code “có mùi”.

9. Chiến lược phân chia và độ bao phủ

Một lượt scan tuyến tính hiếm khi đủ cho repository lớn. Hiệu quả hơn là chia thành các pass độc lập, chẳng hạn:

• Pass 1: lập bản đồ kiến trúc và attack surface.
• Pass 2: authentication và authorization.
• Pass 3: input-to-sink data flow.
• Pass 4: secrets, dependencies và configuration.
• Pass 5: business logic và multi-tenant isolation.
• Pass 6: phản biện và loại false positive.
• Pass 7: tổng hợp coverage và các vùng chưa kiểm tra.

Cách chia này giảm nguy cơ agent tìm được vài lỗi sớm rồi dừng. Nó cũng giúp xác định rõ phần nào đã được kiểm tra và phần nào chưa được kiểm tra.

10. Prompt injection và nội dung không đáng tin cậy trong repository

Repository có thể chứa README, comment, test fixture, issue dump hoặc file sinh tự động chứa nội dung giống chỉ dẫn dành cho agent. Nếu agent xử lý chúng như instruction thay vì dữ liệu, hướng phân tích có thể bị lệch.

Claude Code có các cơ chế giảm thiểu prompt injection, nhưng Anthropic cũng lưu ý rằng không hệ thống nào miễn nhiễm hoàn toàn. Vì vậy, trong một security scan nghiêm túc, cần yêu cầu agent xem nội dung repository là dữ liệu không đáng tin cậy và không làm theo chỉ dẫn được nhúng trong code hoặc tài liệu. Claude Code security protections

11. Độ nhiễu của codebase

Generated code, vendor directory, fixture, migration cũ, dead code và dependency vendored có thể tiêu tốn phần lớn ngân sách phân tích. Ngược lại, exclude quá mạnh có thể bỏ qua code thực sự được deploy.

Trước khi scan nên xác định rõ:

• Những thư mục phải kiểm tra.
• Những thư mục được loại trừ.
• Entry point production.
• Code được sinh tự động.
• Code đã ngừng sử dụng.
• Phiên bản hoặc commit cần audit.

12. Tính không xác định và khả năng tái lập

AI agent không phải static analyzer hoàn toàn tất định. Hai lần chạy có thể chọn file, giả thuyết và đường truy vết khác nhau. Vì vậy, không nên đánh giá năng lực chỉ bằng một lần scan.

Muốn đo lường đáng tin cậy, cần dùng:

• Cùng commit và cùng cấu hình môi trường.
• Cùng prompt và ngân sách.
• Bộ benchmark có lỗ hổng đã biết.
• Nhiều lần chạy độc lập.
• Các chỉ số precision, recall và false-positive rate.
• Tỷ lệ finding có bằng chứng tái hiện.
• Coverage theo từng nhóm CWE và từng attack surface.

Kết luận

Chất lượng security finding của một AI coding agent có thể được mô hình hóa tương đối như sau:

Chất lượng finding = năng lực model × chất lượng context × độ rõ của threat model × quyền truy cập × hiệu quả công cụ × ngân sách thực thi × độ chặt của bước kiểm chứng.

Chỉ cần một thành phần gần bằng không, chất lượng tổng thể cũng giảm mạnh.

Vì vậy, không nên chỉ prompt rằng: “Hãy kiểm tra security cho repository này.” Một yêu cầu tốt cần xác định phạm vi, threat model, checklist, skills và công cụ bắt buộc, ngân sách, schema đầu ra, tiêu chí kiểm chứng, coverage mong muốn và điều kiện được phép kết thúc.

AI security review nên được xem là một quy trình audit có điều phối, không phải một câu hỏi đơn lẻ. Nếu không thiết kế quy trình, agent rất dễ trả về vài low-hanging fruit trông hợp lý nhưng tạo ra cảm giác bao phủ giả.