Kiểm tra bảo mật trong Claude Code: hướng dẫn từng bước và tự động hóa bằng GitHub Action vào năm 2026

Tác giả của tài liệu gốc mô tả trải nghiệm của mình: “Tôi vừa chạy security-review trên dự án vibe của mình, và nhóm đã tìm thấy một số vấn đề thực sự trong 4 phút, những vấn đề này hiện đã được khắc phục.” Trước đây, công việc tương tự mất cả ngày của một chuyên gia tư vấn bên ngoài.

Tài liệu bổ sung về cấu hình công cụ có trong tài liệu Ailoot.

/security-review trong Claude Code là gì?#

Lệnh này hoạt động ở hai chế độ. Chạy cục bộ: chạy /security-review trong terminal, Claude sẽ đọc repository và tạo báo cáo. Chạy phía máy chủ: cài đặt cùng engine dưới dạng GitHub Action để tự động nhận xét inline trên mọi Pull Request.

Không giống các công cụ quét SAST cổ điển (Snyk Code, Semgrep, SonarQube), /security-review không hoạt động dựa trên các quy tắc cố định. Công cụ đọc mã như một kỹ sư trực tiếp kiểm tra: theo dõi luồng dữ liệu, hiểu bạn đang dùng framework nào và ranh giới tin cậy nằm ở đâu, đồng thời phát hiện những lỗ hổng mà không quy tắc nào mô tả được.

Điều này không có nghĩa /security-review thay thế được một đợt kiểm thử xâm nhập bên ngoài hoặc việc kiểm thử trực tiếp trong môi trường staging. Nó có thể tự động hóa một phần đánh giá mã ban đầu, nhưng bài không đo tỷ lệ độ phủ audit. Sau đây, tôi sẽ giải thích cách chạy đúng và những gì Claude sẽ tìm thấy trong dự án của bạn.

Chạy /security-review trong 5 bước như thế nào?#

Bước 1. Cập nhật Claude Code. Lệnh hoạt động từ bản phát hành ngày 20 tháng 2 năm 2026.

claude update

Nếu cài Claude Code qua npm, bạn cũng có thể chạy:

npm install -g @anthropic-ai/claude-code@latest

Kiểm tra xem /security-review đã xuất hiện chưa:

claude /help | grep security

Bước 2. Mở dự án và đăng nhập Claude Code.

cd ~/projects/my-vibe-project
claude

Bước 3. Chạy lệnh. Trong Claude Code, chỉ cần nhập:

/security-review

Claude tự động thực hiện 3 giai đoạn phân tích:

1. Nghiên cứu ngữ cảnh repository (Repository Context Research) - đọc cấu trúc và xác định stack, các route và truy vấn cơ sở dữ liệu.
2. Phân tích so sánh (Comparative Analysis) - so sánh trạng thái hiện tại với các dạng lỗ hổng thường gặp trong stack này.
3. Đánh giá lỗ hổng (Vulnerability Assessment) - liệt kê từng điểm nghi vấn cùng mức độ tin cậy trên thang điểm 1-10. Chỉ các phát hiện có độ tin cậy ≥ 8 mới được đưa vào báo cáo.

Bước 4. Đọc báo cáo. Kết quả có dạng bảng Markdown. Với mỗi vấn đề, Claude cung cấp:

• Tệp và số dòng (ví dụ: src/auth/login.ts:42)
• Mức độ nghiêm trọng (HIGH / MEDIUM / LOW)
• Danh mục (sql_injection, xss, auth_bypass, insecure_storage)
• Mô tả - vấn đề là gì
• Kịch bản khai thác - kẻ tấn công có thể lợi dụng vấn đề ra sao
• Khuyến nghị - cách khắc phục

Bước 5. Yêu cầu Claude áp dụng bản sửa lỗi. Sau đó, bạn có thể làm việc với Claude như một agent thông thường:

“Áp dụng các bản sửa lỗi mức HIGH trong báo cáo, từng lỗi một, kèm mô tả PR.”

Claude sẽ mở từng tệp và đề xuất thay đổi; bạn xác nhận. Trong một dự án thực tế, tôi đã xử lý 5 phát hiện trong 40 phút thay vì 3 giờ như dự kiến.

