軟體物料清單與政策即程式碼整合應用

軟體供應鏈安全日益受到重視，軟體物料清單（SBOM）的應用也越來越廣泛。本文將探討如何結合政策即程式碼（PaC）技術，強化 SBOM 的應用，提升軟體供應鏈的整體安全性。透過 OPA Rego 政策，可以有效地檢查 SBOM 中的加密元件，並識別潛在的安全風險。此外，利用 Grype 工具產生的漏洞資訊，結合 PaC 策略，可以快速識別 SBOM 中存在的已知漏洞，並根據漏洞嚴重程度進行分類別和排序，以便進行優先修復。文章也介紹了 SLSA 框架和 in-toto 證明機制，說明如何透過簽章驗證和流程稽核，確保 SBOM 的真實性與完整性，進一步提升軟體供應鏈的可信度。

軟體物料清單（SBOM）與政策即程式碼（PaC）的整合應用

軟體物料清單（SBOM）已成為軟體供應鏈（SSC）安全的重要組成部分。透過將 SBOM 與政策即程式碼（PaC）結合，可以進一步增強 SSC 的安全態勢。本文將探討如何使用 PaC 評估 SBOM，以偵測其中的加密元件和已知漏洞。

使用 PaC 偵測 SBOM 中的加密元件

在 SSC 安全領域，瞭解軟體元件的組成至關重要。某些元件可能包含加密函式庫，這些函式庫可能受到特殊的安全要求和法規約束。以下是一個使用 OPA Rego 政策來偵測 SBOM 中包含加密字串的元件範例：

package main

import rego.v1

warn_crypto contains component if {
    some component in input.components
    contains(component["bom-ref"], "crypto")
}

default count_warn_crypto := 0
count_warn_crypto := count(warn_crypto)

compliant if {
    count_warn_crypto == 0
}

內容解密：

此 Rego 政策檢查 SBOM 中的每個元件是否包含「crypto」字串。如果發現任何包含「crypto」的元件，政策將標記這些元件。contains(component["bom-ref"], "crypto") 這行程式碼檢查元件的 bom-ref 欄位是否包含「crypto」。由於 bom-ref 欄位名稱包含連字號，因此需要使用方括號表示法。

執行此政策後，可以使用 Conftest 工具對 SBOM 檔案進行評估：

$ conftest test -p sbom-crypto.rego syft-sbom.json -o stdout

輸出結果將顯示任何包含「crypto」的元件，並給出警告。

使用 PaC 偵測 SBOM 中的已知漏洞

除了偵測特定元件外，還可以使用 PaC 評估 SBOM 中的已知漏洞。以下是一個使用 Grype 工具產生包含漏洞資訊的 SBOM 範例：

$ grype --by-cve -o cyclonedx-json --quiet 24b080de498b > grype-sbom.json

產生的 SBOM 將包含漏洞資訊，如下所示：

{
    "vulnerabilities": [
        {
            "bom-ref": "urn:uuid:23ea130c-4ff1-4c94-b632-0a3793121766",
            "id": "ALAS-2023-2203",
            "source": {
                "name": "amazon-distro-amazonlinux-2",
                "url": "https://alas.aws.amazon.com/AL2/ALAS-2023-2203.html"
            },
            "ratings": [
                {
                    "severity": "high"
                }
            ],
            "description": "...",
            "affects": [
                {
                    "ref": "pkg:rpm/amzn/ca-certificates@2021.2.50-72.amzn2.0.4?arch=noarch&upstream=ca-certificates-2021.2.50-72.amzn2.0.4.src.rpm&distro=amzn-2&package-id=c25306c78c469d90"
                }
            ]
        }
    ]
}

圖表翻譯：

此 JSON 範例顯示了一個包含漏洞資訊的 SBOM 結構。vulnerabilities 陣列包含了多個漏洞物件，每個物件描述了一個特定的漏洞，包括其嚴重性、描述和受影響的元件。

可以使用以下 OPA Rego 政策來評估此 SBOM，找出具有高或嚴重嚴重性的漏洞：

package main

import rego.v1

bad_severities := {"high", "critical"}

default compliant := false

compliant if {
    count(violation_high_critical) == 0
}

