軟體供應鏈安全

軟體供應鏈安全簡介

對於 Professional Cloud Architect 而言，安全性不應止步於防火牆。在現代雲端原生環境中，程式碼本身以及用於構建和部署程式碼的工具，都是攻擊者的主要目標。軟體供應鏈安全 (Software Supply Chain Security) 是一種確保只有經過信任、驗證的程式碼才能進入生產環境的實務。

Google Cloud 使用「左移 (Shift Left)」方法來實現這一點，將安全性整合到開發生命週期的最初階段。

白話文解釋 Software Supply Chain Security

供應鏈安全就像是高階食品加工廠中嚴格的安全檢查。

類比 1 — 有機認證標章 (Attestations)

想像您正在買有機牛奶。您如何知道它真的是有機的？您會尋找認證標章 (Certified Seal)。在 GCP 中，認證 (Attestation) 就是那個數位標章。當構建系統 (Cloud Build) 成功測試並掃描一個容器時，它會為該容器簽署一個數位標章，表示：「此容器已通過安全測試」。

類比 2 — 裝卸貨平台的保安 (Binary Authorization)

Binary Authorization 就像是超級市場（生產環境）裝卸貨平台的保安人員。當卡車（容器）到達時，保安不只是看司機是誰，還會檢查是否有認證標章的證明文件。如果標章缺失或偽造，卡車就會被禁止卸貨。無論這批貨有多重要，沒有標章就不能進入。

類比 3 — 成分清單 (SBOM)

SBOM (軟體物料清單) 就像是穀片盒上的成分清單。它確切地告訴您裡面有什麼——每個函式庫、每個套件和每個依賴項。如果衛生稽查員（安全掃描器）發現某個特定成分（例如 Log4j 函式庫）有毒（有漏洞），您可以立即檢查成分清單，看看哪些產品需要回收。

SLSA 框架 — Level 1 至 Level 4 詳解

SLSA (Supply-chain Levels for Software Artifacts)，讀音為「salsa」，是 Google 開源並捐贈給 OpenSSF 的供應鏈安全框架。它定義了四個層級，每一級都在前一級的基礎上增加新的防篡改保證。

Level 1 — 紀錄構建流程

建置必須完全腳本化、自動化，並產生 provenance（建置溯源資料） ——一份描述產物如何被建置的元數據（來源、建置步驟、依賴項）。Cloud Build 透過產生包含 steps、images、logsBucket 的 Build 資源來滿足這項要求。光是 Level 1 並無法防止篡改，僅讓流程可稽核。

Level 2 — 防篡改建置服務 + 簽署 provenance

建置必須在託管服務上執行（不可在開發者筆電上），且 provenance 必須由建置服務 簽署。Cloud Build 搭配 Artifact Analysis，會自動為儲存在 Artifact Registry 的容器映像產生 SLSA Level 2 provenance。簽章可透過公開金鑰端點 https://cloudbuild.googleapis.com/.well-known/jwks.json 驗證。

Level 3 — 加固建置 + 不可偽造的 provenance

建置平台執行於 短暫、隔離 的環境。每次建置都使用全新 VM，不留持久狀態，且建置服務阻止使用者注入自製的 provenance。Cloud Build private pools 搭配 --peered-network 並關閉 SSH 即可達到此標準。Provenance 在可信的建置平台內部簽署——建置使用者無法偽造。

Level 4 — 雙人審核 + 密封式建置

最高層級加上 雙人審核 所有原始碼變更，以及 hermetic（密封）、可重現 的建置（建置期間無網路存取；相同輸入永遠產生 bit-for-bit 相同的輸出）。在 GCP 上達成 Level 4 需要大量投入——通常使用 Bazel --config=remote 搭配強制執行需兩位審核者的分支保護。

關鍵 GCP 安全服務

1. Artifact Registry

儲存容器映像檔和語言套件 (Maven, npm, Python) 的安全集中位置。它直接與安全掃描整合。

2. Artifact Analysis

