DevSecOps là gì? Hướng dẫn bảo mật CI/CD và chuỗi cung ứng phần mềm cho đội IT

Tóm tắt nhanh

DevSecOps là cách đưa bảo mật vào toàn bộ vòng đời phát triển phần mềm: từ thiết kế, viết code, review, build, test, release, deploy đến vận hành. Thay vì đợi gần cuối mới kiểm tra bảo mật, DevSecOps đưa kiểm soát bảo mật vào pipeline để phát hiện lỗi sớm, sửa nhanh và giảm rủi ro khi phát hành.

OWASP DevSecOps Guideline mô tả mục tiêu lý tưởng là phát hiện vấn đề bảo mật, gồm lỗi thiết kế và lỗ hổng ứng dụng, càng nhanh càng tốt; guideline cũng đề xuất các bước như secrets scanning, SAST, SCA, IAST, DAST, IaC scanning, infrastructure scanning và compliance checks.¹ NIST SP 800-218, còn gọi là SSDF, định nghĩa một bộ thực hành phát triển phần mềm an toàn có thể tích hợp vào bất kỳ SDLC nào để giảm số lượng lỗ hổng, giảm tác động của lỗ hổng chưa phát hiện và xử lý nguyên nhân gốc.²

Nói đơn giản: DevSecOps không phải là “mua một tool security”. Nó là cách làm để mỗi commit, mỗi pull request, mỗi build và mỗi deployment đều có kiểm tra bảo mật phù hợp.

DevSecOps giải quyết vấn đề gì?

Trong mô hình cũ, security thường xuất hiện muộn:

Code xong → test xong → chuẩn bị release → security review → phát hiện lỗi lớn → trễ deadline

Vấn đề là lỗi bảo mật phát hiện quá muộn, secrets bị commit lên repo, dependency có CVE nhưng không ai biết, image container chứa package lỗi thời, Terraform/Kubernetes manifest cấu hình sai, artifact build không được ký, và không biết binary production được build từ commit nào.

DevSecOps đổi thành:

Thiết kế an toàn → code an toàn → scan sớm → build có kiểm soát
→ ký artifact → deploy theo policy → giám sát runtime

DevSecOps không phải là gì?

DevSecOps tốt phải cân bằng: đủ nghiêm để giảm rủi ro, nhưng không làm developer tìm cách bypass pipeline.

Các lớp bảo mật trong CI/CD

NIST SSDF nói gì?

NIST SP 800-218 chia Secure Software Development Framework thành các nhóm thực hành cấp cao để tích hợp vào SDLC.²

Với đội IT nhỏ, SSDF không nhất thiết phải triển khai toàn bộ ngay. Nhưng nó là khung chuẩn để xây roadmap.

OWASP DevSecOps nói gì?

OWASP DevSecOps Guideline tập trung vào pipeline bảo mật thực tế. Trang project nêu các bước ban đầu gồm scan Git repository để tìm secrets, SAST, SCA, IAST, DAST, IaC scanning, infrastructure scanning và compliance check.¹

Cách dùng thực tế:

secrets scanning → dependency scanning → SAST cơ bản → container/IaC scanning
→ SBOM/signing → DAST → runtime monitoring

SAST, SCA, DAST, IAST là gì?

SAST là Static Application Security Testing. Nó phân tích source code hoặc bytecode mà không cần chạy app. SAST phù hợp phát hiện SQL injection pattern, command injection, path traversal, insecure deserialization, unsafe eval và thiếu input validation. Khi dùng SAST, cần chỉnh rule để tránh false positive quá nhiều.

SCA là Software Composition Analysis. Nó kiểm tra dependencies, package version, CVE và license. SCA nên chạy trên pull request và định kỳ vì CVE mới có thể xuất hiện sau khi code đã merge.

DAST là Dynamic Application Security Testing. Nó kiểm tra app đang chạy từ bên ngoài, thường ở staging hoặc preview environment. DAST phù hợp kiểm tra auth/config sai, security headers thiếu, endpoint lộ, XSS/SQLi dạng runtime, CORS sai, TLS/cookie/session issues.

IAST là Interactive Application Security Testing. Nó chạy cùng app hoặc test runtime để quan sát luồng thực thi. Ưu điểm là có nhiều ngữ cảnh runtime hơn SAST, nhưng cần tích hợp sâu hơn.

Secrets scanning: bước nên làm đầu tiên

Secrets leak là một trong các lỗi phổ biến và nguy hiểm nhất. Chỉ cần một cloud key bị commit, attacker có thể tạo tài nguyên, đọc data hoặc deploy code.

