Trong công việc security, tôi ngày càng sử dụng AI nhiều hơn để hỗ trợ đọc source code, mở rộng attack surface, gợi ý test case và rà soát các dấu hiệu bất thường. AI có thể giúp tiết kiệm đáng kể thời gian, nhưng kết quả của nó thường được trình bày rất thuyết phục, ngay cả khi dữ kiện chưa đầy đủ hoặc chuỗi suy luận còn thiếu.
Vì vậy, trong quá trình review, tôi thường không bắt đầu bằng câu hỏi “kết quả này nghe có hợp lý không?” mà xem mỗi kết luận của AI như một giả thuyết cần được kiểm chứng. Bài viết này chia sẻ một số cách tôi sử dụng để phản biện các kết quả do AI tạo ra, đặc biệt trong bối cảnh security review. Đây không phải là một bộ tiêu chuẩn cố định; tùy loại tác vụ, phạm vi hệ thống và mức độ ảnh hưởng, reviewer có thể điều chỉnh độ sâu của quá trình kiểm tra.
Một số thuật ngữ được sử dụng trong bài
Bài viết sử dụng kết hợp thuật ngữ tiếng Việt và tiếng Anh vốn khá phổ biến trong công việc security. Để tránh hiểu khác nhau, các thuật ngữ chính được dùng với ý nghĩa sau:
| Thuật ngữ | Ý nghĩa trong bài viết |
|---|---|
| Reviewer | Người trực tiếp kiểm tra kết quả do AI tạo ra và chịu trách nhiệm đưa ra kết luận cuối cùng. Trong bối cảnh bài viết này, reviewer thường là security engineer, pentester, PSIRT member hoặc người có đủ kiến thức về hệ thống đang được đánh giá. Reviewer không nhất thiết là người đã viết prompt hay vận hành AI. |
| Claim | Một nhận định hoặc kết luận cụ thể do AI đưa ra và có thể được kiểm chứng độc lập. |
| Finding | Một vấn đề hoặc dấu hiệu bất thường được phát hiện trong quá trình review. Một finding do AI đưa ra mới chỉ là ứng viên cần xác minh, chưa mặc nhiên được xem là lỗ hổng. |
| Evidence | Bằng chứng dùng để hỗ trợ hoặc bác bỏ một claim, chẳng hạn source code, log, trace, tài liệu, request/response hoặc kết quả thử nghiệm. |
| PoC (Proof of Concept) | Kịch bản hoặc bước thử nghiệm tối thiểu nhằm chứng minh vấn đề có thể xảy ra trong điều kiện xác định. |
| False positive | Trường hợp AI báo cáo có vấn đề nhưng sau khi kiểm tra, vấn đề đó không tồn tại hoặc không thể xảy ra trong bối cảnh thực tế. |
| False negative | Trường hợp vấn đề thực sự tồn tại nhưng AI không phát hiện hoặc không báo cáo. |
| Attack surface | Những điểm mà attacker có thể tiếp cận hoặc tương tác với hệ thống, ví dụ: API, giao diện, deep link, file upload hoặc luồng xử lý dữ liệu. |
| Source–sink path | Đường đi của dữ liệu từ nơi tiếp nhận đầu vào (source) đến vị trí có thể phát sinh hành vi nhạy cảm hoặc nguy hiểm (sink). |
| Data flow/control flow | Cách dữ liệu hoặc luồng điều khiển di chuyển qua các function, component và lớp bảo vệ trong hệ thống. |
| Control | Cơ chế kiểm soát giúp ngăn chặn hoặc giảm thiểu rủi ro, chẳng hạn validation, authorization, sandbox hoặc cơ chế bảo vệ của framework. |
| Severity | Mức độ nghiêm trọng của vấn đề, được đánh giá dựa trên khả năng khai thác, quyền cần có, phạm vi ảnh hưởng và hậu quả thực tế. |
Trong phần còn lại của bài viết, từ reviewer được dùng theo nghĩa rộng nói trên, không chỉ giới hạn ở người thực hiện code review.
1. Bắt đầu từ từng kết luận cụ thể
Không nên chấm cả câu trả lời của AI là “đúng” hoặc “sai” trong một lần. Trước hết, cần tách nội dung thành những kết luận nhỏ có thể kiểm tra độc lập.
Chẳng hạn, nếu AI kết luận:
Endpoint này tồn tại lỗ hổng IDOR và người dùng có thể đọc dữ liệu của người khác.
Kết luận trên thực tế bao gồm nhiều nhận định:
- Endpoint nhận một định danh mà người dùng có thể kiểm soát.
- Định danh đó được dùng để truy xuất một đối tượng trong hệ thống.
- Hệ thống không kiểm tra quyền truy cập phù hợp.
- Người dùng thông thường có thể gọi endpoint.
- Dữ liệu thuộc người dùng khác thực sự được trả về.
- Dữ liệu được trả về có ý nghĩa về mặt bảo mật.
- Không có cơ chế bảo vệ nào khác ngăn hành vi khai thác.
AI có thể đúng khi mô tả một đoạn code nhưng vẫn sai khi kết luận về khả năng khai thác hoặc mức độ ảnh hưởng. Việc tách nhỏ giúp reviewer xác định chính xác phần nào đã được chứng minh, phần nào mới chỉ là suy đoán.
2. Khung phản biện CLAIM–EVIDENCE
Để tránh bỏ sót các bước quan trọng, tôi thường sử dụng CLAIM–EVIDENCE như một checklist khi rà soát kết quả AI:
| Thành phần | Nội dung cần xem xét | Câu hỏi chính |
|---|---|---|
| Claim | Xác định từng kết luận cụ thể | AI đang khẳng định điều gì? |
| Logic | Kiểm tra chuỗi suy luận | Kết luận có thực sự được suy ra từ dữ liệu không? |
| Assumption | Tìm các giả định ẩn | Điều kiện nào đang được AI mặc nhiên xem là đúng? |
| Independent evidence | Kiểm chứng bằng nguồn độc lập | Code, log, tài liệu hoặc thử nghiệm có xác nhận không? |
| Missing coverage | Xác định phần chưa được xem xét | Có nhánh xử lý, trường hợp biên hoặc phản ví dụ nào bị bỏ sót? |
| Error analysis | Phân loại sai sót | AI sai dữ kiện, sai logic, thiếu phạm vi hay suy diễn quá mức? |
| Negative test | Chủ động tìm cách bác bỏ | Điều kiện hoặc đầu vào nào có thể làm kết luận không còn đúng? |
| Trust decision | Quyết định cách sử dụng | Chấp nhận, kiểm chứng thêm hay bác bỏ? |
Đây không phải một framework tiêu chuẩn hay quy trình bắt buộc. Tôi sử dụng khung này chủ yếu để phân biệt rõ ba lớp: điều AI quan sát được, điều AI suy luận và điều đã được kiểm chứng trong thực tế.
3. Quy trình phản biện
Ghi lại đầu vào và điều kiện chạy
Trước khi đánh giá, cần lưu lại model và phiên bản, prompt, các công cụ hoặc skill đã sử dụng, source code hoặc commit được phân tích, giới hạn quyền truy cập, giới hạn token và kết quả thô của từng lần chạy.
Thông tin này đặc biệt quan trọng khi cần giải thích vì sao hai lần chạy cho ra kết quả khác nhau. Nếu không lưu điều kiện đầu vào, rất khó xác định sự khác biệt đến từ model, prompt, dữ liệu hay phạm vi truy cập.
Đối chiếu kết luận với bằng chứng
Mỗi kết luận quan trọng nên được đặt cạnh bằng chứng mà AI cung cấp và bằng chứng do reviewer kiểm tra độc lập.
| Kết luận | Bằng chứng AI cung cấp | Kiểm tra độc lập | Đánh giá |
|---|---|---|---|
| Không có kiểm tra quyền | AI trích dẫn một function | Kiểm tra thêm middleware và caller | Chưa đủ bằng chứng |
| UserA đọc được dữ liệu của UserB | AI suy luận từ source code | PoC thực tế nhận HTTP 403 | Không chính xác |
| Response có thể làm lộ dữ liệu riêng tư | AI chỉ ra field liên quan | Response thực tế xác nhận field được trả về | Đã xác nhận |
Nên ưu tiên bằng chứng theo mức độ trực tiếp. Kết quả tái hiện thực tế thường có giá trị cao hơn suy luận thuần túy; tiếp theo là log, trace, request/response, data flow đầy đủ trong source code, tài liệu chính thức và lịch sử issue hoặc commit. Nhận định của AI chỉ nên được xem là điểm khởi đầu cho việc kiểm tra.
Các trích dẫn do AI đưa ra cũng phải được mở và đọc lại. Một tài liệu có tồn tại không có nghĩa là tài liệu đó thực sự hỗ trợ cho kết luận đang được nêu.
Kiểm tra logic và giả định ẩn
Một số sai sót thường gặp gồm:
- Dữ kiện ban đầu đúng, nhưng kết luận cuối cùng không theo sau từ dữ kiện đó.
- Khả năng xảy ra về mặt lý thuyết bị mô tả thành khả năng khai thác thực tế.
- AI chỉ đọc một function mà bỏ qua caller, middleware hoặc cơ chế bảo vệ của framework.
- Không tìm thấy bằng chứng bị hiểu thành bằng chứng cho thấy sự việc không tồn tại.
- Kết quả từ một trường hợp riêng lẻ bị khái quát cho toàn bộ hệ thống.
- Mức độ ảnh hưởng được đưa ra khi chưa xác định rõ tác nhân, quyền cần có và tài sản bị ảnh hưởng.
- Một khuyến nghị best practice bị báo cáo như một lỗ hổng bảo mật.
- Cơ chế kiểm soát bù trừ ở tầng khác không được xem xét.
Chủ động tìm bằng chứng phản bác
Reviewer không nên chỉ tìm thông tin ủng hộ kết luận của AI. Cần thử thay đổi role, tenant, trạng thái, quyền sở hữu và điều kiện đầu vào; kiểm tra cả đường đi thành công lẫn đường đi thất bại; đồng thời tìm validation hoặc authorization ở các tầng trước và sau vị trí AI đã chỉ ra.
Đối với chức năng có nhiều giao diện, nên so sánh hành vi giữa UI, API, mobile, background job và dữ liệu cache. Với luồng lưu trữ hoặc hiển thị dữ liệu, việc kiểm tra cũng không nên dừng ở bước tạo mới mà cần đi qua toàn bộ chu trình, chẳng hạn: tạo → tải lại → chỉnh sửa → tải lại lần nữa.
Cách làm này giúp hạn chế thiên lệch xác nhận, tức là xu hướng chỉ chú ý đến những bằng chứng phù hợp với kết luận ban đầu.
Kiểm tra độ ổn định
Với các model có đầu ra không hoàn toàn xác định, nên chạy cùng một bài kiểm tra nhiều lần và so sánh:
Kết luận nào xuất hiện ổn định?
- Bằng chứng được trích dẫn có thay đổi không?
- AI có đưa ra các nguyên nhân gốc khác nhau không?
- Chỉ cần thay đổi cách viết prompt thì kết luận có thay đổi đáng kể không?
Tuy nhiên, việc một kết luận xuất hiện lặp lại không chứng minh rằng kết luận đó đúng. Độ ổn định chỉ là một tín hiệu về hành vi của model; nó không thể thay thế bằng chứng thực tế.
4. Chấm mức độ tin cậy
Để việc đánh giá giữa các reviewer nhất quán hơn, có thể chấm từng kết quả theo thang 0–2:
| Tiêu chí | 0 điểm | 1 điểm | 2 điểm |
|---|---|---|---|
| Tính chính xác | Sai | Đúng một phần | Đúng |
| Bằng chứng | Không có | Gián tiếp | Trực tiếp, có thể kiểm chứng |
| Mức độ bám sát nguồn | Bịa hoặc sai vị trí | Có liên quan nhưng thiếu | Đúng file, dòng code, API hoặc tài liệu |
| Logic | Không hợp lệ | Còn bước nhảy logic | Chuỗi suy luận đầy đủ |
| Phạm vi bao phủ | Bỏ sót phần quan trọng | Bao phủ luồng chính | Có nhánh phụ, trường hợp biên và control |
| Khả năng tái hiện | Không tái hiện được | Thiếu điều kiện | PoC hoặc test tái hiện ổn định |
| Đánh giá ảnh hưởng | Sai hoặc phóng đại | Chưa đủ rõ | Xác định rõ tác nhân, tài sản và hậu quả |
| Thừa nhận giới hạn | Khẳng định quá mức | Cảnh báo chung chung | Nêu rõ điều kiện và phần chưa chắc chắn |
Tổng điểm tối đa là 16:
- 14–16 điểm: chất lượng tốt, nhưng vẫn cần reviewer xác nhận trước khi sử dụng chính thức.
- 10–13 điểm: có giá trị như một đầu mối điều tra, cần bổ sung bằng chứng.
- 6–9 điểm: độ tin cậy thấp, nên phân tích lại.
- 0–5 điểm: không nên sử dụng làm căn cứ.
Điểm số chỉ hỗ trợ sàng lọc, không thay thế điều kiện bắt buộc. Chẳng hạn, một security finding không nên được xác nhận chỉ vì tổng điểm cao nếu chưa chứng minh được data flow, khả năng tiếp cận hoặc hành vi thực tế.
5. Áp dụng trong AI security review
Đối với kết quả rà soát bảo mật, một finding cần mô tả được đầy đủ chuỗi sau:
Entry point
→ Dữ liệu do attacker kiểm soát
→ Validation hoặc authorization
→ Quá trình truyền dữ liệu hay luồng điều khiển
→ Security-sensitive sink
→ Hành vi quan sát được
→ Ảnh hưởng cụ thểReviewer cần trả lời tối thiểu các câu hỏi sau:
- Attacker là ai và cần có quyền gì?
- Attack surface có thực sự truy cập được không?
- Dữ liệu đầu vào nào do attacker kiểm soát?
- Đường đi từ source đến sink có được chứng minh đầy đủ không?
- Hệ thống có validation, permission check hoặc cơ chế bảo vệ mặc định nào không?
- Có PoC hoặc test case tái hiện ổn định không?
- Kết quả mong đợi và kết quả thực tế khác nhau như thế nào?
- Dữ liệu hoặc tác vụ nào bị ảnh hưởng?
- Nguyên nhân gốc phù hợp với nhóm CWE nào?
- Phương án sửa xử lý nguyên nhân gốc hay chỉ chặn một payload cụ thể?
- Có khả năng bypass hoặc gây regression không?
- Đây là vulnerability, functional bug hay chỉ là khuyến nghị best practice?
Các nghiên cứu đánh giá công cụ phân tích mã nguồn cho thấy hiệu quả phát hiện lỗi thay đổi đáng kể tùy theo loại lỗi, độ phức tạp và đặc điểm của codebase. Công cụ thường tìm thấy lỗi đơn giản dễ hơn lỗi liên quan đến luồng xử lý phức tạp. Vì vậy, nếu muốn đánh giá khả năng security review của AI, cần thử nghiệm trên chính codebase và nhóm lỗi đại diện cho môi trường sử dụng thực tế.
6. Đánh giá AI ở cấp độ hệ thống
Nếu mục tiêu là so sánh các model, hoặc so sánh AI khi có và không có skill hỗ trợ, cần xây dựng một tập dữ liệu chuẩn gồm:
- Các lỗ hổng đã được xác nhận.
- Những đoạn code không có lỗ hổng nhưng dễ tạo false positive.
- Cả lỗi đơn giản và lỗi cần phân tích qua nhiều file.
- Nhiều nhóm lỗ hổng khác nhau.
- Trường hợp thiếu dữ liệu, trong đó câu trả lời phù hợp phải là “chưa đủ bằng chứng”.
Hai chỉ số cơ bản là precision và recall:
- Precision = TP / (TP + FP): trong số các finding mà AI phát hiện, có bao nhiêu finding thực sự chính xác.
- Recall = TP / (TP + FN): trong số các lỗ hổng thực sự tồn tại, AI phát hiện được bao nhiêu.
Trong đó, TP là true positive, FP là false positive và FN là false negative.
Hai chỉ số này chưa phản ánh hết chất lượng của một hệ thống AI hỗ trợ security review. Nên đo thêm:
- Tỷ lệ bằng chứng trỏ đúng file, dòng code hoặc luồng xử lý.
- Độ chính xác khi xác định nguyên nhân gốc.
- Tỷ lệ PoC tái hiện thành công.
- Mức độ thống nhất khi đánh giá severity.
- Tỷ lệ claim không có bằng chứng hỗ trợ.
- Khả năng từ chối kết luận khi dữ liệu chưa đủ.
- Mức độ ổn định giữa nhiều lần chạy.
- Chi phí, token, thời gian và số lượng file cần đọc.
Không nên đánh giá công cụ chỉ bằng số lượng finding. Một hệ thống tạo ra 20 finding nhưng có 15 false positive có thể kém hữu ích hơn một hệ thống chỉ đưa ra bốn finding nhưng tất cả đều có bằng chứng rõ ràng và tái hiện được.
7. Mẫu ghi nhận kết quả phản biện
Kết luận của AI: [Nêu claim cần kiểm tra]
Trạng thái:
Confirmed / Partially confirmed / Unverified / Rejected
Bằng chứng hỗ trợ:
Bằng chứng phản bác:
Giả định chưa được xác nhận:
Phạm vi AI đã kiểm tra:
Phạm vi còn bỏ sót:
Kết quả tái hiện:
Nguyên nhân gốc:
Ảnh hưởng thực tế:
Mức độ tin cậy:
High / Medium / Low
Kết luận của reviewer:
[Chỉ xác nhận nội dung đã có bằng chứng độc lập.]
Hành động tiếp theo:
[Bổ sung log, kiểm tra caller, tạo PoC, mở rộng regression test...]Kết luận
Từ góc nhìn của người làm security, tôi cho rằng kết quả AI nên được xem là một đầu mối phân tích, không phải kết luận cuối cùng. Giá trị lớn nhất của AI nằm ở khả năng mở rộng phạm vi rà soát, gợi ý giả thuyết và hỗ trợ tìm bằng chứng. Trách nhiệm xác nhận vẫn thuộc về reviewer, đặc biệt khi kết quả được dùng để đăng ký lỗ hổng, đánh giá mức độ ảnh hưởng hoặc đưa ra quyết định có rủi ro cao.
Một kết luận chỉ nên được sử dụng chính thức khi đã trải qua ba bước: kiểm chứng bằng nguồn độc lập, chủ động tìm bằng chứng phản bác và tái hiện trong điều kiện phù hợp. Cách tiếp cận này không loại bỏ hoàn toàn sai sót của AI, nhưng giúp biến output của AI từ một câu trả lời có vẻ thuyết phục thành một kết quả có thể kiểm tra, giải thích và chịu trách nhiệm.