violation_high_critical contains info if {
    some vulnerability in input.vulnerabilities
    some rating in vulnerability.ratings
    some affect in vulnerability.affects
    rating.severity in bad_severities
    ref := affect.ref
    id := vulnerability.id
    url := vulnerability.source.url
    info := sprintf("id: %s, ref: %s, url: %s", [id, ref, url])
}

內容解密：

此政策檢查 SBOM 中的每個漏洞，如果其嚴重性為「high」或「critical」，則將其標記為違規。violation_high_critical 規則遍歷所有漏洞及其評級和受影響的元件，以收集違規資訊。

執行此政策後，可以使用 Conftest 工具對 SBOM 檔案進行評估：

$ conftest test -p sbom.rego sbom.json -o stdout

輸出結果將顯示任何具有高或嚴重嚴重性的漏洞，並給出失敗訊息。

軟體物料清單的承諾

在 SSC 安全的背景下，SBOM 可以改善整體安全態勢。透過定期產生 SBOM，可以使用它們進行漂移偵測。此外，將 SBOM 與 PaC 結合使用，可以偵測元件並瞭解可疑套件的可能暴露範圍。

在減少 CVE 的過程中，瞭解哪些 CVE 是最高優先順序至關重要。可以依靠通用漏洞評分系統（CVSS）分數和嚴重性，或尋找其他來源的分數。

軟體物料清單（SBOM）與軟體供應鏈（SSC）安全

在現代軟體開發中，軟體物料清單（Software Bill of Materials, SBOM）扮演著至關重要的角色。SBOM是一種詳細記錄軟體中所使用的所有元件、函式庫及其版本的清單，類別似於產品的原料清單。它對於管理和降低軟體供應鏈（Software Supply Chain, SSC）的風險至關重要。

SBOM 的重要性

SBOM 的價值在於它能夠提供對軟體元件的全面可視性，這對於以下方面尤為重要：

1. 漏洞管理：透過 SBOM，開發者和安全團隊可以快速識別軟體中使用的元件是否存在已知漏洞（如 CVE），並進行及時的修補或升級。
2. 授權合規：SBOM 有助於確保軟體中使用的開源元件符合相關的授權要求，避免因授權問題導致的法律風險。
3. 供應鏈風險管理：SBOM 提供了一種方法來評估和管理供應鏈中的風險，確保所使用的元件是安全可信的。

提升 SBOM 的價值

為了充分發揮 SBOM 的價值，需要進一步豐富其內容和提高其可信度。除了基本的元件清單外，還應包括以下資訊：

CVE 相關資訊的深入分析

1. 可修補性（Patchability）：瞭解特定 CVE 在受影響的程式碼函式庫中是否能夠被修補，以及修補的難易程度。
2. 可利用性（Exploitability）：參考 Vulnerability Exploitability eXchange (VEX) 資訊和 Known Exploited Vulnerabilities (KEV) 目錄，評估 CVE 被實際利用的可能性。
3. 可達性（Reachability）：利用 Endor Labs 等工具進行可達性分析，透過呼叫圖譜（call graphs）展示軟體函式之間的關係，判斷 CVE 所涉及的函式或方法在程式碼函式庫中是否可達。

這些額外的資訊對於管理多個 CVE、最佳化修復優先順序以及提高風險管理能力至關重要。

SBOM 的真實性和完整性

SBOM 的價值直接取決於其可信度。為確保 SBOM 的真實性和完整性，需要採取以下措施：

1. 密碼學簽名和驗證：使用 Public Key Infrastructure (PKI) 對 SBOM 進行簽名和驗證，以確保其未被篡改。
2. 證明（Attestations）：使用 in-toto 等框架生成可驗證的宣告（statements），描述軟體的生產過程和相關的安全屬性。

SLSA 框架

Supply-chain Levels for Software Artifacts (SLSA) 是一個安全框架，旨在防止軟體供應鏈中的篡改、提高完整性並保護軟體包和基礎設施。SLSA 定義了多個級別的安全控制措施，其中：

• Level 1：存在出處（provenance），但容易被繞過或偽造。
• Level 2：在 Level 1 的基礎上，透過密碼學簽名和驗證提高真實性和完整性，但仍可能透過供應鏈攻擊被破壞。
• Level 3：在 Level 2 的基礎上，透過嚴格控制密碼學材料的存取，防止篡改，提供更高的安全性。