Nên kiểm tra:

• API keys;
• cloud access keys;
• private keys;
• database URL;
• JWT secret;
• OAuth client secret;
• webhook secret;
• npm/pypi/docker token;
• SSH key.

Cách triển khai:

pre-commit hook
  ↓
pull request scan
  ↓
protected branch gate
  ↓
scheduled scan toàn repo
  ↓
secret rotation playbook

Tool phổ biến: Gitleaks, TruffleHog, GitHub secret scanning hoặc tool nội bộ.³ Quan trọng: khi phát hiện secret, không chỉ xóa commit. Phải revoke/rotate secret vì secret đã từng xuất hiện trong Git history.

Dependency security và lockfile

Dependency là phần lớn của phần mềm hiện đại. DevSecOps cần kiểm soát lockfile, package registry, dependency update, CVE triage, license, package provenance, typosquatting và abandoned packages.

Checklist:

• dùng lockfile;
• không auto-upgrade production dependency không review;
• bật Dependabot/Renovate hoặc tool tương đương;
• scan dependency trên PR;
• fail pipeline với critical CVE có exploit nếu không có exception;
• tạo SBOM;
• theo dõi direct và transitive dependency;
• dùng private registry/cache nếu cần;
• hạn chế install script nguy hiểm nếu ecosystem cho phép.

SBOM là gì?

SBOM là Software Bill of Materials: danh sách thành phần phần mềm trong một artifact hoặc sản phẩm. Nó giúp biết app đang dùng package nào, version nào, license nào và có liên quan tới CVE nào. Hai chuẩn phổ biến là CycloneDX và SPDX.⁴⁵

Ví dụ pipeline:

Build image
  ↓
Generate SBOM
  ↓
Scan SBOM
  ↓
Attach SBOM to release
  ↓
Store in artifact registry

SBOM hữu ích khi có CVE mới, cần audit license, cần compliance hoặc cần trace dependency.

Software supply chain security và SLSA

DevSecOps hiện đại không chỉ scan code. Nó còn phải bảo vệ software supply chain: source, dependency, build, artifact, registry và deployment.

SLSA là viết tắt của Supply-chain Levels for Software Artifacts. Trang SLSA mô tả đây là security framework, checklist tiêu chuẩn và controls để ngăn tampering, cải thiện integrity và bảo vệ packages/infrastructure.⁶

SLSA quan tâm đến việc artifact có được build từ source đúng không, build có isolated không, provenance có được tạo tự động không, builder có đáng tin không, ai có quyền thay đổi build pipeline và artifact có bị sửa sau build không.

Mục tiêu thực tế:

Source commit rõ ràng
  ↓
Build trong runner đáng tin
  ↓
Tạo provenance
  ↓
Ký artifact
  ↓
Verify trước deploy

Artifact signing và provenance

Nếu bạn chỉ build container image rồi push registry, attacker có thể tấn công registry, runner, token hoặc tag.

Nên có:

• ký container image;
• ký binary/package;
• tạo provenance;
• verify signature trước deploy;
• không deploy image không ký;
• không dùng tag mutable như latest cho production;
• pin bằng digest.

Sigstore cung cấp hệ sinh thái ký artifact, trong đó Cosign thường dùng để ký container images và artifact.⁷⁸

Ví dụ logic policy:

IF image.signature.valid == true
AND image.provenance.builder == "trusted-ci"
AND image.source.repo == "org/app"
AND image.source.branch == "main"
THEN allow deploy
ELSE block

OIDC thay cho long-lived cloud keys

CI/CD không nên lưu cloud access key dài hạn trong secrets nếu có thể tránh. Nhiều nền tảng CI hiện hỗ trợ OIDC federation để đổi identity của workflow lấy token ngắn hạn.

GitHub mô tả OpenID Connect trong GitHub Actions là cơ chế để workflow yêu cầu short-lived access token trực tiếp từ cloud provider, thay vì lưu long-lived credential trong GitHub.⁹

Mô hình:

GitHub Actions workflow
  ↓ OIDC token có claim repo/branch/environment
Cloud IAM trust policy
  ↓
Short-lived cloud token
  ↓
Deploy

IaC scanning

Infrastructure as Code cũng là code. Terraform, Helm, Kubernetes YAML, Dockerfile và GitHub Actions workflow đều có thể có misconfig.

Nên scan Terraform, Kubernetes manifest, Helm chart, Dockerfile, GitHub Actions/GitLab CI config, cloud resource policy, security group/firewall và IAM policy.