/security-review tìm thấy những lỗ hổng nào?#

Danh sách đầy đủ những nội dung được đưa vào phân tích theo mặc định được mô tả trong tài liệu chính thức của Anthropic:

Ngoài ra, lệnh còn bao quát những nhóm vấn đề mà công cụ quét tự động hiếm khi phát hiện:

• Command injection - thực thi đầu vào của người dùng trong shell (child_process.exec(userInput))
• Path traversal - tải tệp qua ../../etc/passwd
• XXE - XML có external entity
• Template injection - SSTI trong Jinja/Handlebars/EJS
• NoSQL injection - toán tử $ne, $gt trong truy vấn MongoDB
• Dùng sai mật mã học - sử dụng MD5, chế độ ECB hoặc IV tĩnh

Claude gán mức độ nghiêm trọng cho mỗi phát hiện. Thang phân loại rất đơn giản:

• HIGH - khai thác từ xa mà không cần xác thực, rò rỉ dữ liệu ảnh hưởng đến tất cả người dùng
• MEDIUM - cần thêm điều kiện để khai thác (cần có session / cần đầu vào cụ thể)
• LOW - một hướng tấn công tiềm tàng, hiện chưa nghiêm trọng nhưng đáng khắc phục

Cần lưu ý: với cấu hình tiêu chuẩn, Claude không báo cáo DoS, giới hạn tần suất, cạn kiệt bộ nhớ, open redirect không chứng minh được tác động, regex injection / ReDoS hoặc giả mạo log. Đây là chủ ý để bạn không bị ngập trong nhiễu. Nếu các nhóm này quan trọng, hãy mở rộng quy tắc (xem phần lọc cảnh báo giả bên dưới).

Thiết lập GitHub Action để tự động rà soát như thế nào?#

Bước 1. Lấy API key. Truy cập console.anthropic.com, tạo API key và sao chép.

Bước 2. Đưa key vào repository secrets. Trong GitHub: Settings → Secrets and variables → Actions → New repository secret. Đặt tên là CLAUDE_API_KEY; giá trị là key của bạn.

Bước 3. Tạo workflow file. Lưu tệp với tên .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Bước 4. Gộp nhánh vào main. Action sẽ tự động chạy khi có PR tiếp theo.

Action thực hiện những gì:

• Chạy trên mọi Pull Request đang mở / được synchronize.
• Lấy diff giữa nhánh PR và main.
• Chạy cùng engine với /security-review cục bộ.
• Đăng nhận xét inline ngay tại các dòng mã có điểm nghi vấn.
• Sao chép toàn bộ báo cáo vào Job Summary.

Chi tiết quan trọng trong permissions:

• pull-requests: write - để đăng nhận xét inline.
• contents: read - để đọc mã. Không có write. Action không tự sửa mã; nó chỉ báo cáo.

Bộ quyền này đủ dùng cho repository riêng tư. Với repo công khai, bạn có thể chỉ định thêm actions: read nếu sử dụng reusable workflow.

Lọc cảnh báo giả và thay đổi độ nhạy như thế nào?#

Bảng đầy đủ các input của GitHub Action (nguồn: README của repository):

Ví dụ cấu hình lọc cảnh báo giả. Tạo tệp .claude/security/false-positives.md:

# Quy tắc lọc cảnh báo giả cho dự án của chúng ta

- Mọi `dangerouslySetInnerHTML` bên trong `src/lib/email/layout.ts` đều an toàn -
  HTML được tạo từ template đáng tin cậy và đi qua `sanitize-html`
  tại thời điểm ghi vào cơ sở dữ liệu, không phải lúc render.
- Không báo cáo API key kiểm thử ghi cứng trong `__tests__/fixtures/*.ts`.
  Tất cả key đều bắt đầu bằng `sk-test-fake-`.
- Nối SQL trong `src/lib/admin/migrations.ts` là chấp nhận được - tệp này chỉ chạy
  với quyền root và dữ liệu đầu vào lấy từ environment variables.

Kết nối tệp này trong workflow:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

Hướng dẫn quét bảo mật tùy chỉnh cũng tương tự. Tạo một tệp chứa các quy tắc đặc biệt quan trọng với dự án của bạn:

# Kiểm tra bổ sung cho dự án của chúng ta

- Mọi endpoint dưới `/api/admin/*` phải kiểm tra vai trò quản trị viên
  thông qua wrapper dùng chung. Không có wrapper này thì mức độ nghiêm trọng là HIGH.
- Mọi webhook của YooKassa / CloudPayments phải xác minh chữ ký trước khi
  phân tích body. Không làm vậy thì mức độ nghiêm trọng là HIGH.
- Token magic-link phải chỉ dùng được một lần (đánh dấu là đã sử dụng sau
  yêu cầu hợp lệ đầu tiên). Token có thể tái sử dụng có mức độ nghiêm trọng MEDIUM.

Đây không còn là preset của Anthropic: bạn đang chuyển chuyên môn về dự án của mình thành các quy tắc mà Claude áp dụng mỗi lần chạy. Đó chính là cốt lõi của “phương pháp quan trọng hơn model”.

Xem thêm về phương pháp quản lý ngữ cảnh cho Claude trong các hướng dẫn “Cách cấu hình CLAUDE.md” và “Second Brain trong Claude Code”.

Claude KHÔNG phát hiện được gì và vì sao: những hạn chế thực tế?#

Anthropic liệt kê rõ những nội dung bị tắt theo mặc định và lý do (nguồn: README của repository):

• Từ chối dịch vụ (Denial of Service) - quá nhiều nhiễu, hầu như luôn có tác động thấp.
• Vấn đề giới hạn tần suất - được xử lý ở cấp độ hạ tầng, không phải trong mã.
• Cạn kiệt bộ nhớ / CPU - tương tự.
• Xác thực đầu vào chung chung khi chưa chứng minh được tác động - xác thực mọi trường tạo ra vô số cảnh báo giả.
• Open redirect - thường là hành vi có chủ đích.

Điều riêng đánh giá mã không xác minh đầy đủ nếu thiếu bằng chứng runtime hoặc deployment:

• Cấu hình máy chủ production. NGINX headers, chính sách CORS, thiết lập TLS và các cổng đang lắng nghe. Cần kiểm tra thủ công trong môi trường staging.
• Race condition. Ví dụ: chi tiêu hai lần khi có các yêu cầu hoàn tiền đồng thời. Phân tích tĩnh có thể chỉ mẫu đáng ngờ nhưng hành vi đồng thời vẫn cần thử.
• Lỗi logic nghiệp vụ thanh toán. Nếu tổng đơn hàng được tính ở phía client rồi gửi thẳng cho nhà cung cấp dịch vụ thanh toán, đó là mức độ HIGH, nhưng Claude không phải lúc nào cũng nhận ra mẫu này nếu thiếu ngữ cảnh rõ ràng về cách thanh toán cần hoạt động.
• IDOR ở cấp cơ sở dữ liệu. Claude thường phát hiện nếu truy vấn SELECT * FROM orders WHERE id = $1 không kiểm tra WHERE user_id = $session.userId. Nhưng nếu việc kiểm tra được triển khai qua ORM middleware và Claude không thấy được toàn bộ luồng dữ liệu, công cụ có thể bỏ sót.
• Khả năng chống social engineering / phishing. Nội dung này không liên quan đến mã.

Dùng /security-review như đánh giá tĩnh ban đầu. Tiếp theo thử động staging, kiểm role/quyền, SAST phù hợp và cấu hình triển khai thực. Bài không xác lập phần trăm phủ đo được.

Chọn phạm vi và thời điểm đánh giá ngoài theo rủi ro, thay đổi của hệ thống. Một lệnh hoặc audit ngoài định kỳ đều không xác lập độ phủ bảo mật 100%.

Tác giả nội dung gốc đã rà soát bảo mật một dự án vibe như thế nào#

Những gì được phát hiện. Bức tranh thường thấy ở một dự án vibe trung bình trong giai đoạn “chạy được trên production nhưng chưa qua rà soát”: một số điểm nghi vấn về luồng xác thực, logic xử lý webhook từ tích hợp thanh toán, xử lý tải tệp lên và thêm vài lưu ý cụ thể về xử lý HTML lúc render. Tôi không công khai chi tiết; một số khuyến nghị đã được áp dụng, những khuyến nghị khác vẫn đang trong PR. Trong dự án được báo này, quét ban đầu hữu ích và nhanh; chưa xác lập phần trăm độ phủ audit hoặc thời gian hoàn thành chung.