自動掃描 Artifact Registry 中的映像檔以尋找漏洞 (CVE)。

• 上傳時掃描 (On-push Scanning)： 每當上傳新映像檔時進行掃描。
• 持續分析 (Continuous Analysis)： 當全球 CVE 資料庫發現新漏洞時，自動重新掃描映像檔。

3. Binary Authorization

針對 GKE 和 Cloud Run 的部署時安全性控制。

• 政策強制執行 (Policy Enforcement)： 您可以定義一項政策，例如：「僅允許由 QA 團隊簽署的映像檔進行部署」。
• 認證者 (Attestors)： 提供數位簽章的實體（例如 Cloud Build、安全工具或人工管理者）。

構建安全流水線

專業架構師會設計一個「鎖定」的流水線：

1. 來源 (Source)： 程式碼儲存在具有受保護分支的安全存儲庫中。
2. 構建 (Cloud Build)： 構建在隔離環境中運行。Artifact Analysis 掃描漏洞。
3. 認證 (Attest)： 如果掃描結果乾淨且測試通過，則建立數位簽章 (Attestation)。
4. 部署 (GKE/Cloud Run)： Binary Authorization 檢查簽章。如果有效，則進行部署；否則，將其攔截並發送警報。

漏洞管理策略

• 優先級排序： 專注於具有已知「可用修復 (Fix available)」的「關鍵 (Critical)」和「高 (High)」漏洞。
• 自動修補： 使用工具在依賴項需要更新時自動建立 Pull Request。
• 漏洞例外處理： 有時會發現不適用於您特定案例的漏洞。Artifact Analysis 允許您記錄並「認可 (acknowledge)」這些例外情況。

Artifact Registry 容器掃描深度解析

Artifact Registry 是 GCP 統一的套件儲存庫，取代舊版的 Container Registry (gcr.io)。在供應鏈安全層面，最重要的是兩種掃描行為。

上傳時掃描 (On-push Scanning)

每當映像透過 docker push <region>-docker.pkg.dev/<project>/<repo>/<image>:<tag> 或 gcloud artifacts docker images upload 推送時，Artifact Analysis 會自動取出映像 manifest，辨識作業系統套件（Debian、Ubuntu、RHEL、Alpine 等）與語言套件（Maven、Go、npm、Python、Nuget），然後比對 NVD / OSV / 廠商安全公告。小型映像通常 60 秒內回報結果，大型映像可能需要數分鐘。

持續分析 (Continuous Analysis)

映像被掃描過一次後就會進入監控清單。當有 新 CVE 揭露、且符合映像中既有套件版本時，Occurrence 會自動更新——你無須重新推送映像。這是偵測像 Log4Shell 這類零日漏洞、找出已部署映像受影響範圍的唯一務實做法。

啟用與查詢

# 在專案層級啟用掃描
gcloud services enable containerscanning.googleapis.com

# 查詢特定映像的 CVE
gcloud artifacts docker images list-vulnerabilities \
  us-central1-docker.pkg.dev/my-proj/repo/myapp:v1 \
  --format="table(vulnerability.effectiveSeverity,vulnerability.shortDescription)"

掃描覆蓋層級

• 標準層（每月 N 次內免費）： 僅作業系統套件——Debian、Ubuntu、Alpine、RHEL、CentOS。
• 進階層（Security Command Center Premium）： OS + 語言套件（Go、Java、JavaScript、Python、.NET）+ 持續分析。

限制與陷阱

• 掃描支援 Docker v2 與 OCI manifest——distroless 與 FROM scratch 映像因套件元資料有限，掃描結果可能不完整。
• 多架構 manifest list 會逐架構掃描；結果會彙整，但你必須逐個 digest 查詢。
• 映像刪除後就無法再追溯漏洞——重要的生產 tag 請透過 Artifact Registry 的 cleanup policies 設 KEEP 規則保留。

Artifact Analysis API — 漏洞與 provenance Occurrences

