Platform Engineering 4 — CI/CD & Bảo mật chuỗi cung ứng

Trong Platform Engineering — Tổng quan, platform team cung cấp cho developer những golden path — con đường chuẩn, tự phục vụ, an toàn. Nếu IaC là cách tạo hạ tầng và GitOps là cách triển khai, thì CI/CD chính là băng chuyền biến code thành artifact chạy được. Bài này ôn nhanh CI/CD hiện đại, nhưng trọng tâm là hai góc nhìn ít được nói tới: (1) CI/CD như một platform capability chứ không phải script mỗi team tự viết, và (2) bảo mật chuỗi cung ứng phần mềm (software supply chain security) — điểm nóng nhất của DevSecOps giai đoạn 2023–2025 sau hàng loạt vụ tấn công.

Ôn nhanh CI/CD hiện đại

CI (Continuous Integration) là việc tự động build và kiểm thử mỗi khi code được đẩy lên Git, để phát hiện lỗi sớm và giữ nhánh chính luôn ở trạng thái "xanh". CD có hai nghĩa chồng nhau: Continuous Delivery (luôn sẵn sàng deploy, nhưng bấm nút thủ công) và Continuous Deployment (deploy tự động khi qua hết cổng kiểm tra).

Một pipeline điển hình đi qua các giai đoạn:

build  →  test  →  scan  →  package  →  deploy

• Build: biên dịch code, tạo binary/bundle.
• Test: unit test, integration test, lint, đo coverage.
• Scan: quét lỗ hổng bảo mật (dependency, image, secrets) — giai đoạn mà phần lớn pipeline cũ bỏ qua.
• Package: đóng gói thành container image, đẩy lên registry với tag/digest cố định.
• Deploy: đưa lên môi trường, thường qua GitOps hoặc lệnh deploy trực tiếp.

Công cụ phổ biến: GitHub Actions (workflow YAML trong .github/workflows), GitLab CI (.gitlab-ci.yml), Jenkins (Jenkinsfile, mạnh về on-prem nhưng nặng vận hành), cùng các lựa chọn khác như CircleCI, Tekton, Argo Workflows.

Một chuẩn mực quan trọng của CI hiện đại là ephemeral runners — máy chạy job được tạo mới tinh cho mỗi lần chạy rồi hủy ngay sau đó. Runner "sống lâu" (persistent) là rủi ro bảo mật lớn: secret bị cache lại, artifact của job trước còn sót, kẻ tấn công cắm cửa hậu tồn tại qua nhiều lần build. Runner ephemeral loại bỏ toàn bộ lớp rủi ro này và đảm bảo build có tính tái lập.

CI/CD như một Platform Capability

Đây là điểm khác biệt cốt lõi giữa "DevOps truyền thống" và "platform engineering". Trong mô hình cũ, mỗi team tự viết pipeline của mình — dẫn tới hàng chục biến thể YAML sao chép qua lại, không ai vá lỗ hổng đồng bộ, mỗi team lại quên một bước bảo mật khác nhau. Platform team giải bài toán này bằng pipeline chuẩn.

Cả hai hệ sinh thái lớn đều hỗ trợ tái sử dụng:

• GitHub Actions: reusable workflows (workflow_call) và composite actions — team chỉ cần gọi một dòng, toàn bộ logic build-scan-sign nằm ở repo trung tâm do platform team bảo trì.
• GitLab CI: include: template và CI/CD components — kế thừa một pipeline chuẩn thay vì viết lại.

Ý tưởng golden path ở đây: developer không tự viết lại pipeline. Họ khai báo "tôi là một service Java/Python", platform cung cấp pipeline chuẩn đã tích hợp sẵn test, scan, ký artifact, sinh SBOM và bàn giao cho GitOps. Khi platform team vá một lỗ hổng hay thêm một cổng kiểm tra, toàn bộ service trong tổ chức được nâng cấp cùng lúc mà không team nào phải sửa gì.

Kết nối với GitOps rất tự nhiên và là mô hình được khuyến nghị hiện nay:

• CI lo build & push: compile, test, scan, ký, sinh SBOM, đẩy image lên registry.
• CD do GitOps lo: CI chỉ cập nhật một dòng image tag/digest trong repo cấu hình (config repo); Argo CD phát hiện thay đổi và đồng bộ cluster về đúng trạng thái mong muốn.

Ranh giới này quan trọng: CI không có quyền truy cập trực tiếp vào cluster production. CI chỉ tạo artifact và commit; việc áp dụng lên cluster do controller GitOps kéo về (pull), giảm mạnh bề mặt tấn công.