Những gì tôi loại bỏ vì là cảnh báo giả:

• Các phát hiện về DoS thông qua regex trong bước xác thực đầu vào - tải thực tế không dồn lên các regex đó.
• Một phát hiện về API key ghi cứng - đó là key kiểm thử có tiền tố fake- rõ ràng trong fixtures.

Mất bao lâu? Lần chạy mất 4 phút. Đọc báo cáo mất 25 phút. Áp dụng bản sửa lỗi mất khoảng một giờ, có kèm kiểm thử. Tổng cộng: khoảng một tiếng rưỡi từ lúc “bắt đầu” đến khi “mọi thứ nằm trên main”. Một đợt kiểm thử xâm nhập bên ngoài trên cùng phạm vi cần một tuần theo lịch và có chi phí cao hơn hàng chục lần.

Kết luận chính. /security-review không thay thế được kiểm thử xâm nhập bên ngoài. Nó có thể tìm phát hiện mức mã hữu ích như lượt quét bốn phút tác giả báo. Xem và thử bản sửa, kiểm runtime và cấu hình triển khai riêng; quét không xóa rủi ro bảo mật dự án.

Tích hợp /security-review vào quy trình pre-commit như thế nào?#

Hook từng nêu dùng git_commit, --severity HIGH, --fail-on-find không phải công thức hoạt động có tài liệu và không được dùng làm security gate. Bài chưa cung cấp hook chặn commit cục bộ đã xác minh. GitHub Action chính thức trên tạo phát hiện PR tự động; nhận xét PR không chứng minh chặn commit hoặc merge.

Hướng dẫn đầy đủ về hooks có trong tài liệu “Hooks trong Claude Code”.

Một phương án khác là dùng routines để tạo routine pre-deploy-check, chạy /security-review + npm run build + npm run test bằng một lệnh. Có thêm tài liệu trong Ailoot.

Nếu dùng MCP servers, bạn có thể tích hợp các phát hiện từ /security-review với hệ thống xử lý sự cố (Sentry, Linear, Notion), để mỗi phát hiện mức HIGH tự động trở thành một ticket.

FAQ về /security-review#

Mỗi lần chạy tốn bao nhiêu? Tùy quy mô dự án. Với 30K dòng mã của tôi, mỗi lần chạy sử dụng khoảng $0.30-0.50 trong số dư API. Một repository doanh nghiệp lớn với một triệu dòng mã có thể tốn đến $5-8 mỗi lần chạy. Mức này rẻ hơn hàng chục lần so với phí đăng ký bất kỳ công cụ quét SaaS nào.

Nên chạy cục bộ bao lâu một lần? Tối thiểu là trước mỗi lần phát hành lên production. Cũng cân nhắc trước commit và PR đáng kể. Bài không cung cấp hook tự chặn commit đã xác minh.

Công cụ hoạt động với stack nào? Bất kỳ stack nào Claude đọc được. Theo quan sát của tác giả, các stack đã được kiểm tra gồm: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel) và Ruby on Rails. Chất lượng thấp hơn với các ngôn ngữ rất ít phổ biến (Erlang, Elixir, Clojure), nhưng vẫn sẽ tìm thấy vấn đề nào đó.

Nên làm gì nếu Claude lần nào cũng tìm thấy cùng một “lỗ hổng”, dù thực tế đó không phải lỗ hổng? Thêm phát hiện đó vào false-positive-filtering-instructions và giải thích “vì sao điều này an toàn”. Claude sẽ không báo cáo lại trong những lần chạy sau.

Có thể chỉ chạy trên các tệp cụ thể không? Có, khi chạy cục bộ: chỉ cần chạy /security-review src/lib/auth/*.ts. Trong GitHub Action, công cụ chỉ kiểm tra diff của PR hiện tại; thông thường đó chính là ý nghĩa của “các tệp cụ thể”.

Nguồn#

Tài liệu bổ sung có trong tài liệu Ailoot.