Shannon AI pentester: khai thác thật rồi mới báo cáo

Nhiều đội ship code mỗi ngày nhưng vẫn giữ nhịp pentest cũ: thuê đơn vị bên ngoài một lần mỗi năm. Khoảng trống giữa hai lần pentest là nơi lỗ hổng mới sinh ra và nằm yên tới kỳ kiểm tra tiếp theo. Shannon lấp khoảng trống đó: AI pentester tự động chạy trước mỗi release, phân tích source code rồi khai thác thật trên app đang chạy, chỉ báo cáo những gì chứng minh được bằng proof-of-concept.

Vấn đề: ship liên tục, pentest 1 lần/năm

Pentest thủ công không theo kịp nhịp release

Pentest thủ công hiểu ngữ cảnh nghiệp vụ và chuỗi tấn công nhiều bước, nhưng nó đắt, cần đặt lịch trước nhiều tuần, và kết quả chỉ đúng với trạng thái app tại thời điểm kiểm tra.

Scanner truyền thống thiếu bằng chứng khai thác

Scanner truyền thống chạy nhanh và rẻ, nhưng báo cáo của chúng thường là danh sách nghi vấn chưa được chứng minh, và sau vài lần toàn false positive, đội kỹ thuật sẽ bỏ qua cả cảnh báo thật.

Ai cần Shannon trước mỗi release

Theo mình, nhóm hưởng lợi rõ nhất là đội backend và DevOps đã có staging, ship thường xuyên, và đang dùng AI coding agent như Claude Code hay Cursor, cùng sysadmin và homelab self-hoster muốn rà soát app trước khi mở ra internet.

Shannon là gì

Shannon là công cụ pentest tự động của Keygraph, mã nguồn mở theo giấy phép AGPL-3.0, viết bằng TypeScript. Kho chính thức là KeygraphHQ/shannon, phiên bản tham chiếu là v3.5.0, phát hành ngày 2026-10-27, với khoảng 50.000 star trên GitHub.

Khác gì một scanner thông thường

Shannon không chỉ quét rồi suy đoán: nó đọc source code, xác định các attack path khả thi, rồi tự thực thi khai thác trên một instance app đang chạy, và một finding chỉ xuất hiện trong báo cáo khi exploit chạy được thật.

Nguyên tắc “No exploit, no report”

Đây là triết lý thiết kế của dự án: mỗi finding kèm theo proof-of-concept để bạn tái hiện lại đường tấn công thay vì tin vào suy luận của máy. Theo mình, đây là điểm đáng giá nhất của Shannon, nhưng “không báo cáo” không đồng nghĩa “không tồn tại”, và báo cáo sạch không phải chứng nhận an toàn.

Không thay thế pentester con người

Shannon phù hợp làm lớp kiểm tra thường xuyên giữa các kỳ pentest thủ công, giống như unit test không thay thế được code review của người có kinh nghiệm. Với ứng dụng xử lý dữ liệu nhạy cảm, cần kết luận tuân thủ, hoặc có logic nghiệp vụ phức tạp, pentester con người vẫn bắt buộc.

Shannon hoạt động như thế nào

Luồng tổng thể

Luồng làm việc gồm bốn bước: đọc source để hiểu cấu trúc app, route API, cách xử lý input và cơ chế xác thực; lập danh sách attack path theo các dạng lỗ hổng OWASP thường gặp; thực thi khai thác thật trên app đang chạy; và chỉ tổng hợp finding có proof-of-concept chạy được thành báo cáo.

Thành phần chính: CLI npx, worker Docker, workspace resumable

Bạn điều khiển Shannon qua CLI cài bằng npx. Khi chạy scan, CLI kéo worker image từ Docker Hub và khởi động hạ tầng cục bộ, trong đó worker container chạy tách biệt và mount repo mục tiêu ở chế độ chỉ đọc, còn kết quả ghi vào workspace cục bộ có thể tiếp tục được (resumable) nếu lần chạy bị gián đoạn.

