Tự động hóa Kiểm tra Bảo mật Code (SAST/DAST) bằng Workflow: Chạy Snyk khi thay đổi code

Tóm tắt nhanh nội dung
– Tại sao kiểm tra bảo mật code (SAST/DAST) lại quan trọng – rủi ro thực tế, chi phí mất mát.
– Vấn đề thường gặp: quét thủ công, bỏ sót lỗ hổng, thời gian phản hồi chậm.
– Giải pháp workflow automation: tích hợp Snyk (hoặc Trivy, OWASP ZAP) vào CI/CD, chạy tự động khi có commit/pull‑request.
– Bước thực hiện chi tiết: chuẩn bị môi trường, viết pipeline, cấu hình secret, báo cáo.
– Template quy trình: YAML mẫu cho GitHub Actions, GitLab CI, Azure Pipelines.
– Lỗi phổ biến & cách khắc phục: token hết hạn, cấu hình sai, false‑positive.
– Scale lên toàn công ty: centralized scanning, caching, artifact storage.
– Chi phí thực tế: license Snyk, runner, lưu trữ, nhân sự.
– Số liệu trước‑sau: giảm 70 % lỗ hổng high/critical, thời gian phát hiện giảm từ 3 ngày → 30 phút.
– FAQ: “Có cần chạy cả SAST và DAST?”, “Làm sao giảm false‑positive?”.
– Hành động ngay: triển khai pipeline mẫu, đo lường KPI, cải tiến liên tục.

1. Tóm tắt nội dung chính

Trong môi trường phát triển nhanh (CI/CD) ngày nay, bảo mật code không còn là công việc “đánh một lần rồi xong”. Các lỗ hổng SAST (Static Application Security Testing) và DAST (Dynamic Application Security Testing) nếu không được phát hiện sớm sẽ dẫn tới chi phí khắc phục gấp hàng chục lần, thậm chí gây mất uy tín doanh nghiệp. Bài viết này sẽ chỉ cho bạn cách tự động hoá quy trình quét bảo mật bằng workflow, cụ thể là tích hợp Snyk vào pipeline CI/CD, từ việc cài đặt, cấu hình, tới khi mở rộng quy mô cho toàn bộ dự án.

2. Vấn đề thật mà mình và khách hay gặp mỗi ngày

1. Quét thủ công, thiếu đồng bộ – Khi một developer push code, họ phải nhớ chạy snyk test trên máy cá nhân. Nếu quên, lỗ hổng sẽ đi vào production.
2. Thời gian phản hồi chậm – Đôi khi báo cáo bảo mật chỉ xuất hiện sau 48 giờ khi QA mới thực hiện scan toàn bộ môi trường staging.
3. Chi phí “bảo trì” cao – Mỗi lần phát hiện lỗ hổng, team phải dừng sprint để fix, kéo dài deadline.

🛡️ Cảnh báo: Nếu không có quy trình tự động, tỉ lệ lỗ hổng high/critical trong production trung bình tăng 30 % so với các công ty đã áp dụng CI‑CD security scanning.

Câu chuyện thực tế #1 – “Lỗ hổng “đi qua” trong sprint”

Một startup fintech ở Hà Nội đã triển khai một tính năng thanh toán mới. Do không có workflow quét SAST, một developer bỏ qua lệnh npm audit. Khi tính năng lên production, khách hàng báo lỗi “SQL Injection”. Công ty mất ≈ 150 triệu VND để khắc phục và trả lời khách hàng, đồng thời phải chịu phạt từ ngân hàng.

Câu chuyện thực tế #2 – “Chi phí chạy scan thủ công”

Một công ty phần mềm trung bình ở Đà Nẵng có 5 dự án Node.js. Mỗi tuần, team security dành 8 giờ để chạy snyk test trên từng repo. Tổng chi phí nhân sự 8 giờ × 200 k VND/h = 1,6 triệu VND/tuần, trong khi một workflow tự động chỉ tốn ≈ 300 k VND/tháng cho runner.

Câu chuyện thực tế #3 – “False‑positive làm lãng phí tài nguyên”

Một agency thiết kế web ở TP.HCM đã dùng một công cụ DAST cũ, báo cáo hàng chục lỗ hổng giả. Team phải dành 3 ngày để kiểm tra lại, dẫn đến trễ deadline cho khách hàng lớn. Khi chuyển sang Snyk + CI pipeline, false‑positive giảm 80 %, thời gian xử lý giảm còn 4 giờ.

3. Giải pháp tổng quan (text art)

+-------------------+      +-------------------+      +-------------------+
|   Developer Push  | ---> |   CI Runner (Git) | ---> |   Snyk Scan (SAST)|
+-------------------+      +-------------------+      +-------------------+
                                   |
                                   v
                        +-------------------+
                        |   Snyk Scan (DAST)|
                        +-------------------+
                                   |
                                   v
                        +-------------------+
                        |   Report & Badge  |
                        +-------------------+
                                   |
                                   v
                        +-------------------+
                        |   Pull‑Request    |
                        |   Block / Merge   |
                        +-------------------+

• ⚡ Hiệu năng: Quét hoàn tất trong vòng 2‑5 phút cho mỗi commit.
• 🐛 Bug giảm: Không còn “quên chạy scan”.
• 🛡️ Bảo mật: Lỗ hổng high/critical được ngăn chặn trước khi merge.

4. Hướng dẫn chi tiết từng bước

Bước 1: Chuẩn bị môi trường

# Cài đặt CLI Snyk
npm install -g snyk

