SBOM Và SCA Trong Doanh Nghiệp: Quản Lý Rủi Ro Chuỗi Cung Ứng Phần Mềm Năm 2026

SBOM và SCA đang trở thành hai năng lực nền tảng trong bảo mật chuỗi cung ứng phần mềm. Khi một ứng dụng hiện đại có thể kéo theo hàng trăm thư viện npm, PyPI, Maven, container image layer và package hệ điều hành, câu hỏi “chúng ta đang chạy những thành phần nào?” không còn là chuyện giấy tờ. Nó quyết định tốc độ phản ứng khi có CVE nghiêm trọng, khả năng đáp ứng audit và mức độ an toàn trước khi release.

Bài viết này đi theo góc nhìn thực chiến cho doanh nghiệp: SBOM là gì, SCA khác gì vulnerability scanner thông thường, thiết kế quy trình trong CI/CD, ví dụ lệnh tạo SBOM và quét dependency, cách ưu tiên xử lý CVE, lỗi thường gặp, checklist nghiệm thu và một bài lab cuối bài.

1. SBOM và SCA là gì?

SBOM là Software Bill of Materials, tức danh sách thành phần phần mềm của một artifact: package, library, version, license, checksum, dependency relationship và metadata liên quan. Có thể hiểu SBOM như “bảng thành phần” của một container image hoặc ứng dụng.

SCA là Software Composition Analysis. SCA phân tích dependency mã nguồn/container để phát hiện lỗ hổng, license risk, package lỗi thời, dependency không được bảo trì hoặc package có dấu hiệu độc hại. SBOM trả lời “có gì bên trong”; SCA trả lời “thành phần đó có rủi ro gì và có nên cho đi tiếp không”.

SBOM: inventory có cấu trúc, thường theo chuẩn CycloneDX hoặc SPDX.
SCA: phân tích rủi ro từ inventory/dependency và đưa ra finding.
Policy gate: quy tắc quyết định build được đi tiếp hay bị chặn.
VEX: thông tin một CVE có thực sự ảnh hưởng artifact cụ thể hay không.

2. Vì sao doanh nghiệp cần SBOM/SCA trong năm 2026?

Rủi ro phần mềm không chỉ nằm ở code do team tự viết. Một package nhỏ bị takeover, một maintainer account bị lộ, một container base image cũ hoặc một transitive dependency dính CVE có thể trở thành điểm vào của attacker. Khi có sự cố kiểu Log4Shell, câu hỏi đầu tiên của lãnh đạo thường là: “Hệ thống nào của mình đang dùng thư viện này?”. Nếu không có SBOM/inventory, team phải grep thủ công từng repo, từng image và từng server.

SBOM/SCA giúp:

Tìm nhanh ứng dụng bị ảnh hưởng bởi CVE mới.
Chặn dependency rủi ro trước khi vào production.
Chuẩn hóa báo cáo cho audit, khách hàng enterprise và compliance.
Giảm tranh cãi giữa Dev, Sec và Ops bằng dữ liệu cụ thể.
Hỗ trợ quản lý license open-source.
Xây dựng baseline cho DevSecOps thay vì quét bảo mật cuối dự án.

3. Kiến trúc triển khai SBOM/SCA trong CI/CD

3.1. Điểm tạo SBOM

SBOM nên được tạo ở nhiều tầng:

Source level: phân tích package manifest như package-lock.json, requirements.txt, pom.xml, go.mod.
Build artifact: tạo SBOM sau khi build để phản ánh chính xác artifact phát hành.
Container image: phân tích cả app dependency lẫn OS packages trong image.

3.2. Nơi lưu SBOM

SBOM không nên nằm rải rác trong log CI. Hãy lưu cùng artifact trong registry, object storage hoặc dependency-track. Mỗi SBOM cần gắn với commit SHA, build number, image digest và môi trường deploy.

3.3. Policy gate

Policy gate nên phân biệt severity và exploitability. Ví dụ: fail build nếu có CVE critical có fix version và package đang reachable; cảnh báo nếu medium chưa có fix; bắt buộc review nếu license thuộc nhóm cấm.

4. Ví dụ tạo SBOM bằng Syft

Cài Syft trên Linux lab:

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
syft version

Tạo SBOM CycloneDX cho một container image:

syft nginx:1.25 -o cyclonedx-json > nginx-1.25.sbom.json
head -n 20 nginx-1.25.sbom.json

Output sẽ có metadata và danh sách component. Một đoạn rút gọn:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {"name": "openssl", "version": "3.0.x", "type": "library"}
  ]
}

Với source code Node.js:

cd my-node-app
npm ci
syft dir:. -o spdx-json > app.spdx.json

Điểm quan trọng: SBOM phải tạo từ trạng thái dependency đã lock. Nếu không dùng lockfile, hôm nay và ngày mai cùng một source có thể kéo dependency khác nhau.

5. Quét lỗ hổng bằng Grype hoặc OWASP Dependency-Check

Cài Grype:

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
grype version

Quét trực tiếp image:

grype nginx:1.25 --fail-on critical

Quét từ SBOM đã tạo:

grype sbom:nginx-1.25.sbom.json --output table

Output mẫu:

NAME       INSTALLED  FIXED-IN  TYPE  VULNERABILITY   SEVERITY
openssl    3.0.x      3.0.y     deb   CVE-2026-XXXX   High
zlib       1.2.x                deb   CVE-2025-YYYY   Medium

Trong CI, bạn có thể fail build khi có critical:

grype sbom:app.sbom.json --fail-on critical

Tuy nhiên, production policy không nên chỉ dựa vào CVSS. Hãy kết hợp: có exploit public không, package có được gọi trong runtime không, service có exposed Internet không, có fix version không và có compensating control không.

6. Ví dụ GitHub Actions pipeline

name: sbom-sca
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Syft
        run: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sudo sh -s -- -b /usr/local/bin
      - name: Install Grype
        run: curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sudo sh -s -- -b /usr/local/bin
      - name: Generate SBOM
        run: syft dir:. -o cyclonedx-json > app.sbom.json
      - name: Scan SBOM
        run: grype sbom:app.sbom.json --fail-on critical
      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-sbom
          path: app.sbom.json

Với GitLab CI hoặc Jenkins, nguyên tắc tương tự: tạo SBOM, scan, lưu artifact, áp policy. Đừng chỉ in report ra console rồi mất dấu.

7. Cách ưu tiên xử lý CVE

Một hệ thống lớn có thể sinh hàng nghìn finding. Nếu mọi finding đều “khẩn cấp”, cuối cùng không finding nào được xử lý nghiêm túc. Hãy dùng ma trận ưu tiên:

P0: critical/high, có exploit, service Internet-facing, có fix version hoặc workaround rõ.
P1: high nhưng không exposed trực tiếp, cần upgrade trong sprint gần nhất.
P2: medium/low, theo dõi và gom vào maintenance window.
Accepted risk: có lý do, owner, expiry date và bằng chứng VEX nếu phù hợp.

Ví dụ runbook khi có CVE mới:

# 1. Tìm artifact bị ảnh hưởng trong SBOM repository
# 2. Kiểm tra service owner và môi trường deploy
# 3. Xác nhận package có reachable/exploitable không
# 4. Tạo ticket upgrade hoặc mitigation
# 5. Release bản vá, scan lại, lưu bằng chứng

8. Lỗi thường gặp khi triển khai SBOM/SCA

8.1. Chỉ quét repository, bỏ qua container image

Repo scan không thấy package hệ điều hành trong image. Container scan lại có thể thấy package không nằm trong source. Production cần cả hai.

8.2. Không lock dependency

Không có lockfile khiến SBOM không tái lập được. Hãy dùng package-lock.json, poetry.lock, go.sum, Maven/Gradle lock hoặc cơ chế tương đương.

8.3. Fail build quá gắt ngay ngày đầu

Nếu bật fail-on high cho toàn bộ legacy repo, pipeline có thể đỏ hàng loạt và team sẽ tìm cách bỏ qua. Nên bắt đầu bằng observe mode, tạo baseline, rồi tăng dần policy cho repo mới hoặc service critical.

8.4. Không có owner cho finding

SCA report không có người chịu trách nhiệm thì chỉ là dashboard đẹp. Mỗi service cần owner, SLA xử lý và kênh escalation.

8.5. Không lưu bằng chứng sau khi fix

Audit cần bằng chứng: SBOM phiên bản cũ, finding, ticket, commit fix, bản scan sạch sau release. Hãy tự động lưu artifact scan theo build.

9. Checklist nghiệm thu

Có SBOM chuẩn CycloneDX hoặc SPDX cho artifact release.
SBOM gắn với commit SHA, build number và image digest.
SCA chạy tự động trong CI/CD, không phụ thuộc thao tác thủ công.
Có policy rõ cho critical/high/medium và license risk.
Có cơ chế exception: owner, lý do, expiry date, review định kỳ.
Report được lưu lâu dài, không chỉ nằm trong CI log.
Finding có ticket và service owner.
Đã test pipeline fail khi có critical giả lập.
Đã có runbook phản ứng khi CVE lớn xuất hiện.

10. Bài lab cuối bài

Thực hành trong một VM hoặc máy lab:

Chọn một project Node.js/Python/Java có lockfile.
Dùng Syft tạo SBOM CycloneDX cho source directory.
Dùng Grype quét SBOM và xuất report table/json.
Build container image, tạo SBOM cho image và so sánh với source SBOM.
Thêm một dependency cũ có CVE trong branch lab, quan sát pipeline fail.
Upgrade dependency, scan lại và lưu report sạch.
Viết policy ngắn: critical fail build, high cần ticket trong 7 ngày, medium theo sprint.

Kết luận

SBOM và SCA không phải phong trào compliance cho đẹp báo cáo. Đây là cách doanh nghiệp nhìn rõ phần mềm mình đang vận hành, phản ứng nhanh hơn trước CVE và giảm rủi ro dependency ngay trong pipeline. Bắt đầu nhỏ với một vài service quan trọng, tạo SBOM chuẩn, scan tự động, lưu bằng chứng và áp policy tăng dần. Khi quy trình đã ổn, SBOM/SCA sẽ trở thành một phần tự nhiên của DevSecOps thay vì một bước kiểm tra gây phiền ở cuối dự án.