Phạm vi: injection, XSS, SSRF, broken authentication/authorization

Phạm vi tập trung vào các nhóm OWASP quen thuộc: injection, cross-site scripting (XSS), server-side request forgery (SSRF), và broken authentication/authorization. Đây là những nhóm vừa phổ biến vừa kiểm chứng được bằng khai thác live, còn lỗi logic nghiệp vụ sâu nằm ngoài thế mạnh của công cụ này.

Kiểm thử có xác thực: TOTP, email auth, focus areas

Nhiều lỗ hổng nghiêm trọng chỉ lộ ra sau khi đăng nhập, như phân quyền sai giữa các user hay IDOR. Shannon hỗ trợ kiểm thử có xác thực — credentials, login flow, kể cả TOTP và email auth — cùng focus areas và rules of engagement, và theo mình hãy dùng tài khoản thử nghiệm riêng với quyền hạn chế.

Đầu ra: PDF, Markdown, JSON, SARIF 2.1.0

Sau mỗi lần chạy, Shannon xuất báo cáo PDF, Markdown, JSON và SARIF 2.1.0. SARIF là định dạng quan trọng nhất nếu bạn muốn gắn Shannon thành security gate, vì pipeline đọc trực tiếp trạng thái và mức độ nghiêm trọng của từng finding từ file này.

Kiến trúc và giới hạn kỹ thuật

Chạy trong hạ tầng của bạn, repo mount read-only

Shannon chạy hoàn toàn trong hạ tầng của bạn: CLI, worker container và workspace đều nằm trên máy hoặc runner của bạn, kết quả lưu cục bộ, repo được mount chỉ đọc nên agent không sửa code của bạn. Tài liệu của dự án mô tả mô hình này là “private by design”.

Nhưng theo mình cần hiểu đúng một tầng nữa. “Private by design” chỉ đúng ở tầng hạ tầng chạy và lưu kết quả. Shannon dùng mô hình BYOK: bạn tự mang API key của LLM provider. Nếu dùng Anthropic hay OpenAI qua cloud, source code vẫn rời khỏi hạ tầng của bạn để tới provider LLM trong lúc agent phân tích và khai thác.

BYOK và các provider LLM

Shannon không bán kèm model và cũng không proxy traffic model qua máy chủ của Keygraph. Bạn tự chọn provider: Anthropic, OpenAI, xAI, AWS Bedrock, custom base URL, hoặc model cục bộ qua Ollama, vLLM, LM Studio. Đội cần bảo mật code nghiêm ngặt nên cân nhắc chạy model cục bộ hoặc trỏ qua LLM gateway tự host, ví dụ theo hướng trong bài tự host New API làm AI gateway. Ngoài ra, Anthropic và OpenAI áp dụng cyber safeguard theo thời gian thực, có thể ngắt một phiên scan, nên hãy hoàn tất hướng dẫn legitimate-tester của provider trước lần chạy đầu tiên.

Phụ thuộc bắt buộc: Docker, Node.js 18+, Docker Compose v2

Điều kiện tiên quyết gồm Docker, Node.js 18 trở lên, và credential của provider LLM. Trên runner CI, GitHub Action còn yêu cầu thêm Docker Compose v2. Phần lớn lỗi lần chạy đầu tiên đều bắt nguồn từ việc Docker chưa chạy được.

Giới hạn: bản open-source yêu cầu source code

Bản open-source bắt buộc phải có source code. Nếu bạn chỉ có URL của app đang chạy mà không có code, hoặc muốn quét dependency (SCA), quét secret, hay nhận pull request sửa lỗi tự động, đó là phạm vi của bản Pro/Enterprise thương mại.

Giới hạn về độ tin cậy