Lỗi thường gặp gồm bucket public, security group mở 0.0.0.0/0, container chạy privileged, secret trong env plain text, IAM wildcard *, Kubernetes pod chạy root, thiếu resource limits và Dockerfile dùng root hoặc base image lỗi thời. Tool phổ biến: Trivy, Checkov, tfsec, kube-linter, kube-score hoặc scanner của cloud provider.¹⁰

CI/CD runner security

Build runner là mục tiêu hấp dẫn. Nếu attacker kiểm soát runner, họ có thể lấy secret, thay artifact hoặc inject code.

Checklist:

• dùng ephemeral runner nếu có thể;
• tách runner cho trusted và untrusted PR;
• không expose secret cho pull request từ fork;
• hạn chế quyền token mặc định;
• pin GitHub Actions bằng SHA nếu cần chặt;
• không chạy build production trên runner shared không tin cậy;
• cleanup workspace sau build;
• network egress hạn chế;
• log không in secret;
• branch protection;
• mandatory review cho workflow changes.

Một quy tắc quan trọng: thay đổi file CI/CD phải được review kỹ như thay đổi production code.

Policy gates: khi nào nên fail pipeline?

Không phải mọi cảnh báo đều nên chặn build. Nếu chặn quá nhiều, developer sẽ tìm cách bypass.

Policy phải dựa trên rủi ro, ngữ cảnh và khả năng xử lý.

Mẫu pipeline DevSecOps

Developer commit
  ↓
pre-commit: secrets + lint
  ↓
Pull Request
  ↓
SAST + SCA + IaC scan + unit tests
  ↓
Code review + security review khi cần
  ↓
Merge to main
  ↓
Build trong runner tin cậy
  ↓
Generate SBOM
  ↓
Sign artifact + generate provenance
  ↓
Container scan
  ↓
Deploy staging
  ↓
DAST + smoke test
  ↓
Policy gate
  ↓
Deploy production
  ↓
Runtime monitoring + vulnerability response

Ví dụ GitHub Actions cơ bản

Ví dụ này minh họa các bước, không phải cấu hình hoàn chỉnh cho mọi dự án:

name: security-ci

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write
  id-token: write

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2

      - name: SAST with Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten

      - name: Filesystem and dependency scan with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          severity: CRITICAL,HIGH
          exit-code: "1"

Trong production, nên pin action version chặt hơn, đặt permissions tối thiểu và tách job theo ngữ cảnh.

DevSecOps cho Kubernetes

Nếu deploy lên Kubernetes, cần thêm image scanning, image signing verification, admission controller, Pod Security Standards, RBAC tối thiểu, NetworkPolicy, secret management, resource limits, runtime detection và audit logs.

Policy deploy mẫu:

Chỉ cho deploy image nếu:
- image được ký;
- provenance hợp lệ;
- SBOM tồn tại;
- không có critical CVE chưa có exception;
- namespace có NetworkPolicy;
- workload không chạy privileged;
- service account không dùng default;
- resource limits đã đặt.

DevSecOps cho AI coding agent

AI coding agent có thể sửa code, chạy command, đọc log, tạo PR, cập nhật dependency và đôi khi deploy. Vì vậy cần mở rộng DevSecOps sang AI workflow.

Checklist:

• không đưa secrets vào prompt;
• agent chạy trong sandbox hoặc user quyền thấp;
• tool allowlist;
• log mọi tool call;
• require review cho PR do agent tạo;
• không auto-merge code agent viết;
• không cho agent tự sửa CI/CD workflow nếu chưa review;
• không cho agent tự rotate/deploy production secret;
• chạy SAST/SCA/IaC scan trên code agent tạo;
• dùng policy “human approval required” cho command nguy hiểm.

Nếu team dùng Claude Code, Codex, Cursor hoặc agent tương tự, DevSecOps pipeline là lớp kiểm soát bắt buộc trước khi code của agent vào main.

Roadmap 30/60/90 ngày

Ngày 1–30: nền tảng nhanh

• Bật branch protection.
• Bắt buộc review PR.
• Bật MFA cho Git hosting.
• Secrets scanning trên PR.
• Dependency scanning cơ bản.
• SAST baseline.
• Tạo security policy cho severity.
• Tạo playbook rotate secret.
• Bật audit log cho Git/CI/CD.

Ngày 31–60: bảo vệ build và artifact