Bảo mật chuỗi cung ứng phần mềm

Từ năm 2020 trở đi, một loạt vụ tấn công đã đưa supply chain security thành ưu tiên số một: SolarWinds (2020), Log4Shell (2021), Codecov, và đặc biệt các vụ chèn mã độc vào thư viện npm/PyPI diễn ra liên tục 2023–2025. Bài học chung: kẻ tấn công không cần đột nhập vào bạn — họ đầu độc một dependency hoặc một bước trong pipeline của bạn, rồi mã độc tự động lan tới mọi nơi dùng nó.

Chuỗi cung ứng phần mềm gồm mọi thứ đi vào sản phẩm cuối: thư viện bên thứ ba, base image, công cụ build, plugin CI, và cả bản thân pipeline. Bảo vệ nó cần nhiều lớp phòng thủ.

SBOM — Software Bill of Materials

SBOM là "bảng kê thành phần" — danh sách đầy đủ mọi thư viện, phiên bản và license có trong một artifact, tương tự bảng thành phần in trên bao bì thực phẩm. Hai định dạng chuẩn: SPDX và CycloneDX. Công cụ như syft sinh SBOM từ source hoặc image.

Vì sao quan trọng? Khi Log4Shell nổ ra, câu hỏi sống còn là "ta có dùng log4j phiên bản dính lỗi ở đâu không?". Ai có SBOM cho mọi artifact thì trả lời trong vài phút; ai không có thì mất hàng tuần rà tay. SBOM biến câu hỏi "ta có bị ảnh hưởng không" từ một cuộc điều tra thành một lệnh tra cứu.

Quét lỗ hổng: SCA và image scanning

SCA (Software Composition Analysis) quét các dependency để đối chiếu với cơ sở dữ liệu lỗ hổng (CVE). Quét image container còn kiểm tra cả các gói OS trong base image. Công cụ phổ biến: Trivy, Grype, Snyk, Dependabot. Pipeline chuẩn nên chặn (fail) khi phát hiện lỗ hổng nghiêm trọng (critical/high) chưa có ngoại lệ được duyệt.

Phân biệt nhanh các loại quét:

Ký và xác minh artifact — Sigstore/cosign

Quét cho biết artifact có sạch không; ký (signing) cho biết artifact có đúng nguồn gốc không. Sigstore là dự án mã nguồn mở (Linux Foundation) làm cho việc ký trở nên dễ; cosign là công cụ ký container image và artifact. Điểm hay của Sigstore là mô hình keyless signing: thay vì quản lý khóa riêng lâu dài (dễ rò rỉ), danh tính người/pipeline ký được chứng thực qua OIDC và ghi vào một sổ cái công khai (transparency log, tên là Rekor). Bên tiêu thụ image dùng cosign verify để đảm bảo image đúng là do pipeline hợp lệ tạo ra, không bị tráo giữa đường.

Provenance, attestation và khung SLSA

Provenance là bằng chứng "artifact này được build từ commit nào, bởi pipeline nào, lúc nào". Attestation là một khẳng định có chữ ký gắn kèm artifact (SBOM cũng có thể là một attestation, kết quả scan cũng vậy). SLSA (Supply-chain Levels for Software Artifacts, đọc là "salsa") là khung phân cấp mức độ trưởng thành supply chain, từ Level 0 (không có gì) tới các mức cao yêu cầu build trên hệ thống cô lập và provenance không thể giả mạo. SLSA cho tổ chức một thang đo để đặt mục tiêu tiến bộ thay vì "làm bảo mật cho có".

Nguyên tắc nền tảng

• Pin phiên bản: khóa dependency theo phiên bản chính xác và tốt nhất là theo hash/digest, không dùng tag trôi (latest) vốn có thể bị đổi ngầm dưới chân bạn.
• Quét secrets: chặn commit chứa API key, token, mật khẩu ngay tại pipeline và pre-commit hook.
• Least-privilege cho pipeline — OIDC thay long-lived key: đây là thay đổi lớn nhất. Thay vì lưu một AWS access key vĩnh viễn trong secret của CI (rò một lần là mất toàn bộ), pipeline dùng OIDC để đổi lấy một credential ngắn hạn (vài phút) đúng lúc cần, giới hạn đúng quyền tối thiểu. Chi tiết quản lý bí mật xem Platform 6 — Secrets & Security và Kiểm soát truy cập & mã hóa.