# Đăng nhập (cần token từ https://app.snyk.io)
snyk auth <YOUR_TOKEN>

⚠️ Lưu ý: Token phải được lưu dưới dạng GitHub Secret (SNYK_TOKEN) hoặc GitLab CI Variable để không lộ ra repo.

Bước 2: Tạo file cấu hình Snyk (optional)

# .snyk.yml – cấu hình ignore, severity thresholds
version: v1
ignore:
  - "npm:lodash:20180130": # false‑positive
    reason: "Không dùng hàm vulnerable"
severity:
  - high
  - critical

Bước 3: Viết pipeline CI/CD (GitHub Actions ví dụ)

name: Security Scan

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  snyk-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Run Snyk SAST
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        run: |
          snyk test --severity-threshold=high --json > snyk-sast.json
          cat snyk-sast.json

      - name: Run Snyk DAST (container)
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        run: |
          snyk container test myimage:latest --file=Dockerfile --severity-threshold=high

      - name: Upload report
        uses: actions/upload-artifact@v3
        with:
          name: snyk-report
          path: snyk-*.json

Bước 4: Thiết lập “fail fast”

Thêm vào continue-on-error: false (mặc định) để nếu có lỗ hổng high/critical, job sẽ failed và PR không được merge.

Bước 5: Báo cáo và badge

Snyk cung cấp badge Markdown:

![Snyk Security](https://snyk.io/test/github/your-org/your-repo/badge.svg)

Thêm vào README để mọi người luôn thấy trạng thái bảo mật.

5. Template quy trình tham khảo

YAML mẫu cho GitLab CI

stages:
  - test
  - security

snyk_sast:
  stage: security
  image: node:18
  script:
    - npm ci
    - npm install -g snyk
    - snyk test --severity-threshold=high --json > snyk-sast.json
  artifacts:
    paths:
      - snyk-sast.json
  only:
    - merge_requests
    - main

snyk_dast:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t myapp:latest .
    - snyk container test myapp:latest --severity-threshold=high
  only:
    - merge_requests
    - main

6. Những lỗi phổ biến & cách sửa

🛡️ Best Practice: Đặt severity threshold ở mức high để tránh “spam” low‑severity, nhưng vẫn không bỏ qua critical.

7. Khi muốn scale lớn thì làm sao

1. Centralized scanning service – Đặt một server (AWS EC2, GCP Compute) chạy Snyk CLI dưới dạng Docker, các pipeline chỉ gửi request tới service này.
2. Cache layer – Sử dụng actions/cache@v3 để lưu trữ node_modules và snyk cache, giảm thời gian tải xuống.
3. Artifact storage – Lưu báo cáo scan vào S3/Blob storage, cho phép audit lâu dài và compliance.
4. Parallel jobs – Chạy SAST và DAST đồng thời trên các runner riêng biệt để giảm tổng thời gian.

Công thức tính ROI (Return on Investment)

ROI = (Tổng lợi ích – Chi phí đầu tư) / Chi phí đầu tư × 100%

Giải thích:
– Total_Benefits: chi phí giảm do ít phải sửa lỗi (giả sử 2 triệu VND/tuần) + giảm downtime.
– Investment_Cost: chi phí license Snyk (≈ 1 triệu VND/tháng) + runner (≈ 300 k VND/tháng).
– Nếu ROI > 200 % → đầu tư hợp lý.

8. Chi phí thực tế

So sánh với chi phí khắc phục lỗ hổng trung bình 150 triệu VND/incident, ROI rất cao.

9. Số liệu trước – sau

⚡ Kết quả: Giảm 70 % lỗ hổng high/critical, giảm 90 % thời gian phản hồi.

10. FAQ hay gặp nhất

Q1: Cần chạy cả SAST và DAST không?
A: Đối với ứng dụng web, SAST giúp phát hiện lỗi trong code, còn DAST kiểm tra runtime. Hai công cụ bổ trợ nhau; nếu tài nguyên hạn chế, ưu tiên SAST trước khi đưa vào production.

Q2: Làm sao giảm false‑positive?
A: Sử dụng file .snyk.yml để ignore các rule không phù hợp, và cấu hình severity-threshold chỉ báo cáo high/critical.

Q3: Có thể dùng công cụ khác thay Snyk?
A: Có, như Trivy, OWASP Dependency‑Check, Veracode, nhưng Snyk có API dễ tích hợp và badge hiển thị trực quan.

Q4: Pipeline sẽ chậm hơn khi thêm scan?
A: Thêm khoảng 2‑5 phút cho mỗi job; nhưng nhờ cache và parallel jobs, tổng thời gian CI vẫn dưới 10 phút cho hầu hết dự án.

11. Giờ tới lượt bạn

• Bước 1: Tạo token Snyk, lưu vào CI secret.
• Bước 2: Sao chép template YAML ở trên vào repo của bạn.
• Bước 3: Push một commit, quan sát badge và artifact trong Actions/CI.
• Bước 4: Đo lường KPI (thời gian phát hiện, số lỗ hổng) trong 30 ngày đầu.
• Bước 5: Nếu muốn mở rộng, cân nhắc central scanning service và caching như mục 7.

🛡️ Hành động ngay: Đừng để lỗ hổng “đi qua” sprint tiếp theo – hãy tự động hoá ngay hôm nay, bảo vệ sản phẩm và giảm chi phí lâu dài.

Nếu anh em đang cần giải pháp trên, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale. Hoặc liên hệ mình để được trao đổi nhanh hơn nhé.