Báo cáo do LLM viết có thể chứa chi tiết chưa đủ căn cứ hoặc diễn giải sai mức độ ảnh hưởng. Quy trình đúng là: đọc finding, tái hiện PoC trên staging, rồi mới quyết định vá hay bác bỏ, và ghi lại lý do bác bỏ để lần chạy sau không phải tranh luận lại.

Cài đặt và chạy lần đầu trên staging

Nói rõ trước: phần này mình chưa chạy thử Shannon trên app thật, chỉ đối chiếu lệnh và quy trình với tài liệu chính thức của dự án. Các lệnh dưới đây được trích nguyên văn từ README, bạn nên chạy thử trên một app nhỏ trước khi áp cho hệ thống lớn.

Điều kiện tiên quyết

Chuẩn bị đủ bốn thứ: Docker đang chạy được (kiểm tra bằng docker ps); Node.js 18 trở lên (kiểm tra bằng node --version); credential của provider LLM, lưu dưới dạng biến môi trường hoặc secret; và một bản staging chạy bằng dữ liệu bỏ được, có thể snapshot và khôi phục. Tuyệt đối không trỏ Shannon vào production.

Phiên bản tham chiếu: v3.5.0 (2026-10-27), AGPL-3.0

Các lệnh trong bài dùng tag @latest của package @keygraph/shannon, tương ứng với dòng phát hành mới nhất. Nếu cần tái lập đúng kết quả, hãy ghi lại phiên bản thực tế đã chạy (xem output của lệnh setup) vào hồ sơ scan, vì @latest sẽ thay đổi theo thời gian.

Bước 1 — Khởi tạo

npx @keygraph/shannon@latest setup

Lệnh này chạy wizard khởi tạo: chọn provider LLM, nhập credential, kéo worker image từ Docker Hub và khởi động hạ tầng cục bộ. Đừng vội chạy scan ngay khi chưa cấu hình xong provider — lỗi thiếu credential là lỗi gặp nhiều nhất ở lần đầu.

Bước 2 — Chạy scan đầu tiên, giải thích từng flag

npx @keygraph/shannon@latest start -u https://your-app.com -r /path/to/your/repo

Trong đó -u là URL của app đang chạy mà Shannon sẽ khai thác — ở lần đầu, đây phải là URL staging; -r là đường dẫn tới repo source code trên máy bạn, được mount read-only vào worker container. Quá trình chạy đầy đủ mất khoảng 1–1,5 giờ tùy app và model, nên hãy chạy trên máy chủ staging luôn bật thay vì laptop sắp hết pin.

Hoàn tất cyber safeguards trước lần chạy đầu tiên

Nếu dùng Anthropic hoặc OpenAI, hoàn tất hướng dẫn legitimate-tester của provider trước lần chạy đầu tiên. Thực tế hơn nữa: chạy thử một scan ngắn trên app nhỏ để xác nhận safeguard không chặn, rồi mới chạy scan đầy đủ cho app chính.

Cách xác minh

Trong lúc scan chạy, quan sát qua live terminal của Shannon và kiểm tra worker container bằng docker ps. Sau khi scan kết thúc, kiểm tra workspace cục bộ: phải có các file báo cáo (PDF, Markdown, JSON, SARIF) kèm chi tiết từng finding và PoC tương ứng. Nếu workspace trống hoặc chỉ có log mà không có báo cáo, scan có thể đã bị gián đoạn.

Output kỳ vọng

Output đúng kỳ vọng là danh sách finding, mỗi finding có PoC tái hiện được, mức severity, và file SARIF đi kèm để pipeline đọc được. Nếu output toàn những mục “có thể bị tấn công” mà không có PoC, có khả năng bạn đang đọc nhầm phần phân tích trung gian, hoặc scan chưa hoàn tất.

Lỗi thường gặp và cách xử lý

Đọc báo cáo và xử lý finding

Phân biệt status: exploited với giả thuyết phân tích code