Chất lượng, Policy Gate và Đo lường

Bảo mật chỉ là một họ của các cổng kiểm tra (gate). Một pipeline chín chắn còn chặn deploy nếu test thất bại, lint không đạt, hoặc coverage tụt dưới ngưỡng.

Policy-as-code đưa các quy tắc này thành code có thể review và version. Công cụ như OPA/Conftest hay Kyverno cho phép viết chính sách kiểu "không được deploy image chưa ký", "không được có lỗ hổng critical", "SBOM phải tồn tại" — và pipeline tự động từ chối nếu vi phạm. Ưu điểm: quy tắc minh bạch, kiểm toán được, áp dụng nhất quán mọi team.

Để biết pipeline có thực sự hiệu quả, dùng DORA metrics — bốn chỉ số kinh điển của DevOps:

Điểm tinh tế: bảo mật và tốc độ không đối nghịch. Team làm supply chain security tốt thường có DORA cao hơn, vì tự động hóa scan/sign loại bỏ các cửa duyệt thủ công chậm chạp.

Kết hợp Progressive Delivery và Rollback

Deploy qua cổng chưa phải hết rủi ro — code có thể qua mọi test mà vẫn hỏng khi gặp lưu lượng thật. Progressive delivery giảm rủi ro bằng cách phát hành từ từ: canary (đẩy cho 5% người dùng, theo dõi lỗi/độ trễ rồi mới mở rộng) hoặc blue-green (chạy song song hai môi trường, chuyển traffic tức thì). Kết hợp GitOps, rollback đơn giản: revert commit trong config repo, controller tự đưa cluster về phiên bản trước — mọi thay đổi production là một commit, hoàn tác bằng một commit.

Sơ đồ pipeline có cổng bảo mật

Ví dụ pipeline YAML rút gọn (minh họa)

Dưới đây là một GitHub Actions workflow minh họa thể hiện các bước scan/sign/SBOM. Cấu hình thật cần điều chỉnh cho registry, quyền và công cụ cụ thể của tổ chức.

# Minh họa — không phải cấu hình sản xuất
name: build-secure
on: [push]

permissions:
  contents: read
  id-token: write   # OIDC: cấp token ngắn hạn, không dùng key vĩnh viễn
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest   # runner ephemeral
    steps:
      - uses: actions/checkout@v4

      - name: Run tests
        run: make test lint coverage

      - name: Build & push image
        run: |
          docker build -t $IMAGE:$GITHUB_SHA .
          docker push $IMAGE:$GITHUB_SHA

      - name: SCA + image scan (chặn nếu critical)
        uses: aquasecurity/[email protected]
        with:
          image-ref: $IMAGE:$GITHUB_SHA
          severity: CRITICAL,HIGH
          exit-code: '1'

      - name: Sinh SBOM (CycloneDX)
        run: syft $IMAGE:$GITHUB_SHA -o cyclonedx-json > sbom.json

      - name: Ký image + đính SBOM (keyless cosign)
        run: |
          cosign sign --yes $IMAGE:$GITHUB_SHA
          cosign attest --yes --predicate sbom.json \
            --type cyclonedx $IMAGE:$GITHUB_SHA

      - name: Cập nhật config repo (kích hoạt GitOps)
        run: ./scripts/bump-image-tag.sh $GITHUB_SHA

Bối cảnh ngân hàng

Ở ngân hàng, CI/CD là một phần của khung kiểm soát thay đổi (change control) chịu thanh tra. Ba yêu cầu nổi bật:

• Phân tách nhiệm vụ (Segregation of Duties — SoD): người viết code không được tự phê duyệt và tự đưa code của mình lên production. Pipeline thực thi bằng branch protection (bắt buộc reviewer khác), cổng phê duyệt thủ công cho production, và tách vai người trigger deploy khỏi người viết.
• Audit pipeline: mọi lần build, scan, ký, deploy để lại log bất biến — ai chạy, commit nào, kết quả scan, ai duyệt. Đây là bằng chứng tuân thủ khi thanh tra hỏi "phiên bản đang chạy production được kiểm chứng thế nào".
• Chứng minh nguồn gốc: provenance + chữ ký cosign trả lời câu hỏi kiểm toán "làm sao biết binary trên production đúng là build từ code đã review, không bị tráo".

Chính SoD, audit và provenance biến các thực hành supply chain security từ "nên có" thành "bắt buộc" trong ngân hàng.

Use case thực tế