Artifact Analysis API (containeranalysis.googleapis.com) 是元資料層，把掃描結果、attestations、SBOM、build provenance 全部儲存成 Notes 與 Occurrences 的圖結構。

Notes 與 Occurrences 的差異

• Note 是某類發現——例如「CVE-2021-44228 存在於 log4j-core 2.14.1」。
• Occurrence 是該 Note 套用到特定資源的實例——例如「CVE-2021-44228 出現在映像 sha256:abc123 的第 4 層」。

這種分離設計讓單一 CVE Note 能關聯到數千個受影響映像 Occurrence，而不會重複儲存。

Provenance Occurrences

當 Cloud Build 產生具備 SLSA Level 2+ provenance 的映像時，Artifact Analysis 會儲存一筆 BUILD 類別的 Occurrence，內容包括：

• 原始碼的 git commit SHA。
• 建置步驟、所用的容器映像、參數。
• 建置者身分（Cloud Build 服務帳號電子郵件）。
• 一個簽署過的 JWT payload，任何人都可用 Google 的公開金鑰驗證。

用 gcloud 查詢 Provenance

gcloud artifacts docker images describe \
  us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123 \
  --show-provenance

用 Resource Manager 過濾

你可以列出整個組織內所有 Critical 等級的 CVE Occurrence：

gcloud container analysis occurrences list \
  --project=my-proj \
  --filter='kind="VULNERABILITY" AND vulnerability.severity="CRITICAL"'

Binary Authorization Attestations 與政策模式

Binary Authorization 是執行時期的把關者。它在准入時刻評估部署政策，並決定允許、攔截或僅稽核紀錄。

Attestor 的三個組成部分

一個 Attestor 由三部分組成：

1. Artifact Analysis 中的一筆 Note（標章的公開名稱）。
2. 一把用於驗證簽章的 PKIX 公開金鑰（或 KMS 託管金鑰）。
3. 控制誰可以針對該 Attestor 建立 attestation 的 IAM binding。

建立與簽署

# 建立 attestor
gcloud container binauthz attestors create prod-attestor \
  --attestation-authority-note=prod-attestor-note \
  --attestation-authority-note-project=my-proj

# 對映像簽署（通常由 Cloud Build 自動完成）
gcloud beta container binauthz attestations sign-and-create \
  --artifact-url="us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123" \
  --attestor=prod-attestor \
  --keyversion=projects/my-proj/locations/global/keyRings/binauthz/cryptoKeys/prod/cryptoKeyVersions/1

政策評估模式

• ALWAYS_ALLOW： 全部放行——用於 dev 叢集。
• ALWAYS_DENY： 全部攔截——少見，僅用於孤立叢集。
• REQUIRE_ATTESTATION： 最常見——映像必須擁有所列每個 attestor 的有效 attestation。
• ALWAYS_ALLOW 搭配 dryRunOnly: true： 稽核模式——政策違規會記到 Cloud Audit Logs，但部署仍會繼續。適合推出新政策時使用。

叢集個別規則

預設政策套用至整個叢集網路，但你可用 clusterAdmissionRules 逐叢集覆寫。典型設定：

• projects/my-proj/zones/us-central1-a/clusters/dev → ALWAYS_ALLOW
• projects/my-proj/zones/us-central1-a/clusters/prod → REQUIRE_ATTESTATION 搭配 prod-attestor

持續驗證 (Continuous Validation, CV)

即使准入成功，Continuous Validation 仍會每 24 小時重新檢查運行中的 Pod，若 Pod 不再符合（例如 attestation 已撤銷），會發出 Cloud Logging 紀錄。這捕捉了「政策在部署後變嚴」的情境。

SBOM 產生 — GCP 上的 SPDX 與 CycloneDX

Software Bill of Materials（軟體物料清單） 已不再是選項——美國 Executive Order 14028 要求販售給聯邦機構的軟體必須附 SBOM，歐盟 Cyber Resilience Act 也預期類似揭露。

兩大業界標準

