Rà soát pull request theo OWASP với AI: yêu cầu bằng chứng và test
Dùng AI để sàng lọc rủi ro bảo mật trong pull request, nhưng chỉ đưa cảnh báo vào review khi có dấu vết trong diff, kế hoạch kiểm chứng và bước xác minh của con người.
Một pull request thêm endpoint, sửa middleware xác thực hoặc đổi cách đọc cấu hình có thể trông hoàn toàn ổn nếu chỉ nhìn vào logic nghiệp vụ.
AI cũng có thể đưa ra các cảnh báo nghe thuyết phục nhưng không chỉ được dòng mã liên quan, không nêu cách kiểm chứng, cũng không gợi ý test. Những nhận xét như vậy khó giúp tác giả PR hành động.
Cách dùng AI hiệu quả hơn là coi nó như trợ lý lập giả thuyết: mọi cảnh báo cần đi kèm bằng chứng trong diff, kế hoạch kiểm chứng và phần việc còn lại cho reviewer.
OWASP Top 10 là tài liệu nâng cao nhận thức về các rủi ro quan trọng đối với ứng dụng web. Theo OWASP, phiên bản phát hành hiện tại là OWASP Top 10 2025. Đây là khung để đặt câu hỏi đúng khi review, không phải nhãn để AI tự kết luận rằng code an toàn hoặc có lỗ hổng.
Đặt “hợp đồng” rõ ràng với AI reviewer
Một AI reviewer không nên chỉ nói: “Có thể có lỗ hổng bảo mật”. Nhận xét đó khiến tác giả PR không biết phải sửa gì và reviewer khó xác định mức độ ưu tiên.
Hãy coi mỗi phát hiện của AI là một giả thuyết. Chỉ đưa giả thuyết vào review khi nó có đủ bốn phần:
Bằng chứng trong PR: file, hàm, đoạn diff hoặc luồng dữ liệu liên quan.
Liên hệ OWASP: nhóm rủi ro cần đối chiếu trong OWASP Top 10 2025.
Cách kiểm chứng: điều kiện, đầu vào, hành vi an toàn mong đợi và dấu hiệu cần xem xét thêm.
Hành động tiếp theo: test tự động đề xuất hoặc bước xác minh thủ công.
Yêu cầu AI nói rõ khi thiếu dữ liệu. Ví dụ, nếu PR chỉ thay đổi controller nhưng không có cấu hình gateway, AI không nên kết luận endpoint bị lộ. Cách diễn đạt phù hợp hơn là: “Chưa thể xác minh từ diff; cần kiểm tra cấu hình gateway và chính sách xác thực.”
Cách làm này hữu ích với PR liên quan đến API, SDK, đăng nhập, tải tệp lên, template, truy vấn dữ liệu hoặc cấu hình triển khai. Đây đều là các khu vực mà thay đổi nhỏ có thể làm thay đổi ranh giới tin cậy của hệ thống.
Chuẩn bị ngữ cảnh: đừng bắt AI đoán từ diff
OWASP Top 10 là khung nhận thức rộng cho lập trình viên và bảo mật ứng dụng web. Nó không thay thế hiểu biết về kiến trúc của sản phẩm.
Trước khi nhờ AI review, hãy cung cấp ngữ cảnh tối thiểu:
Mục tiêu của PR theo mô tả tác giả.
Diff và các file liên quan trực tiếp đến thay đổi.
Ranh giới tin cậy: dữ liệu đến từ đâu, hệ thống nào gọi vào API.
Cơ chế xác thực và phân quyền kỳ vọng, nếu có liên quan.
Test hiện có và cách chạy test theo quy ước của team.
Những gì không có trong ngữ cảnh, như cấu hình hạ tầng hoặc giá trị secret lúc chạy.
Không cần gửi toàn bộ repository nếu giả thuyết chỉ liên quan đến một luồng cụ thể. Hãy giới hạn dữ liệu ở phần cần thiết và thay thông tin nhạy cảm bằng placeholder.
OWASP Cheat Sheet Series là dự án cung cấp các thực hành bảo mật cho người xây dựng ứng dụng. Khi cần kiểm tra sâu hơn một chủ đề, hãy đọc và tham chiếu cheat sheet trên website chính thức của dự án, thay vì trông chờ mô hình nhớ chính xác mọi quy tắc.
Tài liệu tham chiếu ở đây không quy định cách gọi mô hình AI, chi phí, chính sách lưu prompt hay quyền truy cập của công cụ review. Những yếu tố này phụ thuộc vào công cụ AI và chính sách nội bộ của từng đội.
Quy trình review theo ba vòng
Bước 1: Lập bản đồ rủi ro, chưa kết luận
Ở vòng đầu, yêu cầu AI phân loại các điểm cần xem xét. Mục tiêu là tạo danh sách kiểm tra ngắn, chưa phải tạo comment trên PR.
text
Bạn là trợ lý security review cho pull request.
Bối cảnh hệ thống:
<kiến trúc, luồng dữ liệu, ranh giới tin cậy>
Mục tiêu PR:
<mô tả PR>
Phần thay đổi:
<diff và các file liên quan>
Hãy đối chiếu với OWASP Top 10 2025.
Chỉ liệt kê các giả thuyết rủi ro có dấu vết trong phần thay đổi.
Với mỗi giả thuyết, trả về:
Mức độ tin cậy: cao / trung bình / thấp
Bằng chứng: file, hàm, đoạn logic trong diff
Dữ liệu hoặc điều kiện cần theo dõi
Thông tin còn thiếu để kết luận
Không khẳng định có lỗ hổng nếu bằng chứng chỉ là suy đoán.
Không đề xuất sửa code ở bước này.
Đầu ra mong muốn là bản đồ các điểm cần mở code để kiểm tra tiếp. Nếu AI không nêu được vị trí cụ thể trong diff, hãy loại phát hiện đó khỏi vòng sau hoặc yêu cầu nó làm lại với ngữ cảnh rõ hơn.
Bước 2: Biến phát hiện thành kịch bản có thể kiểm chứng
Chọn phát hiện có bằng chứng rõ nhất và yêu cầu AI chuyển nó thành kế hoạch kiểm thử. Đây là cổng chất lượng quan trọng: nếu không mô tả được điều kiện xảy ra rủi ro hoặc cách quan sát hành vi, phát hiện đó thường chưa đủ cơ sở để trở thành comment chặn PR.
text
Đây là phát hiện cần xác minh:
<phát hiện và bằng chứng từ bước trước>
Hãy tạo kế hoạch xác minh, không tự giả định các chi tiết không có trong ngữ cảnh.
Trả về đúng các mục:
Điều kiện để rủi ro xảy ra
Đầu vào hoặc hành động kiểm thử
Kết quả an toàn mong đợi
Kết quả cho thấy cần sửa
Test tự động nên thêm hoặc sửa
Bước xác minh thủ công
Điều gì test này không chứng minh được
Nếu không thể thiết kế test từ thông tin hiện có, ghi rõ dữ liệu còn thiếu.
Ví dụ, một PR có endpoint nhận dữ liệu đầu vào rồi chuyển giá trị đó qua lớp xử lý mới. Kết quả tốt không phải là câu “có nguy cơ injection”. Kết quả tốt phải chỉ ra dữ liệu đi từ đâu, được biến đổi ở đâu, điểm nào cần mở để kiểm tra, và test cần chứng minh hành vi nào.
Tránh đưa chi tiết có thể biến bình luận PR thành hướng dẫn khai thác. Điều cần giữ là cấu trúc kiểm chứng và yêu cầu an toàn, không phải mô tả kỹ thuật tấn công.
Bước 3: Chỉ viết comment khi đã có đường kiểm chứng
Sau khi reviewer mở code và xác nhận bối cảnh, dùng AI để chuẩn hóa comment. Comment nên ngắn, có thể hành động và cho phép người khác kiểm tra lại quyết định.
text
Viết comment pull request từ thông tin sau:
Bằng chứng đã được reviewer xác nhận:
<file, hàm, hành vi>
Rủi ro cần diễn đạt:
<liên hệ OWASP Top 10 2025>
Kịch bản kiểm chứng:
<điều kiện và kết quả>
Thay đổi hoặc test mong muốn:
<yêu cầu cụ thể>
Viết bằng giọng hợp tác.
Không nói rằng đây là lỗ hổng đã được xác nhận nếu chưa có tái hiện.
Nêu rõ phần nào cần reviewer con người xác minh.
Mẫu comment:
> Ở <file/hàm>, dữ liệu từ <nguồn> đi đến <đích> mà phần thay đổi hiện chưa cho thấy kiểm soát <điều kiện>. Cần đối chiếu luồng này với rủi ro OWASP liên quan.
>
> Đề nghị bổ sung test cho trường hợp <đầu vào/điều kiện> để xác nhận hệ thống trả về <hành vi an toàn>. Reviewer cũng cần kiểm tra <cấu hình hoặc quyền runtime> vì phần này không xuất hiện trong PR.
Reviewer vẫn phải tự xác minh gì?
AI chỉ có thể đánh giá những gì được cung cấp trong prompt, diff hoặc công cụ được cấp quyền truy cập. Vì vậy, reviewer vẫn nên:
Mở đúng file và xác nhận trích dẫn của AI không sai ngữ cảnh.
Chạy hoặc xem xét test do tác giả bổ sung.
Kiểm tra đường đi của dữ liệu qua các lớp không nằm trong diff.
Xác minh cấu hình, quyền và hành vi lúc chạy mà code review không thể hiện.
Ghi rõ trạng thái của mỗi phát hiện: đã chứng minh, đã giảm thiểu hoặc chưa đủ dữ liệu.
AI phù hợp để tăng độ phủ câu hỏi và giảm thời gian soạn review. Quyết định chấp nhận rủi ro vẫn cần thuộc về người hiểu sản phẩm, kiến trúc và môi trường triển khai.
Lưu ý về tài liệu và dữ liệu nhạy cảm
OWASP mô tả Top 10 là tài liệu nâng cao nhận thức, phản ánh đồng thuận rộng về các rủi ro trọng yếu của ứng dụng web. Đừng biến nó thành checklist máy móc: có PR không chạm đến nhóm rủi ro nào trong Top 10, và có rủi ro thực tế cần phân tích vượt ra ngoài diff.
Repository của OWASP Cheat Sheet Series nêu giấy phép CC BY-SA 4.0. Nếu tái sử dụng hoặc phân phối lại nội dung cheat sheet trong tài liệu nội bộ hay prompt template dùng chung, team nên kiểm tra yêu cầu tuân thủ giấy phép của mình. README cũng lưu ý các file Markdown trong repository là nguồn làm việc, không предназначены để được tham chiếu như tài liệu bên ngoài; ưu tiên website chính thức khi cần trích dẫn.
Cuối cùng, không đưa secret, token, dữ liệu khách hàng, cấu hình nhạy cảm hoặc toàn bộ log production vào prompt. Hãy dùng placeholder và chỉ gửi phần code cần thiết cho giả thuyết đang kiểm tra.
Checklist trước khi approve
[ ] AI có trích đúng file, hàm hoặc đoạn diff không?
[ ] Mỗi cảnh báo có liên hệ OWASP rõ ràng nhưng không bị gán nhãn quá đà?
[ ] Có test đề xuất hoặc lý do cụ thể vì sao chưa thể viết test?
[ ] Reviewer đã xác minh phần AI không thấy được, như cấu hình, quyền và hành vi runtime?
[ ] Comment nêu hành động cần làm, thay vì chỉ nêu lo ngại?
[ ] Prompt không chứa dữ liệu nhạy cảm?
Khi đáp ứng các điểm này, AI không chỉ tạo cảnh báo bảo mật. Nó trở thành trợ lý giúp đội chuyển từ nghi vấn sang quyết định review có bằng chứng.