Bối cảnh — NCB, pipeline chuẩn cho dịch vụ dữ liệu. Team dữ liệu NCB vận hành hàng chục microservice (API phục vụ mô hình rủi ro, job tổng hợp dữ liệu, service chấm điểm). Trước đây mỗi service có một .gitlab-ci.yml sao chép tay: có service quét lỗ hổng, có service không; không service nào ký image; khi một CVE nghiêm trọng trong thư viện Python nổ ra, team mất gần một tuần rà tay xem service nào bị ảnh hưởng.

Giải pháp — golden path pipeline. Platform team xây một CI/CD component dùng chung (một reusable pipeline), mọi service chỉ cần include vài dòng. Luồng chuẩn:

1. Build trên runner ephemeral.
2. Test + coverage (chặn nếu coverage < 70%).
3. Scan SCA + image bằng Trivy (chặn nếu có CVE critical chưa được duyệt ngoại lệ).
4. Ký cosign keyless qua OIDC — không còn key vĩnh viễn trong CI.
5. Sinh SBOM CycloneDX và lưu kèm artifact.
6. GitOps deploy: CI cập nhật image digest vào config repo, Argo CD đồng bộ lên cluster (canary trước, full sau).

Kết quả (số liệu ước lượng minh họa cho quy mô này):

• Với ~40 service quét trung bình mỗi tháng, pipeline chặn khoảng 50–70 lỗ hổng critical/high trước khi lên production — trước đây phần lớn số này lọt qua rồi mới vá gấp.
• Khi CVE mới công bố, nhờ SBOM tập trung, thời gian trả lời "service nào bị ảnh hưởng" giảm từ ~5 ngày xuống dưới 30 phút (một truy vấn trên kho SBOM).
• 100% image lên production đều được ký và xác minh; Argo CD từ chối image không chữ ký hợp lệ qua policy Kyverno.
• Lead time deploy giảm dù thêm cổng bảo mật, vì bỏ được bước duyệt thủ công rời rạc và tự động hóa toàn bộ.

Bài học: khi bảo mật được đóng gói thành golden path, dev không phải "gánh thêm việc" — họ được an toàn miễn phí, còn platform team vá một chỗ là cả tổ chức được vá.

Ghi nhớ

• CI/CD hiện đại đi theo chuỗi build → test → scan → package → deploy, chạy trên ephemeral runner để tránh rò rỉ và đảm bảo tái lập.
• Coi CI/CD là platform capability: pipeline chuẩn (reusable workflow/template) là golden path — dev không tự viết lại, platform vá một lần là toàn tổ chức được nâng cấp.
• Mô hình khuyến nghị: CI build & push image, CD do GitOps — CI không chạm trực tiếp vào cluster production, giảm bề mặt tấn công.
• Bảo mật chuỗi cung ứng là điểm nóng 2023–2025: SBOM (SPDX/CycloneDX) để kê thành phần, SCA/image scan (Trivy/Grype) để bắt CVE, ký cosign/Sigstore để xác minh nguồn gốc, provenance/attestation theo SLSA để chứng minh cách build.
• Nguyên tắc nền: pin phiên bản theo digest, quét secrets, và OIDC thay long-lived key để pipeline chạy least-privilege với credential ngắn hạn.
• Policy-as-code (OPA/Conftest, Kyverno) chặn deploy khi không đạt; DORA metrics đo hiệu quả — bảo mật tốt thường đi cùng tốc độ cao chứ không đối nghịch.
• Kết hợp progressive delivery (canary/blue-green) và rollback bằng revert commit để giảm rủi ro phát hành.
• Ngân hàng bắt buộc SoD, audit pipeline và chứng minh nguồn gốc — supply chain security ở đây là yêu cầu tuân thủ, không phải tùy chọn.

Nguồn tham khảo

• GitHub Actions Documentation — reusable workflows, composite actions, OIDC hardening (id-token: write), ephemeral runners.
• SLSA — Supply-chain Levels for Software Artifacts — khung phân cấp mức độ, provenance và attestation.
• Sigstore Documentation — cosign, keyless signing, Rekor transparency log.
• Trivy Documentation (Aqua Security) — SCA, image scanning, cấu hình severity/exit-code.
• CycloneDX Specification và SPDX Specification — hai định dạng SBOM chuẩn.
• Open Policy Agent / Conftest Documentation — policy-as-code cho pipeline gate.
• Jez Humble & David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley, 2010).
• Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and DevOps (IT Revolution, 2018) — nguồn gốc bộ DORA metrics.
• NIST SP 800-218, Secure Software Development Framework (SSDF).