• SPDX (Software Package Data Exchange)： Linux Foundation 標準，ISO/IEC 5962:2021。支援 tag-value、JSON、YAML、RDF 格式。授權元資料表達能力強。
• CycloneDX： OWASP 維護，JSON/XML，針對安全用途最佳化。包含 VEX (Vulnerability Exploitability eXchange) 與依賴關係圖。

GCP Artifact Analysis 可從任何掃描過的映像匯出 兩種 格式：

# 匯出 SPDX
gcloud artifacts sbom export \
  --uri=us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123 \
  --format=SPDX

# 匯出 CycloneDX
gcloud artifacts sbom export \
  --uri=us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123 \
  --format=CYCLONEDX

SBOM 儲存模式

最佳實務是把 SBOM 存到 專屬的 Cloud Storage 值區，開啟物件版本控制並設定 Bucket Lock 保留政策（例如 7 年），讓 SBOM 在合規稽核時防篡改。

整合的開源 SBOM 工具

• Syft (Anchore)——從檔案系統、容器映像或 registry 產生 SBOM。
• Trivy (Aqua)——SBOM + 漏洞掃描器。
• Tern——專為容器映像設計。

由 SBOM 驅動的漏洞回應

當 CVE-2024-XXXX 發布時，你不需要重新掃描所有映像。可對 SBOM 語料用 jq 查詢，或載入 BigQuery 執行：

SELECT image_uri FROM `proj.security.sboms`
WHERE 'pkg:maven/org.apache.logging.log4j/[email protected]' IN UNNEST(components);

這把原本需要好幾天的救火工作壓縮成一分鐘的查詢。

Assured Open Source Software (Assured OSS)

Assured OSS 是 Google 精選的開源套件儲存庫，這些套件正是 Google 自己內部使用、建置並做過安全測試的版本。

你會得到什麼

• 套件由 Cloud Build 在 SLSA Level 3 基礎設施上建置。
• 每個產物都有 簽署過的 provenance。
• Google 安全團隊執行 持續漏洞掃描。
• VEX 聲明 標示哪些 CVE 實際上可被利用。
• 修補更快——Google 通常在上游發布前就已修補。

支援的生態系（持續擴充）

• Java (Maven)——超過 1,000 個套件，包含 Guava、Apache Commons、Jackson、Log4j。
• Python (pip)——Django、Flask、requests、NumPy 等。

如何使用

把 pom.xml 或 requirements.txt 指向 Assured OSS 的 Artifact Registry remote repository：

<repository>
  <id>assured-oss</id>
  <url>https://us-maven.pkg.dev/cloud-aoss/maven</url>
</repository>

Python：

pip install --index-url https://us-python.pkg.dev/cloud-aoss/python/simple/ django

何時用 Assured OSS、何時用公開鏡像

• 高合規需求（FedRAMP、HIPAA、FSI）→ Assured OSS。
• 一般開發 → 用 Artifact Registry remote caching 對接公開鏡像通常已足夠。
• 混合做法 → 把關鍵函式庫（crypto、auth、logging frameworks）釘到 Assured OSS；其餘走 Maven Central 經 remote repo。

依賴審查與 Cosign 容器簽署

依賴審查（原始碼端）

程式碼進到 Cloud Build 之前，就該先掃 PR 中的依賴變更。選項：

• GitHub Dependency Review Action——若新依賴存在已知 CVE 就讓 PR 失敗。
• OSV-Scanner（Google 開源）——針對 go.sum、package-lock.json、Pipfile.lock 等執行。可透過自訂步驟整合進 Cloud Build。
• Renovate / Dependabot——CVE 揭露時自動產生升版 PR。

Cosign 容器簽署

cosign（Sigstore 專案）是 OCI 產物簽署的事實開源標準。它與 Binary Authorization 互補——你可以把 cosign 簽章 當作輸入 來建立 Binary Authorization attestation。

# 用 KMS 託管金鑰簽署（生產建議做法）
cosign sign --key gcpkms://projects/my-proj/locations/global/keyRings/cosign/cryptoKeys/prod \
  us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123