Trong output SARIF và JSON, trường trạng thái là thứ cần đọc đầu tiên. status: exploited nghĩa là finding đã có PoC chạy được — đây là thứ cần xử lý thật. Các mục chỉ dừng ở mức phân tích code không nên đưa vào cùng hàng đợi với exploited, và càng không nên cấu hình pipeline fail vì chúng.

Thứ tự ưu tiên vá

Thứ tự xử lý theo mình nên là: exploited kèm severity cao trước, rồi tới exploited severity trung bình, và chỉ đóng ticket sau khi đã tái hiện PoC trên staging và xác nhận bản vá chặn được đúng đường tấn công đó.

Gắn Shannon vào CI/CD làm security gate

GitHub Action shannon-action@v1 và GitLab component

Shannon có GitHub Action chính thức (KeygraphHQ/shannon-action) và GitLab CI/CD component. Với GitHub Action, yêu cầu gồm: repo private, runner có Docker và Docker Compose v2, credential provider lưu dưới dạng Actions secret, và một target staging hoặc dev mà runner truy cập được. Artifact báo cáo được giữ lại sau mỗi lần chạy để phục vụ audit.

Thiết kế gate đúng: chỉ fail trên exploited từ severity cấu hình trở lên

Đây là nguyên tắc quan trọng nhất khi gắn Shannon vào pipeline: gate chỉ fail khi có finding status: exploited từ mức severity bạn cấu hình trở lên. Theo mình, điểm khởi đầu hợp lý là fail ở mức high, chạy một thời gian để đội quen với nhịp xử lý, rồi mới siết dần xuống medium nếu thấy phù hợp.

Không chặn mọi pull request bằng scan 1–1,5 giờ

Một lần chạy Shannon mất khoảng 1–1,5 giờ, chưa kể chi phí LLM. Gắn nó vào mọi pull request nghĩa là mỗi PR chờ thêm hơn một giờ, và chi phí API nhân lên theo số PR trong ngày. Thiết kế hợp lý hơn là đặt gate ở pre-release hoặc chạy nightly, còn per-PR vẫn giữ SAST nhanh như Semgrep hay CodeQL.

Rollback gate khi có sự cố

Nếu gate gây tắc pipeline hoặc scan làm hỏng staging, thứ tự rollback nên là: chuyển gate về warn-only ngay, sau đó mới gỡ workflow nếu cần; khôi phục snapshot database staging về trạng thái trước scan; xóa workspace chứa dữ liệu test nếu nghi ngờ rò rỉ; và xoay credential provider cùng tài khoản test nếu có dấu hiệu lộ. Shannon không sửa code target nên rollback ở đây là rollback pipeline và staging, không phải revert code.

Đánh giá kỹ thuật

Ưu điểm

Điểm cộng lớn nhất là bằng chứng khai thác: finding nào cũng kèm PoC nên đội xử lý ít phải tranh luận “liệu có thật không”. Thứ hai là khả năng gắn vào nhịp release qua SARIF gate. Thứ ba, hỗ trợ xác thực phức tạp (TOTP, email auth) giúp quét được vùng sau đăng nhập. Cuối cùng, workspace resumable giảm thiệt hại khi lần chạy dài bị gián đoạn.

Nhược điểm

Đổi lại, bạn phải chấp nhận scan chậm và tốn tiền LLM cho mỗi lần chạy. Yêu cầu bắt buộc có source code loại trừ trường hợp pentest black-box ở bản open-source. Và chất lượng kết quả phụ thuộc vào model cùng chính sách safeguard của provider — hai yếu tố nằm ngoài tầm kiểm soát trực tiếp của bạn.

Bảo mật và an toàn pháp lý

Nguyên tắc an toàn không thể thỏa hiệp: chỉ chạy Shannon trên hệ thống bạn sở hữu hoặc có văn bản cho phép kiểm thử rõ ràng. Tuyệt đối không chạy trên production, không chạy lên hệ thống của bên thứ ba “để xem thử”. Bài viết về Heldkeys kiểm tra quyền truy cập của AI agent trên blog này cũng nhấn mạnh cùng một tinh thần: trao quyền cho agent phải đi kèm kiểm soát.

