Audit bảo mật code bằng Claude Code: quy trình thực chiến 2026

Audit bảo mật code bằng Claude Code là gì?

Audit bảo mật code bằng Claude Code là quy trình dùng Claude Code như một "AI security reviewer" - đọc hiểu ngữ nghĩa của code để phát hiện lỗ hổng, chứ không chỉ so khớp mẫu (pattern-match) như linter truyền thống. Vì mô hình hiểu được luồng dữ liệu và ý định của hàm, nó bắt được những lỗi mà công cụ dựa trên regex hay bỏ sót: input người dùng chảy vào câu SQL nối chuỗi, một endpoint thiếu kiểm tra quyền, hay một khóa API bị nhét thẳng vào source.

Các nhóm lỗ hổng Claude Code thường soi được gồm: injection (SQL, command, NoSQL, XXE), xác thực và phân quyền hỏng (IDOR, leo thang đặc quyền, session yếu), rò rỉ dữ liệu (secret hardcode, log dính PII), crypto yếu (RNG kém, quản lý khóa sai), lỗi cấu hình (CORS, security headers), và supply chain (dependency dính CVE).

Có hai đường tiếp cận trong bài này:

• Native /security-review - lệnh có sẵn trong Claude Code và một GitHub Action chính chủ của Anthropic, ra mắt tháng 8/2025 (anthropics/claude-code-security-review, truy cập 08/2026). Nó review thay đổi đang chờ, chấm severity và đề xuất fix, kèm bộ lọc false-positive.
• Skill dựng sẵn ak-security - gói prompt STRIDE + OWASP A01-A10, dependency audit theo stack, red-team đa persona và chế độ --fix, để bạn khỏi phải tự soạn prompt dài.

Tài liệu chính thức về mô hình bảo mật của Claude Code nằm ở code.claude.com/docs/en/security (truy cập 08/2026) - nên đọc trước khi cấp quyền cho AI chạy lệnh trong repo.

Chuẩn bị trước khi audit

Ba phút chuẩn bị giúp phiên audit sạch và có thể rollback:

• Claude Code đã cài và đăng nhập. Nếu chưa, xem hướng dẫn cài đặt Claude Code.
• Git working tree sạch (git status không còn thay đổi lửng lơ). Bạn cần diff rõ ràng để phân biệt phần AI đề xuất và để rollback bằng git restore nếu bản vá làm hỏng.
• Xác định scope trước: một thư mục (src/api/**), các file đang thay đổi, hay toàn repo. Scope hẹp thì nhanh và rẻ token hơn.
• Chỉ audit code TIN CẬY. Đây là cảnh báo quan trọng nêu sớm: khi bạn cho AI đọc code từ repo hoặc PR của người lạ, nội dung độc hại trong code đó có thể chèn chỉ thị (prompt injection) đánh lừa mô hình. Với code không tin cậy, hãy đọc thủ công hoặc chạy trong môi trường cô lập.
• Rà quyền chạy lệnh. Xem lại permissions và an toàn khi chạy Claude Code để AI không tự ý chạy lệnh phá hoại trong lúc quét.

Quy trình audit 6 bước với Claude Code

Đây là xương sống của cả phiên. Làm tuần tự từ hẹp đến rộng để kết quả dễ đọc và không đốt token vô ích.

Bước 1 - Xác định phạm vi (scope)

Bắt đầu bằng việc chỉ rõ vùng cần soi. Với thay đổi nhỏ, để Claude tập trung vào diff; với repo lớn, khoanh theo glob thư mục nhạy cảm (auth, thanh toán, upload, API công khai). Yêu cầu Claude đọc toàn bộ file in-scope trước khi phân tích - nếu không, mô hình dễ đoán mò dựa trên tên hàm. Ví dụ mở đầu:

Đọc toàn bộ các file trong src/api/ và src/auth/ trước.
Chưa sửa gì cả. Chỉ liệt kê những vùng có bề mặt tấn công
(nhận input ngoài, truy cập DB, xử lý xác thực) để mình chọn scope.

Bước 2 - Chạy /security-review cho thay đổi đang chờ

Với các thay đổi bạn sắp commit, chạy lệnh native ngay trong phiên Claude Code:

/security-review

Lệnh này review phần diff đang chờ, phân loại severity và đề xuất cách vá cho từng phát hiện. Nó chạy trên model Claude mạnh nhất khả dụng (có thể cấu hình) - nên coi như một reviewer bảo mật đọc PR của bạn trước khi con người kịp nhìn. Đây là điểm nhanh nhất để "shift-left": bắt lỗi ngay lúc code còn nóng, chưa lên nhánh chính.

Bước 3 - Quét toàn repo theo STRIDE + OWASP

Để soi sâu hơn diff, đưa Claude một prompt có cấu trúc mô hình hóa mối đe dọa. STRIDE map khá gọn sang OWASP Top 10. Prompt template copy-paste được:

Audit bảo mật toàn bộ code in-scope theo 6 nhóm STRIDE và map sang OWASP Top 10:
- Spoofing -> A07 (lỗi nhận dạng/xác thực)
- Tampering -> A03 (injection), A08 (toàn vẹn dữ liệu/phần mềm)
- Repudiation -> A09 (thiếu logging/giám sát)
- Info Disclosure -> A02 (crypto), A01 (kiểm soát truy cập)
- Denial of Svc -> lưu ý nhưng chỉ báo nếu có impact rõ
- Elevation of Priv -> A01 (broken access control)

Với mỗi phát hiện, ghi: severity, category, file:line, mô tả ngắn,
và đề xuất fix cụ thể. Đừng báo lỗi mang tính lý thuyết không chứng minh được impact.

Bước 4 - Audit dependencies

Lỗ hổng thường không nằm trong code bạn viết mà trong thư viện bạn kéo về. Chạy tool đúng theo stack rồi để Claude tổng hợp và xếp ưu tiên:

npm audit # Node.js
pip-audit # Python
govulncheck ./... # Go
bundle audit # Ruby

Rồi dán output cho Claude: "Xếp các CVE này theo mức độ khai thác thực tế trong dự án của mình, bỏ qua cái nằm ở devDependencies không lên production." Claude giúp lọc nhiễu - không phải CVE nào cũng nằm trên đường thực thi của bạn.

Bước 5 - Dò secrets bị hardcode

Yêu cầu Claude quét API key, mật khẩu, token, private key nhét thẳng trong source và file config. Quan trọng về credential hygiene: khi báo cáo, hãy mask giá trị thật thành <REDACTED_TOKEN> trước khi log hay commit report - đừng để bí mật rò ra chính file audit.

Quét toàn repo tìm secret hardcode (api key, password, token, private key,
chuỗi kết nối DB). Với mỗi phát hiện chỉ ghi file:line và LOẠI secret,
mask giá trị thành <REDACTED>. Đừng in giá trị thật ra output.

Bước 6 - Phân loại severity và xuất báo cáo

Yêu cầu Claude gom tất cả phát hiện vào một bảng theo mức nghiêm trọng, kèm ngưỡng hành động rõ ràng:

Để lưu lại kết quả, yêu cầu Claude xuất báo cáo ra Markdown kèm phần tóm tắt số lượng theo severity ở đầu ("2 Critical, 3 High…") - đây là dạng dễ dán vào issue tracker hay gửi lead review. Nếu chạy audit định kỳ, giữ báo cáo theo ngày trong một thư mục security/ (đã gitignore phần nhạy cảm) để so sánh giữa các đợt và thấy lỗ hổng nào tái xuất hiện hay lọt qua review.

Phiên audit thật: đọc findings ra sao

Đây là phần đối thủ tiếng Việt lẫn tiếng Anh gần như bỏ hẳn: một bảng findings thật chứ không phải mô tả tính năng. Dưới đây là kết quả minh hoạ từ một dự án mẫu Node/TypeScript (API + auth) để bạn thấy output trông ra sao - hãy chạy trên repo của bạn để có bảng của riêng mình:

Cách đọc: xử lý từ trên xuống theo severity. Finding #1 chặn release - không có gì bàn cãi. #2 và #3 vào ngay sprint. #4 (IDOR) hay bị coi nhẹ nhưng lại là lỗ hổng leo thang truy cập rất phổ biến. Với mỗi dòng, mở đúng file:line, xác nhận lỗi có thật (không phải false-positive), rồi mới vá - đừng vá mù theo báo cáo.

Mẹo xác minh nhanh trước khi vá: hỏi ngược Claude "chứng minh finding #4 khai thác được: viết một request cụ thể mà user A dùng để đọc order của user B". Nếu mô hình dựng được kịch bản khai thác cụ thể thì đó là lỗ hổng thật; nếu nó vòng vo hoặc phải giả định điều kiện phi thực tế, khả năng cao là false-positive và bạn hạ ưu tiên. Bước phản biện này lọc bớt nhiễu và giúp bạn giải thích rủi ro cho phần còn lại của team bằng ngôn ngữ tấn công cụ thể thay vì thuật ngữ trừu tượng.

Vá lỗ hổng - ví dụ before/after thật

Lấy finding #1 (Critical, SQL injection) làm ví dụ. Đây là code dễ dính:

// TRƯỚC - dễ bị SQL injection
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = '" + id + "'";
 return db.query(sql); // input id chảy thẳng vào câu SQL
}

Và sau khi vá bằng parameterized query:

// SAU - dùng tham số hóa, driver tự escape
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = $1";
 return db.query(sql, [id]); // giá trị id đi qua kênh tham số, không phải chuỗi SQL
}

Vì sao an toàn hơn: ở bản sau, id không còn được nối vào chuỗi SQL nữa mà truyền qua kênh tham số riêng. Driver database xử lý nó như dữ liệu, không phải lệnh - nên một chuỗi kiểu ' OR '1'='1 không thể đổi cấu trúc câu query.

Với chế độ tự động, skill dựng sẵn có --fix để vá tuần tự từng finding, chạy test guard chống regression sau mỗi bản vá, rồi commit riêng cho từng lỗi. Nhưng luôn xem lại diff trước khi merge - và khi một bản vá làm gãy test, đừng đoán mò mà hãy debug khi fix làm hỏng test cùng AI để tìm đúng nguyên nhân.

Tự động hóa: review bảo mật mỗi Pull Request

Để mỗi PR tự động được quét, dùng GitHub Action chính chủ. Thêm file .github/workflows/security.yml:

name: Security Review
on: [pull_request]
jobs:
 review:
 runs-on: ubuntu-latest
 permissions:
 pull-requests: write
 contents: read
 steps:
 - uses: actions/checkout@v4
 - uses: anthropics/claude-code-security-review@main
 with:
 claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

Action sẽ comment findings trực tiếp lên PR để reviewer thấy ngay.

Caveat bắt buộc: theo Anthropic, action này chưa được hardened chống prompt injection. Chỉ chạy nó trên PR tin cậy và bật "Require approval for all external contributors" trong cài đặt Actions - nếu không, một PR độc hại từ người lạ có thể chèn chỉ thị đánh lừa quá trình review.

Để hoàn thiện lớp phòng thủ, kết hợp với git workflow an toàn với Claude Code và cân nhắc thêm một hook pre-commit dò secret trước khi code kịp lên remote.

Red-team nâng cao: audit theo 4 persona tấn công

Quét STRIDE một lượt là tốt, nhưng lỗ hổng thật thường lộ ra khi bạn nghĩ như kẻ tấn công cụ thể. Chạy audit từ 4 góc nhìn khác nhau cho info-gain rõ rệt:

• Security Adversary - tìm auth bypass, các dạng injection, IDOR: "Mình đăng nhập bằng tài khoản thường thì đọc/sửa được dữ liệu của ai khác không?"
• Supply Chain - dependency dính CVE, CI/CD bị đầu độc, typosquatting trong package.
• Insider - leo thang đặc quyền ngang/dọc, bulk export dữ liệu, lạm quyền của tài khoản nội bộ.
• Infrastructure - SSRF, secret lộ trong biến môi trường, cấu hình container/network sai.

Viết tay đủ 4 persona này rất tốn công vì mỗi góc cần một bộ prompt và checklist riêng. Đây chính là chỗ threat modeling có cấu trúc sẵn giúp tiết kiệm nhiều giờ soạn prompt.

Dùng skill ak-security dựng sẵn (khỏi viết prompt)

Thay vì tự soạn prompt STRIDE, 4 persona red-team và quy trình --fix mỗi lần, bộ kit AgentKit (giảm 20% qua link) đóng gói sẵn tất cả trong skill ak-security (thuộc Engineer Kit, $99; trang có money-back guarantee và cập nhật trọn đời, không nêu phí định kỳ). Cách dùng:

/ak:security src/api/**/*.ts # quét scope hẹp
/ak:security full --red-team --fix # toàn repo, 4 persona, tự vá

Nó gói STRIDE + OWASP A01-A10, dependency audit theo stack, dò secret, chấm severity và vá tuần tự có guard test. Xem Engineer Kit có những skill bảo mật gì để đối chiếu nhu cầu.

Trung thực: skill chỉ tiện lợi hóa việc soạn prompt và quy trình - nó không "biến AI thành pentester". Native /security-review đã đủ cho phần lớn nhu cầu; kit đáng cân nhắc khi bạn audit thường xuyên và muốn red-team đa persona chỉ bằng một lệnh.

Một dòng phân biệt: AgentKit ở đây là bộ kit cho Claude Code (agentkit.best, CLI ak), không phải OpenAI AgentKit (Agent Builder/ChatKit).

Giới hạn thật và khi nào KHÔNG nên tin AI

Bảo mật gần như là YMYL - nói thẳng giới hạn quan trọng hơn thổi phồng:

• Prompt injection. Đừng audit code lạ một cách mù quáng. Code không tin cậy có thể chèn chỉ thị lái mô hình bỏ qua lỗ hổng hoặc chạy lệnh ngoài ý muốn.
• False-positive và false-negative. Mặc định /security-review loại bỏ nhóm DoS, rate-limiting, resource exhaustion, open-redirect và input-validation không chứng minh được impact - nên "quét sạch" không nghĩa là "an toàn tuyệt đối". Ngược lại, AI vẫn bỏ sót lỗi business-logic tinh vi (race condition, TOCTOU, logic phân quyền phức tạp).
• Không thay pentest chuyên nghiệp. Đây là công cụ shift-left để bắt lỗi sớm và rẻ, không phải chứng nhận bảo mật. SAST/DAST và pentest thủ công vẫn cần cho hệ thống quan trọng.
• Chi phí token. Quét repo lớn tốn token và thời gian đáng kể; khoanh scope theo thư mục nhạy cảm thay vì quét full mỗi lần.

Câu hỏi thường gặp (FAQ)

Lệnh /security-review có miễn phí không?

Bản thân lệnh và GitHub Action là mã nguồn mở của Anthropic, dùng được không tốn phí riêng. Chi phí thực tế là token/usage của Claude Code theo gói bạn đang dùng (Pro, Max hoặc API theo token).

Audit bằng Claude Code khác gì SAST truyền thống?

SAST chủ yếu dò theo pattern và luật cố định nên hay nhiều nhiễu. Claude Code đọc hiểu ngữ nghĩa và luồng dữ liệu, nên bắt được lỗi phụ thuộc ngữ cảnh (như IDOR hay logic phân quyền) mà pattern-match bỏ sót - đổi lại có thể thiếu ổn định và cần người xác nhận.

AI có thay được pentest chuyên nghiệp không?

Không. Đây là lớp shift-left bắt lỗi sớm và rẻ, không phải chứng nhận. Hệ thống quan trọng vẫn cần pentest thủ công, cùng SAST/DAST trong pipeline.

Audit code của người khác có an toàn không?

Có rủi ro prompt injection: code không tin cậy có thể chèn chỉ thị đánh lừa mô hình. Chỉ audit code tin cậy, hoặc chạy trong môi trường cô lập và bật phê duyệt thủ công cho contributor bên ngoài.

Audit tốn bao nhiêu token và thời gian?

Tùy scope. Review một diff nhỏ chỉ vài phút và ít token; quét toàn repo lớn tốn nhiều token và lâu hơn hẳn. Khoanh scope theo thư mục nhạy cảm để tiết kiệm.

Skill ak-security khác gì tự viết prompt?

Nó gói sẵn STRIDE + OWASP, red-team 4 persona và quy trình --fix có guard test trong một lệnh, tiết kiệm công soạn prompt. Về năng lực phát hiện thì tương đương việc bạn tự viết prompt tốt - khác biệt là tiện lợi và tính nhất quán, không phải "mạnh hơn về bản chất".

Kết luận và bước tiếp theo

Audit bảo mật code bằng Claude Code không thay được chuyên gia, nhưng biến việc rà lỗ hổng thành thói quen rẻ và nhanh - chạy /security-review trước mỗi release, quét STRIDE định kỳ, và tự động hóa trên PR tin cậy. Tiếp theo, mở rộng sang AI code review toàn diện và củng cố nền tảng với best practices bảo mật khi dùng Claude Code. Và đừng quên: audit định kỳ trước mỗi release quan trọng hơn một lần quét thật kỹ rồi bỏ đó.