# 驗證
cosign verify --key gcpkms://projects/my-proj/locations/global/keyRings/cosign/cryptoKeys/prod \
  us-central1-docker.pkg.dev/my-proj/repo/myapp@sha256:abc123

Sigstore 的 Keyless 簽署

cosign 也支援用 OIDC 身分做 keyless 簽署——簽章綁定到工作負載身分（GitHub Actions、Cloud Build SA），公鑰會記到 Rekor（透明度日誌）。這消除了長期簽署金鑰的管理，但需信任 Sigstore 的 Fulcio CA。

GitHub Actions OIDC 與 Build Provenance 驗證

許多團隊在 GitHub Actions 建置、部署到 GCP。安全模式是用 Workload Identity Federation 讓 GitHub 不靠服務帳號金鑰就能向 GCP 進行身分驗證。

OIDC 信任設定

gcloud iam workload-identity-pools create github-pool --location=global

gcloud iam workload-identity-pools providers create-oidc github-provider \
  --workload-identity-pool=github-pool --location=global \
  --issuer-uri=https://token.actions.githubusercontent.com \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"

然後將服務帳號綁定到特定 repo 與分支：

gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/github-pool/attribute.repository/myorg/myrepo"

GitHub Build Attestations

自 2024 年起，GitHub 對任何 Actions 建置產物原生產生 SLSA v1.0 provenance。actions/attest-build-provenance action 會用一張綁定該 workflow OIDC token 的 Sigstore 短期憑證來簽署 attestation。

- uses: actions/attest-build-provenance@v1
  with:
    subject-name: us-central1-docker.pkg.dev/my-proj/repo/myapp
    subject-digest: sha256:abc123
    push-to-registry: true

在 GKE 上驗證 GitHub 建置的映像

部署端的 Binary Authorization 政策可要求 attestation 必須由 GitHub Sigstore 身分簽署。或者在 Cloud Build 的部署前步驟用 gh attestation verify。

陷阱

• pull_request workflow 跑在唯讀 token 下，無法產生可信的 attestation。只在 push 到受保護分支或 release 事件中簽署。
• 可重用 workflow 必須用 SHA 而非 tag 來引用——tag 可變動、可被劫持。
• GITHUB_TOKEN 外洩——切勿 echo 出來；當作有寫入權限的憑證對待。

常見問題 — 軟體供應鏈安全

Q1. 什麼是 SBOM？

軟體物料清單 (Software Bill of Materials) 是軟體中使用的所有組件、函式庫和依賴項的完整清單。這對於追蹤組織中哪些地方使用了受漏洞影響的函式庫至關重要。

Q2. Binary Authorization 是否適用於非 Google 的容器？

是的。只要容器儲存在 Artifact Registry 中，並且您有一套簽署流程，Binary Authorization 就可以對任何映像檔執行政策。

Q3. 如果 Binary Authorization 攔截了關鍵的生產修復程式該怎麼辦？

Binary Authorization 具備**「緊急處置 (Break-glass)」**模式。這允許緊急部署繞過政策。但是，每次「緊急處置」事件都會被記錄，並應立即進行稽核。

Q4. Artifact Analysis 是免費的嗎？

基礎漏洞掃描會根據掃描的映像檔數量收費。持續分析每個月也會根據每個映像檔收取少許費用。

Q5. 為什麼「左移 (Shift Left)」很重要？

左移意味著將安全檢查移至開發過程的早期。在構建階段修復漏洞，比在生產環境中應對安全漏洞要便宜且快速得多。

架構師最終提示

在 PCA 考試中，請專注於 Artifact Analysis + Binary Authorization 的組合。這是供應鏈安全的主要架構模式。如果場景提到「確保僅部署經過核准的映像檔」，答案就是 Binary Authorization。如果提到「追蹤容器映像檔中的漏洞」，答案則是 Artifact Analysis。此外，請熟悉 SLSA 框架，它是構建完整性的業界標準。