Rủi ro vận hành: agent làm thay đổi state

Trong lúc khai thác, agent có thể tạo tài khoản, submit form, làm thay đổi state của app và gửi request ra ngoài. Ngoài snapshot staging, hãy dùng tài khoản test riêng với quyền hạn chế, tắt các tích hợp gửi email/tin nhắn thật trên staging, và rà soát repo trước khi scan — Shannon đọc source nên không nên chạy lên codebase lạ, không rõ nguồn gốc vì nguy cơ prompt injection.

Hiệu năng và khả năng mở rộng

Về hiệu năng, dữ liệu đã xác minh chỉ có thời gian chạy khoảng 1–1,5 giờ cho một lần quét đầy đủ và mô hình chi phí BYOK. Mình không đưa ra benchmark so sánh tốc độ hay tỷ lệ phát hiện với công cụ khác, vì những con số đó chưa được kiểm chứng trên cùng một app trong phạm vi bài viết này.

So sánh với các lựa chọn cùng phạm vi

Để so sánh công bằng, nên dùng cùng một bộ tiêu chí: có bằng chứng khai thác hay không, cần source hay làm được black-box, gắn CI gate được không, hỗ trợ xác thực tới đâu, chi phí và thời gian mỗi lần chạy, và phạm vi OWASP bao phủ.

Shannon vs OWASP ZAP và Nuclei

ZAP và Nuclei chạy nhanh, rẻ, phù hợp quét thường xuyên và quét black-box khi không có source. Đánh đổi là nhiều cảnh báo chưa được chứng minh khai thác, nên đội phải tự xác minh. Theo mình, hai nhóm này bổ sung cho nhau tốt: ZAP/Nuclei quét nhanh mỗi ngày, Shannon kiểm chứng sâu trước release.

Shannon vs SAST (Semgrep, CodeQL)

SAST như Semgrep hay CodeQL rất giỏi phát hiện mẫu code nguy hiểm ngay trong pull request, chạy nhanh và rẻ. Nhưng phân tích tĩnh không chứng minh được đường tấn công có chạy thật trên app đang chạy hay không. Shannon đi từ code tới exploit thật nên bổ sung đúng vào chỗ SAST dừng lại, chứ không thay thế SAST.

Shannon open-source vs Pro/Enterprise và pentest thủ công

Khi bạn cần pentest black-box, quét dependency và secret, hoặc nhận pull request sửa lỗi tự động, đó là lúc xem xét bản Pro/Enterprise. Khi bạn cần kết luận tuân thủ hoặc đánh giá logic nghiệp vụ phức tạp, đó là lúc cần pentester con người. Bản open-source phục vụ tốt nhất trường hợp ở giữa: đội có source, có staging, muốn kiểm chứng thường xuyên trước release.

Use case thực tế cho từng đối tượng

Doanh nghiệp và đội backend: gate pre-release

Với đội backend, cách dùng trực tiếp nhất là gate pre-release: mỗi bản chuẩn bị lên production phải qua một lần scan staging, fail khi có exploited ở mức high trở lên. Quy trình này bắt được lỗi OWASP cơ bản trước khi nó ra production, và tạo ra artifact SARIF lưu lại làm bằng chứng audit.

DevOps/SRE: SARIF gate trong GitHub Actions/GitLab

Với DevOps/SRE, giá trị nằm ở tự động hóa: workflow chạy nightly hoặc pre-release, SARIF đẩy vào hệ thống quản lý cảnh báo, artifact lưu lại để đối chiếu khi có sự cố. Khi gate chuyển warn-only trong lúc xử lý sự cố, quyết định đó cũng nên được ghi lại.