• Tách runner trusted/untrusted.
• Giảm quyền CI token.
• Dùng OIDC thay long-lived cloud keys.
• Build container trong pipeline chuẩn.
• Generate SBOM.
• Scan container image.
• Ký image bằng Sigstore/Cosign.
• Lưu artifact theo digest.
• Không deploy latest.

Ngày 61–90: policy và runtime

• Verify signature trước deploy.
• Deploy gate theo CVE/severity.
• IaC scanning bắt buộc.
• Kubernetes admission policy nếu có K8s.
• DAST trên staging.
• Dependency update automation.
• Runtime security alerting.
• Dashboard security posture.
• SLA fix vulnerability.
• Diễn tập incident “secret leak” và “compromised dependency”.

Metric nên theo dõi

Tooling tham khảo

OpenSSF Scorecard có thể chạy bằng GitHub Action hoặc CLI để đánh giá các practice rủi ro của project open source, như branch protection, dependency updates, token permissions và nhiều checks khác.¹¹

FAQ

DevSecOps là gì?

DevSecOps là cách tích hợp bảo mật vào toàn bộ DevOps pipeline, từ code, review, build, test, release, deploy đến vận hành. Mục tiêu là phát hiện và xử lý lỗi bảo mật sớm, tự động và có trách nhiệm chung giữa Dev, Sec và Ops.

DevSecOps khác AppSec thế nào?

AppSec tập trung vào bảo mật ứng dụng. DevSecOps rộng hơn ở cách tích hợp AppSec, supply chain security, infrastructure security và runtime monitoring vào pipeline DevOps.

Có cần mua nhiều tool không?

Không. Hãy bắt đầu với kiểm soát nền tảng: branch protection, MFA, secrets scanning, dependency scanning, SAST cơ bản và policy severity. Tool chỉ hữu ích nếu findings có owner và được xử lý.

SBOM có bắt buộc không?

Không phải mọi tổ chức đều bắt buộc, nhưng SBOM rất hữu ích để phản ứng nhanh khi có CVE mới và để đáp ứng yêu cầu compliance/supply chain.

SLSA có phải chỉ dành cho open source không?

Không. SLSA áp dụng cho cả open source và commercial software. Trang SLSA nói framework này dành cho producer, consumer và infrastructure provider trong software supply chain.⁶

Khi nào nên fail build?

Nên fail build với secret thật, critical CVE có exploit, SAST high-confidence nghiêm trọng, IaC misconfig nguy hiểm, artifact chưa ký ở release/production và policy vi phạm rõ ràng. Không nên fail vì mọi cảnh báo low-confidence.

Kết luận

DevSecOps là bước tiến tự nhiên của đội IT và engineering khi phần mềm ngày càng phụ thuộc vào cloud, open source, CI/CD và automation. Trọng tâm không phải là “scan cho có”, mà là xây pipeline có khả năng phát hiện sớm, chặn rủi ro lớn, tạo bằng chứng artifact, giảm secret dài hạn và bảo vệ software supply chain.

Cách bắt đầu tốt nhất là làm từng lớp: secrets scanning, SAST/SCA cơ bản, IaC/container scanning, SBOM, artifact signing, OIDC cho CI/CD, policy gates và runtime monitoring. Khi triển khai đúng, DevSecOps giúp đội phát hành nhanh hơn nhưng vẫn có kiểm soát, giảm lỗ hổng tồn đọng và cải thiện niềm tin vào phần mềm đang chạy production.

Nguồn tham khảo

Footnotes

1. OWASP Foundation. “OWASP DevSecOps Guideline.” https://owasp.org/www-project-devsecops-guideline/ ↩ ↩²

2. NIST. “SP 800-218, Secure Software Development Framework (SSDF) Version 1.1.” https://csrc.nist.gov/pubs/sp/800/218/final ↩ ↩²

3. Gitleaks. https://gitleaks.io/ ↩

4. CycloneDX. https://cyclonedx.org/ ↩

5. SPDX. https://spdx.dev/ ↩

6. SLSA. “Supply-chain Levels for Software Artifacts.” https://slsa.dev/ ↩ ↩²

7. Sigstore. https://www.sigstore.dev/ ↩

8. Sigstore Cosign documentation. https://docs.sigstore.dev/cosign/overview/ ↩

9. GitHub Docs. “OpenID Connect.” https://docs.github.com/en/actions/concepts/security/openid-connect ↩

10. Trivy. https://trivy.dev/ ↩

11. OpenSSF Scorecard. “Build better security habits, one test at a time.” https://securityscorecards.dev/ ↩