Bảo Mật Chuỗi Cung Ứng Dụng: SBOM, SLSA và Chữ Ký Artifact Cho Developer

Karify98 & Amy 🌸·May 31, 2026

#devops #supplychain #security #slsa #cicd

Một câu hỏi đáng suy nghĩ: cái binary đang chạy trên production có thực sự được build từ chính source code mà team review không? Hay ai đó đã chèn thứ gì vào giữa pipeline?

SolarWinds, Log4Shell, vụ backdoor xz utils — mỗi sự cố là một lời nhắc nhở: bảo mật code là chưa đủ, cần bảo mật toàn bộ thứ chạm vào code. Dependency, build system, artifact registry, deployment pipeline — mỗi mắt xích là một điểm tấn công tiềm năng.

Đến 2026, bảo mật chuỗi cung ứng (supply chain security) không còn là nice-to-have. US Executive Order 14028 và EU Cyber Resilience Act đã yêu cầu SBOM bắt buộc cho phần mềm bán cho chính phủ. Các cloud provider lớn yêu cầu SLSA compliance cho marketplace. Khách hàng enterprise bắt đầu hỏi về provenance attestation.

Bài viết này sẽ hướng dẫn triển khai ba trụ cột của supply chain security — SBOM, SLSA, và ký artifact — một cách thực chiến, không vẽ vời.

Bề Mặt Tấn Công: Không Biết Mình Đang Chạy Gì

Hãy thành thật trả lời ba câu hỏi:

Có liệt kê được mọi dependency, kể cả transitive, trong container production không?
Có chứng minh được binary đang chạy trên production được build từ chính source code đã review không?
Có xác minh được không ai sửa artifact giữa CI pipeline và production cluster không?

Nếu câu trả lời là "không" cho bất kỳ câu nào, chuỗi cung ứng đang có lỗ hổng.

Mô hình đơn giản hóa:

Source Code → Build System → Package Registry → Container Registry → Production
     ↑            ↑                ↑                  ↑               ↑
 Malicious    Compromised    Typosquatting       Image          Runtime
  commits      CI runner      packages         tampering       injection

Ba trụ cột dưới đây giải quyết từng mắt xích trong chuỗi này.

Trụ Cột 1: SBOM — Biết Đang Chạy Gì

SBOM (Software Bill of Materials) là bản kê khai đầy đủ, machine-readable, của mọi thành phần trong phần mềm. Giống như nhãn dinh dưỡng cho code vậy.

Một SBOM tiêu chuẩn bao gồm:

Mọi dependency trực tiếp và transitive, kèm version
License của từng component
Supplier information
Các CVE đã biết (khi cross-reference với vulnerability database)

Hai Định Dạng Chính

SPDX (Software Package Data Exchange): Tiêu chuẩn ISO/IEC 5962:2021, do Linux Foundation duy trì. Ưa chuộng bởi chính phủ Mỹ.
CycloneDX: Do OWASP duy trì, tập trung vào security use cases. Thực tế hơn cho internal security.

Generate SBOM Ngay Trong CI/CD

Tool phổ biến nhất hiện nay là Syft (Anchore) và Trivy (Aqua Security):

# Generate SBOM cho container image
syft registry.example.com/myapp:v1.0 -o spdx-json > sbom.spdx.json

# Generate SBOM + scan CVE cùng lúc với Trivy
trivy image --format cyclonedx --output sbom.cdx.json myapp:v1.0

Tích hợp vào GitHub Actions:

name: Build with SBOM
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: myapp:${{ github.sha }}
          format: spdx-json
      - name: Scan SBOM for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'image'
          image-ref: 'myapp:${{ github.sha }}'
          format: 'table'
          severity: 'CRITICAL,HIGH'
          exit-code: 1

Flow này đảm bảo: mỗi lần push lên main, có ngay một SBOM kèm kết quả scan CVE. Nếu có CVE critical, pipeline fail — không ai merge được.

Trụ Cột 2: SLSA — Chứng Minh Code Được Build Đúng Cách

SLSA (Supply-chain Levels for Software Artifacts, đọc là "salsa") là framework xác định mức độ toàn vẹn của build process. Nó trả lời câu hỏi: "Có chứng minh được artifact này được build từ source code này, bằng build process này, không bị can thiệp?"

Bốn Cấp Độ SLSA

Level 0: Không có gì đảm bảo. Build trên laptop rồi push lên thẳng. Không provenance, không verification.
Level 1: Có provenance attestation — một tài liệu ký xác nhận artifact này được build từ commit nào, ngày nào, hệ thống nào. Nhưng chưa tamper-proof.
Level 2: Build chạy trên hosted service (GitHub Actions, Cloud Build) và provenance được ký bởi chính nền tảng đó. Ngăn developer falsify provenance.
Level 3: Build chạy trong môi trường isolated, ephemeral. Không ai — kể cả maintainer — có thể chèn material vào build mà không bị ghi nhận.