達到 SLSA Level 3 需要結合多種技術和工具，如 in-toto attestation framework、sigstore/cosign 和 Policy-as-Code (PaC) 工具（如 OPA 或 CUE）。這些工具共同作用，提供不可變的、抗篡改的記錄，並確保軟體供應鏈的安全性和可觀察性。

實施範例

Liatrio 公司透過一系列最佳實踐和開源工具（如 GitHub Trusted Build Repositories 和 sigstore/cosign），展示瞭如何達到 SLSA Level 3。例如，使用 in-toto attestation framework 生成符合 SLSA 要求的證明，並結合 PaC 工具對證明進行驗證。

程式碼範例：in-toto 證明片段

{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "eyJfdHlwZSI6I...J9fX0=",
  "signatures": [
    {
      "keyid": "",
      "sig": "MEUCI...pSx2o="
    }
  ]
}

#### 內容解密：

此 JSON 物件代表一個 in-toto 證明，包含以下關鍵元素：

1. payloadType：指定了 payload 的型別，在此為 application/vnd.in-toto+json，表示這是一個符合 in-toto 規範的 JSON 物件。
2. payload：Base64 編碼的 in-toto payload，包含了證明的詳細資訊，如構建過程、材料和產品等。
3. signatures：包含一個或多個簽名，用於驗證 payload 的真實性和完整性。每個簽名物件包含 keyid 和 sig 欄位，分別表示簽名所用的金鑰 ID 和 Base64 編碼的簽名值。

透過解碼 payload，可以獲得更多的資訊，如：

{
  "predicateType": "https://slsa.dev/verification_summary/v0.2",
  "policy": {
    "uri": "https://github.com/liatrio/gh-trusted-builds-policy/.../releases/download/v1.1.1/bundle.tar.gz"
  },
  "policy_level": "SLSA_LEVEL_3",
  "resource_uri": "ghcr.io/liatrio/gh-trusted-builds-app"
}

#### 內容解密：

此解碼後的 payload 片段展示了與 SLSA 相關的驗證資訊：

1. predicateType：指定了證明的型別，這裡參照了 SLSA 的驗證摘要規範。
2. policy.uri：指向一個特定的策略包，用於定義達到 SLSA Level 3 所需的安全控制措施。
3. policy_level：明確指出該證明符合 SLSA Level 3，代表最高階別的安全認證。
4. resource_uri：指定了與該證明相關聯的資源 URI，如容器映像的儲存位置。

這些資訊共同確保了軟體供應鏈的安全性和透明度，為達成 SLSA Level 3 提供了堅實的基礎。

圖表說明

  graph LR
    A[開始] --> B{檢查 SBOM}
    B -->|完整|> C[驗證真實性]
    B -->|不完整|> D[傳回錯誤]
    C --> E[驗證簽名]
    E -->|有效|> F[檢查 SLSA 等級]
    E -->|無效|> G[傳回錯誤]
    F -->|Level 3|> H[完成]
    F -->|非 Level 3|> I[傳回錯誤]

圖表翻譯：

此流程圖展示了驗證 SBOM 真實性和檢查 SLSA 等級的步驟：

1. 開始：流程起始點。
2. 檢查 SBOM：首先檢查 SBOM 是否完整。如果完整，進入真實性驗證；否則傳回錯誤。
3. 驗證真實性：檢查 SBOM 的數字簽名是否有效。如果有效，進入 SLSA 等級檢查；否則傳回錯誤。
4. 檢查 SLSA 等級：確認 SBOM 是否達到 SLSA Level 3。如果是，完成驗證；否則傳回錯誤。

此圖清晰地展示了確保 SBOM 安全性和符合 SLSA 要求的關鍵步驟。

軟體供應鏈安全中的策略即程式碼（Policy as Code）實踐

摘要

本章節探討了策略即程式碼（PaC）在軟體供應鏈（SSC）安全中的應用。隨著軟體行業對SSC安全的關注度不斷提升，PaC作為一種提升安全性的關鍵技術，得到了廣泛的應用與發展。本章節透過具體的案例與技術分析，闡述了PaC如何與不同的工具整合，以解決多個策略執行點（PEP）的安全問題。

PaC在軟體供應鏈中的角色

軟體供應鏈的安全性對於確保軟體產品的完整性與可靠性至關重要。隨著SLSA（Supply Chain Levels for Software Artifacts）級別的不斷提升，對SSC的安全要求也日益嚴格。PaC透過在開發、構建與佈署等不同階段實施策略驗證，確保了SSC的安全性。

