# Kiểm chứng khả năng khai thác là gì?

Cyfendo · 20 tháng 10, 2026

Kiểm chứng khả năng khai thác là bước kiểm tra xem một lỗ hổng được báo cáo có thể bị khai thác hay không, bằng cách chạy một phiên bản an toàn của cuộc tấn công vào phần mã, trước khi có ai dành thời gian sửa nó. Các công cụ phân tích tĩnh báo cáo phần mã khớp với một mẫu rủi ro, và nhiều báo cáo trong số đó là cảnh báo giả: đầu vào đã được kiểm tra từ trước, phần mã không bao giờ chạy, hoặc framework đã escape đầu ra. Việc kiểm chứng tách những phát hiện mà kẻ tấn công có thể lợi dụng khỏi những phát hiện họ không thể lợi dụng.

## Vì sao phân tích tĩnh tạo ra dương tính giả

Kiểm thử bảo mật ứng dụng tĩnh (SAST) đọc mã nguồn mà không chạy nó. Nhờ vậy nó bao quát nhanh mọi dòng mã, nhưng phải suy luận những gì xảy ra khi chạy. Dương tính giả thường đến từ một trong các nguyên nhân sau:

- **Sanitizer không được nhận diện.** Đầu vào đi qua một hàm kiểm tra hợp lệ mà công cụ không biết đến, nên nó vẫn coi đầu vào là nguy hiểm.
- **Cơ chế bảo vệ của framework mà công cụ không mô hình hóa.** Nhiều template engine escape đầu ra và nhiều thư viện cơ sở dữ liệu tham số hóa truy vấn một cách tự động.
- **Thiếu ngữ cảnh.** Một route nằm sau bước kiểm tra quyền admin, một hàm chỉ được gọi với hằng số, một tính năng đã tắt trên production.
- **Mã không bao giờ được triển khai.** Test fixture, mã ví dụ và mã chết vẫn bị quét như mã production.
- **So khớp mẫu.** Các quy tắc khớp với hình dạng của mã rủi ro sẽ gắn cờ mọi trường hợp có hình dạng đó.

Khi không thể quyết định, công cụ thường vẫn báo cáo, vì bỏ sót một lỗ hổng tốn kém hơn một cảnh báo giả.

## Cảnh báo giả gây tốn kém những gì

Mỗi cảnh báo đều tốn thời gian của một người để lần theo và loại bỏ, và tỷ lệ dương tính giả cao còn khiến cả nhóm quen với việc phớt lờ công cụ. Một nghiên cứu năm 2013 của Johnson và các cộng sự, “Why Don't Software Developers Use Static Analysis Tools to Find Bugs?”, cho thấy dương tính giả và cách trình bày cảnh báo nằm trong số những lý do chính khiến lập trình viên tránh dùng các công cụ này. Nền tảng phân tích nội bộ của Google, Tricorder, yêu cầu các bước kiểm tra của nó giữ tỷ lệ dương tính giả thực tế dưới 10%, đo bằng tần suất lập trình viên đánh dấu một cảnh báo là không hữu ích.

## Đo độ chính xác của trình quét

Hai con số mô tả một trình quét:

- **Precision (độ chuẩn xác):** tỷ lệ các vấn đề được báo cáo là có thật.
- **Recall (độ bao phủ):** tỷ lệ các vấn đề có thật được báo cáo.