Mục tiêu thực tế: Level 2 cho hầu hết dự án, Level 3 cho critical software.

GitHub Actions Tích Hợp Sẵn SLSA

name: Build with SLSA
on:
  push:
    tags: ['v*']
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}
      - name: Generate SLSA provenance
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true

Workflow này tự động tạo signed attestation chứng minh: repo nào, commit nào, workflow nào đã build ra artifact đó.

Verify Provenance

Bất kỳ ai cũng có thể verify với GitHub CLI:

gh attestation verify oci://ghcr.io/myorg/myapp:v1.0 --owner myorg

Trụ Cột 3: Cosign — Ký Artifact, Chống Giả Mạo

Cosign là tool của Sigstore project, cho phép ký container image và mọi artifact OCI. Nó trả lời câu hỏi cuối cùng: "Có ai sửa artifact này sau khi build không?"

Ký Với Keyless Signing (OIDC)

Cách đơn giản nhất không cần quản lý private key:

# Ký image dùng OIDC identity từ GitHub Actions
cosign sign ghcr.io/myorg/myapp:v1.0

Trong CI pipeline:

- name: Sign container image
  uses: sigstore/cosign-installer@v3
- run: |
    cosign sign \
      --certificate-identity-regexp "https://github.com/${{ github.repository }}" \
      --certificate-oidc-issuer https://token.actions.githubusercontent.com \
      ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

Verify Chữ Ký Trước Khi Deploy

cosign verify \
  --certificate-identity-regexp "https://github.com/myorg/myapp" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/myorg/myapp:v1.0

Điều này nên được tích hợp vào admission controller của Kubernetes (ví dụ: Kyverno hoặc OPA Gatekeeper) để từ chối deploy bất kỳ image nào không có chữ ký hợp lệ. Đây chính là enforcement point cuối cùng — lý thuyết thành thực tế.

Kết Hợp Cả Ba Trong Một Pipeline Thực Tế

Dưới đây là pipeline hoàn chỉnh kết hợp SBOM + SLSA + Cosign:

name: Secure Build Pipeline
on:
  push:
    tags: ['v*']
permissions:
  contents: read
  id-token: write
  attestations: write
  packages: write

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

      - name: Build image
        id: build
        uses: docker/build-push-action@v5
        with:
          context: .
          push: false
          load: true
          tags: myapp:${{ github.sha }}

      # Trụ cột 1: Generate SBOM
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: myapp:${{ github.sha }}
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Scan vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: table
          severity: CRITICAL
          exit-code: 1

      # Push sau khi scan pass
      - name: Push image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}

      # Trụ cột 2: SLSA Provenance
      - name: Generate provenance
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true

      # Trụ cột 3: Cosign Signing
      - uses: sigstore/cosign-installer@v3
      - name: Sign image
        run: |
          cosign sign \
            --certificate-identity-regexp "https://github.com/${{ github.repository }}" \
            --certificate-oidc-issuer https://token.actions.githubusercontent.com \
            ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

Take-Aways Cho Developer

Bắt đầu với SBOM ngay hôm nay: Syft hoặc Trivy, thêm vào CI pipeline mất 5 phút. Biết đang chạy gì là bước đầu tiên.
SLSA Level 2 là low-hanging fruit: Nếu dùng GitHub Actions, attest-build-provenance đã có sẵn, chỉ cần thêm 1 step.
Cosign cho production deployments: Ký tất cả image trước khi push lên registry, verify trước khi deploy.
Enforce ở cuối pipeline: Dùng Kyverno hoặc OPA để chặn image không có chữ ký, không có SBOM, không có provenance.
Quy định đang đến: Dù không bán cho chính phủ Mỹ, enterprise customer sẽ sớm yêu cầu những thứ này. Chuẩn bị trước luôn rẻ hơn chạy theo.

Kết

Supply chain security không phải là thứ làm một lần rồi xong. Nó là một lớp bảo vệ liên tục, từ lúc git push cho đến khi container chạy trên production. SBOM cung cấp visibility, SLSA cung cấp trust, Cosign cung cấp integrity verification.

Ba công cụ này đều miễn phí, open source, và có thể tích hợp vào CI/CD pipeline hiện tại trong vài giờ — không phải vài tuần. Bắt đầu từ repo quan trọng nhất của team, deploy một pipeline như trên, và xem điều gì xảy ra.

Đã triển khai supply chain security cho production workloads của team chưa? Nếu chưa, điều gì đang cản trở?

Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.