當前最棘手的稽核問題不再是「程式碼有沒有 CVE?」,而是「如何證明 production 上正在跑的 artifact,確實是由這份原始碼建置而來、沒有被 inject?」
三種常見的供應鏈攻擊
- Dependency confusion / typosquat (npm、pypi、RubyGems):發布名稱與內部套件相近的惡意套件。
- Source compromise (xz utils、Codecov bash uploader):把惡意程式碼注入上游專案。
- Build poisoning (SolarWinds):攻陷 build server,在 artifact 中注入,而原始碼仍是乾淨的。
對應的標準框架是由 OpenSSF 維護的 SLSA (Supply-chain Levels for Software Artifacts)。
SLSA——build integrity 的四個等級
| Level | 主要要求 |
|---|---|
| L1 | Build 過程有文件,產生基本 provenance。 |
| L2 | Build 在 hosted CI 上執行,provenance 被簽署,原始碼納入版本控制。 |
| L3 | Build 在隔離/hardened 環境中執行,provenance 無法被使用者偽造。 |
| L4 | Hermetic、可重現 (reproducible) 的 build,需雙人審查。 |
多數組織的實際目標:SLSA Build L2-L3。L4 仍很罕見且成本高昂。
SBOM:CycloneDX 還是 SPDX?
兩個標準格式:
- CycloneDX (OWASP):聚焦資安使用情境,支援漏洞、services、ML model。工具生態豐富 (Trivy、Syft、Dependency-Track)。
- SPDX (Linux Foundation):聚焦 license 合規,獲得多國主管機關認可 (例如 US EO 14028)。
選 1 個為主,需要時可以匯出成另一格式。每個 production artifact 都應在 CI 中自動產生 SBOM,並與 artifact 一同保存。
Sigstore:對任何 artifact 的 keyless 簽署
Sigstore 由三個元件組成:
- Cosign:簽署/驗證映像檔、blob、attestation 的 CLI。
- Fulcio:依 OIDC identity 簽發 short-lived 憑證的 CA (TTL 5 分鐘)。
- Rekor:不可變的 transparency log,記錄所有簽署——可檢查是否有人用你的 identity 產生了異常簽署。
最大優勢:沒有需要保管、輪換或備份的私鑰。
Provenance 與 in-toto attestation
Provenance 是描述誰建置、從哪份原始碼、用什麼工具、何時建置的 metadata。標準格式是 in-toto attestation,搭配 predicate type https://slsa.dev/provenance/v1。
GitHub Actions 有官方 generator workflow:
jobs: build: outputs: digest: ${{ steps.push.outputs.digest }} # ... build & push image
provenance: needs: [build] permissions: id-token: write packages: write contents: read uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected] with: image: ghcr.io/org/app digest: ${{ needs.build.outputs.digest }} registry-username: ${{ github.actor }}
這個 workflow 在隔離的 reusable workflow 中建置,產生 provenance 並用 Cosign keyless 簽署——不必額外寫程式碼即可達到 SLSA L3。
部署前驗證 provenance
使用 cosign verify-attestation:
cosign verify-attestation --type slsaprovenance \
--certificate-identity-regexp "https://github.com/org/.+/.github/workflows/build.yml@.+" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
ghcr.io/org/app@sha256:...
或在叢集中透過 Kyverno verifyImages 強制執行,以 OIDC subject 作為 attestor。沒有正確 provenance 的映像檔會被 admission 拒絕。
聰明地管理相依套件
- 以 digest/lockfile 釘住版本:
package-lock.json、poetry.lock、go.sum。永遠不用latest。 - GitHub Action 以 SHA 釘住而非 tag——tag 可能被搬動。
- 對內部套件設立內部 mirror (Artifactory、Nexus),不直接從公開 npm/pypi 拉取。
- Renovate/Dependabot 設定政策:patch 自動合併,minor/major 需人工審查,並設置 cooldown 以避免剛發布的惡意版本。
簡短的供應鏈檢查表
- 每個 production artifact 都有 CycloneDX/SPDX SBOM 並被保存。
- 映像檔以 Cosign keyless 簽署,簽名存於 Rekor。
- Build 在隔離的 reusable workflow 中執行 (達 SLSA L2-L3)。
- 叢集有 policy 在 admit pod 之前驗證簽署 + provenance。
- 相依套件以 lockfile + digest 釘住,並有內部 mirror。
- 透過 SBOM 用 Dependency-Track 追蹤 long-tail CVE。
結論
供應鏈安全已不再是選配——EU CRA、US EO 14028 與許多企業客戶都已在 RFP 中要求 SBOM 與簽署過的 artifact。好消息是:Sigstore + SLSA + CycloneDX 這套開放堆疊,憑藉 OpenSSF 的 reusable workflow,可讓達到 SLSA L3 的成本幾乎為零。請把這視為 2026 年的技術基線。