PaC的關鍵應用場景

1. 開發者桌面：在開發者本地環境中應用PaC，提供即時反饋，幫助開發者更早地修復問題。
2. 程式碼函式庫：在程式碼函式庫中實施PaC，透過持續整合（CI）活動觸發早期問題檢測。
3. Pipeline：在Pipeline中採用PaC，允許執行步驟並驗證Pipeline輸出。

技術實踐與工具整合

本章節透過一個具體的Liatrio演示案例，展示瞭如何構建SLSA級別3的SSC，並使用PaC進行評估。該案例涉及多個開源元件和工具，包括：

• in-toto：用於驗證軟體供應鏈中的構建和佈署步驟。
• OPA（Open Policy Agent）：用於定義和執行策略。
• sigstore/cosign, sigstore/rekor, sigstore/fulcio：用於簽署和驗證軟體產物。
• GitHub可重用工作流程和OIDC整合：用於分離工作流程執行並防止對敏感產物的未授權存取。

程式碼範例：建立驗證摘要證明（VSA）

# GitHub工作流程命令建立VSA
- name: Create Verification Summary Attestation
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    attestation vsa \
      --artifact-uri ghcr.io/${{ github.repository }} \
      --artifact-digest ${{ inputs.digest }} \
      --policy-url \
      "https://github.com/liatrio/gh-trusted-builds-policy/releases/download/v1.4.0/bundle.tar.gz" \
      --verifier-id \
      ${{ github.server_url }}/${{ needs.detect-workflow.outputs.repository }}/${{ needs.detect-workflow.outputs.workflow }}@${{ needs.detect-workflow.outputs.ref }} \
      --fulcio-url ${{ steps.config.outputs.fulcioUrl }} \
      --rekor-url ${{ steps.config.outputs.rekorUrl }}

內容解密：

此段程式碼展示瞭如何在GitHub工作流程中建立驗證摘要證明（VSA）。首先，設定了GITHUB_TOKEN環境變數以取得必要的授權。接著，執行attestation vsa命令，該命令需要多個引數：

• --artifact-uri：指定產物的URI。
• --artifact-digest：指定產物的摘要，用於驗證產物的完整性。
• --policy-url：指定包含OPA策略的包的URL。
• --verifier-id：指定驗證者的ID，通常包含GitHub伺服器URL、倉函式庫名稱、工作流程名稱和參考參照。
• --fulcio-url和--rekor-url：分別指定Fulcio和Rekor服務的URL，用於簽署和記錄產物。

透過這些引數，attestation vsa命令能夠生成一個VSA，用於證明指定的產物已經透過了特定SLSA級別的驗證。

軟體物料清單（SBOM）的重要性

SBOM提供了一份軟體產物中所包含的元件清單，以及這些元件的來源資訊和漏洞情報。結合Syft、Grype、Trivy等工具，可以建立和評估SBOM，從而更好地管理軟體供應鏈中的安全風險。

SBOM的價值

1. 元件清單：列出軟體產物中的所有元件及其來源。
2. 漏洞情報：提供有關已知漏洞的資訊，如可達性和可利用性。
3. 風險管理：幫助優先處理修復工作，特別是在不同來源提供不同的CVSS評分時。

達到SLSA級別3的要求

要達到SLSA級別3，需要實作以下幾點：

1. 密碼學簽名和驗證：對軟體產物進行簽名和驗證，以證明其來源和完整性。
2. 防篡改和防偽造：確保用於生成、簽名和驗證的步驟不被篡改或偽造。
3. 嚴格的工作流程控制：使用GitHub可重用工作流程和OIDC整合，防止未授權存取敏感產物。

隨著SSC安全性的不斷提升，PaC將發揮越來越重要的作用。未來，我們需要進一步探索如何更好地整合PaC和其他安全技術，以實作更高的安全性和可靠性。同時，也需要關注新興技術和工具的發展，以應對不斷變化的安全威脅。

總之，PaC是提升SSC安全性的關鍵技術之一。透過在不同階段實施PaC，並結合SBOM和其他安全技術，可以有效地提高軟體供應鏈的安全性和可靠性。未來，我們需要繼續深入研究和實踐，以實作更高的安全標準。