[OWASP Benchmark](https://owasp.org/www-project-benchmark/) đo cả hai bằng hàng nghìn ca kiểm thử nhỏ, khoảng một nửa được cố ý tạo lỗ hổng và một nửa cố ý an toàn, nên một công cụ không thể đạt điểm cao chỉ bằng cách gắn cờ mọi thứ. Benchmark này chấm điểm một công cụ bằng tỷ lệ dương tính thật trừ đi tỷ lệ dương tính giả (chỉ số Youden).

Trên OWASP Benchmark cho Java (2,740 ca kiểm thử), Cyfendo đưa ra 1,381 cảnh báo, trong đó 1,331 cảnh báo là có thật: precision 96.38%, recall 94.06% và tỷ lệ dương tính giả 3.77%. Trên benchmark cho Python (1,230 ca), tỷ lệ dương tính giả là 3.47%. [Trang benchmark](/benchmarks) có đầy đủ các con số và phần so sánh với các công cụ khác. Những con số này chỉ đo khả năng phát hiện; benchmark không kiểm tra bước kiểm chứng trong sandbox được mô tả bên dưới.

## Khả năng tiếp cận và khả năng khai thác

**Khả năng tiếp cận** đặt câu hỏi liệu đầu vào do kẻ tấn công kiểm soát có đến được phần mã bị gắn cờ hay không. Nó loại bỏ các phát hiện trong mã chết và trong các hàm không được gọi ở đâu cả. Tuy vậy, mã tiếp cận được vẫn có thể an toàn: đầu vào có thể đã được kiểm tra trên đường đi, hoặc lệnh gọi nguy hiểm có thể chỉ nhận giá trị từ một danh sách cố định.

**Khả năng khai thác** đặt câu hỏi liệu một đầu vào cụ thể có tạo ra một kết quả gây hại cụ thể hay không, chẳng hạn trả về bản ghi của khách hàng khác hoặc chạy một lệnh trên máy chủ. Chạy cuộc tấn công là cách duy nhất để trả lời câu hỏi này một cách chắc chắn.

## Các cách kiểm chứng một phát hiện

1. **Phân loại thủ công.** Một kỹ sư bảo mật đọc mã và quyết định. Chính xác, chậm và nằm ngoài tầm với của phần lớn các nhóm nhỏ.
2. **Phân tích khả năng tiếp cận.** Tự động và nhanh, nhưng không thể tách trường hợp tiếp cận được mà an toàn khỏi trường hợp tiếp cận được và khai thác được.
3. **Kiểm thử ứng dụng đang chạy.** Các trình quét động và bài kiểm thử xâm nhập tấn công một ứng dụng đã triển khai từ bên ngoài. Thuyết phục khi chúng thành công, nhưng cần một môi trường đã triển khai và chỉ thấy những gì lộ ra bên ngoài.
4. **Bằng chứng khái niệm trong sandbox.** Chạy cuộc tấn công cụ thể vào một bản sao dùng một lần của mã và quan sát kết quả. Việc này diễn ra tự động và trước khi triển khai.

## Cyfendo kiểm chứng phát hiện như thế nào

1. **Lần theo.** Cyfendo theo dõi đầu vào không đáng tin cậy đi qua mã trên nhiều tệp và gắn cờ các đường đi mà đầu vào đó đến được truy vấn cơ sở dữ liệu, đường dẫn tệp, lệnh shell hoặc dữ liệu của người dùng khác mà chưa được làm an toàn.
2. **Tấn công trong sandbox.** Với mỗi đường đi bị gắn cờ, Cyfendo viết một cuộc tấn công bằng chứng khái niệm và chạy nó vào một bản sao dùng một lần của ứng dụng. Các dịch vụ bên ngoài được thay bằng các thành phần thay thế; ứng dụng Supabase được cung cấp một Supabase thay thế có hai người dùng thử, dựng từ các migration của dự án.
3. **So sánh với một yêu cầu vô hại.** Cuộc tấn công phải tạo ra kết quả gây hại, và một yêu cầu vô hại trên cùng đường đi phải hoạt động bình thường. Điều này ngăn việc một lần sập ứng dụng hoặc một trang lỗi bị tính là bằng chứng.
4. **Báo cáo.** Các vấn đề tái hiện được sẽ được báo cáo kèm các bước sửa. Những phát hiện không tái hiện được vẫn được liệt kê trong dashboard.
5. **Kiểm thử bản sửa.** Bản vá được kiểm tra bằng cách chạy lại cuộc tấn công ban đầu vào mã đã vá và chạy các bài kiểm thử của dự án, và mỗi bản vá đều nêu rõ nó đã được kiểm thử như thế nào.

## Giới hạn

- **Một phát hiện chưa được tái hiện vẫn có thể là thật.** Một số cuộc tấn công phụ thuộc vào cấu hình production, hành vi thực của dịch vụ bên thứ ba, hoặc thời điểm mà sandbox không tái hiện được, nên các phát hiện chưa được tái hiện vẫn nằm trong danh sách trên dashboard.
- **Mã phải chạy được.** Việc kiểm chứng phụ thuộc vào việc có sẵn bộ công cụ của ngôn ngữ và có các thành phần thay thế cho những dịch vụ mà ứng dụng sử dụng.
- **Nó kiểm thử mã, không kiểm thử ý định.** Nó có thể cho thấy người dùng B đọc được bản ghi của người dùng A. Còn việc các quản lý có nên xem bản ghi của nhóm mình hay không là quy tắc mà chỉ chủ ứng dụng mới có thể định nghĩa.

Cyfendo kiểm chứng phát hiện theo cùng một cách, dù đang quét một kho mã nguồn, chạy từ CLI hay được gọi bởi một công cụ lập trình AI như [Cursor](/docs/integration/cursor), [Claude Code](/docs/integration/claude-code) hoặc [Lovable](/docs/integration/lovable).

Source: https://cyfendo.com/vi/blog/what-is-exploitability-validation