Sysadmin và IT admin: rà soát app tự host trước khi mở ra internet

Sysadmin tự host app nội bộ thường có thói quen mở app ra internet rồi mới nghĩ tới bảo mật. Shannon đảo ngược thứ tự đó: dựng staging, chạy scan, vá exploited severity cao, rồi mới mở port. Nếu bạn từng dùng skill audit bảo mật Cloudflare để rà soát lớp biên, Shannon là lớp bổ sung ở tầng ứng dụng phía sau.

Homelab self-hoster: scan định kỳ với dữ liệu thử nghiệm riêng

Homelab self-hoster có thể chạy Shannon định kỳ — ví dụ mỗi tháng một lần — cho các app tự host quan trọng, với dữ liệu và tài khoản thử nghiệm tách riêng khỏi dữ liệu thật. Chi phí LLM là thứ cần cân nhắc ở đây: chọn model rẻ hơn hoặc chạy scan thưa hơn vẫn tốt hơn là không quét gì cả.

Người dùng AI coding agent: kiểm tra lại code do Claude Code/Cursor sinh ra

Nhóm cuối cùng, và theo mình là nhóm sẽ tăng nhanh nhất, là người dùng AI coding agent. Khi phần lớn code mới do AI sinh ra, vòng kiểm tra cũng nên có AI tham gia — nhưng với vai trò đối trọng, không phải đồng lõa. Shannon đọc code do agent khác viết rồi cố khai thác nó, tạo ra một vòng kiểm chứng độc lập trước mỗi release. Nếu bạn từng reverse-engineer app bằng AI agent như trong bài REA, cách tiếp cận của Shannon sẽ thấy quen thuộc: vẫn là AI đọc code, nhưng mục tiêu lần này là chứng minh lỗ hổng thay vì giải thích code.

Kết luận: ai nên dùng, ai chưa nên, bước tiếp theo

Nên dùng nếu: đã có staging, có source, ship thường xuyên

Shannon đáng thử nếu bạn đã có staging dùng dữ liệu bỏ được, có source code, ship thường xuyên, và chấp nhận mỗi lần scan tốn khoảng 1–1,5 giờ cùng chi phí LLM. Trong điều kiện đó, nó mang lại thứ mà scanner truyền thống thiếu: finding kèm PoC, gắn được thành gate trước release.

Chưa nên dùng nếu: chỉ có production, không có source, cần black-box

Chưa nên dùng nếu bạn chỉ có production mà không có staging, không có source code, cần pentest black-box, hoặc cần một kết luận tuân thủ để trình cho khách hàng hay cơ quan kiểm toán. Trong các trường hợp đó, bản open-source không phải công cụ đúng — hãy xem bản thương mại hoặc thuê pentester.

Bước tiếp theo: chạy một scan staging, đọc SARIF, rồi mới bật gate

Bước tiếp theo thực tế nhất gồm ba việc, theo đúng thứ tự: chạy một scan trên staging của app nhỏ nhất mà bạn quan tâm, đọc kỹ file SARIF và tái hiện ít nhất một PoC bằng tay để hiểu báo cáo, rồi mới bật gate fail-on-exploited ở mức high trong pipeline pre-release. Đừng bật gate trước khi đội đã quen đọc báo cáo — gate mà đội chưa hiểu sẽ bị tắt ngay sau lần fail đầu tiên.

Tài liệu tham khảo

• KeygraphHQ/shannon — repo và tài liệu chính thức: https://github.com/KeygraphHQ/shannon
• KeygraphHQ/shannon-action — GitHub Action chính thức: https://github.com/KeygraphHQ/shannon-action
• Keygraph — trang chủ dự án: https://keygraph.io/
• SARIF 2.1.0 — định dạng báo cáo phân tích tĩnh: https://sarifweb.azurewebsites.net/
• OWASP Top 10 — các nhóm lỗ hổng tham chiếu: https://owasp.org/www-project-top-ten/