關於SBOM、BitBucket和OWASP Dependency Track

我所參與的舊與新建築博物館迫使我著手保護它們。例如，一個舊的依賴可能會變成CVE，或者一個穩固的開源項目可能會商業化。這就是軟體材料清單（SBOM）概念產生的背景，用來編目系統的許可證和依賴生態系統。這個構建工件隨後會被分析，以確定其組成元件是否：

1. 容易被利用，或
2. 在不理想的條件下獲得許可，例如過於商業化或過於掠奪性。

這篇文章將解釋如何使用：

1. BitBucket管道生成SBOM，以及
2. OWASP的依賴追蹤如何分析它。

了解您的風險

不知曉您的代碼和容器中潛藏著什麼是一種幸福，但卻是危險的。然而，將所有元件通過依賴分析器可能會產生壓倒性的反饋。最好是將依賴問題的數量在團隊文化中成為儀表板的一部分，並且始終要比昨天少。

維基百科指出：“開放全球應用安全項目（OWASP）是一個在線社群，製作在物聯網、系統軟體和網頁應用安全領域中自由可用的文章、方法論、文件、工具和技術。”因此，他們提供一個平台來追蹤和分析系統中的漏洞也就不足為奇。其最引人注目的特徵是其主儀表板：

中間最大的圖表顯示了所有被追蹤項目的漏洞數量。關於嚴重、中等和低風險的指標顯示在下面。依賴追蹤從一個或多個來源檢索已知漏洞。其中最顯著的是來自美國國家漏洞數據庫的常見漏洞與暴露(CVE)列表。每個CVE都被分配一個從未知和低到嚴重的嚴重程度。這項風險分析由依賴追蹤在幕後定期進行，使用相關的軟體物料清單(SBOM)作為輸入。

最大圖表正下方的部分詳細說明了政策違規情況，政策根據用戶認為重要的內容進行配置。用戶可以將某些依賴項註冊為不希望的，或者可以要求某些許可證或甚至一組許可證在儀表板上顯示並報告。這一反饋機制可以按政策進行配置。

上方部分則顯示了投資組合漏洞、面臨風險的項目、易受攻擊的組件以及隨時間變化的風險分數。

有更多的視圖、圖表和統計數據，例如審計進度、隨著時間推移每個項目的漏洞以及每個組件的漏洞等，但我們不妨將注意力轉向 BitBucket 如何生成並將 SBOM 發送至 Dependency Track。

BitBucket 準備 SBOM

SBOM 的準備在 BitBucket CI/CD 管道中進行，該管道在拉取請求合併到主分支後執行。這確保了儀表板始終與當前情況保持最新。

我使用了一個包裝了 syft 的 BitBucket 管道來生成 CycloneDX SBOM。用於代碼和容器調查的 syft 命令略有不同。

代碼嗅探

從項目根目錄分析代碼的 syft 命令如下：

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

此命令將 SBOM 輸出到名為 code-cdx-sbom.json 的文件中，並使用網絡從互聯網檢索許可證信息；例如，來自中央 Maven 存儲庫。

syft BitBucket 管道來自shiftleftcyber（謝謝你！）然後在 BitBucket 管道的腳本塊中配置，以包裝這個syft命令，如下所示：

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_CMD_ARGS: '. --output cyclonedx-json=code-cdx-sbom.json'

    SYFT_JAVA_USE_NETWORK: 'true'

syft 專案的自述文件列出了令人印象深刻的支持語言，但我只在Java和JavaScript上使用過，並且在待辦事項中有一個Python專案。

你的容器中潛藏著什麼？

要掃描來自你的註冊表的容器，可以在“docker login”的範疇內運行以下命令：

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

對應的 BitBucket 管道是：

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_REGISTRY_AUTH_USERNAME: sadilar

    SYFT_REGISTRY_AUTH_PASSWORD: $DOCKER_PWD

    SYFT_CMD_ARGS: 'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'

all-layers開關指示 syft 檢查容器映像的所有層，而不僅僅是最終產品。

BitBucket 作為存放媒介

剩下的就是讓 Dependency Track 來獲取 SBOM。我使用了生成 SBOM 的 BitBucket 管道的姐妹管道：

- pipe: docker://ccideas/sbom-utilities-pipe:1.5.0

  variables:

    PATH_TO_SBOM: code-cdx-sbom.json

    SEND_SBOM_TO_DTRACK: 'true'

    DTRACK_URL: https://deptrack.test.s2c.co.za

    DTRACK_PROJECT_ID: df3327b2-5439-43ab-bb33-1f24228b6074

    DTRACK_API_KEY: $DTRACK_TEST

我指定了三個輸入參數：

1. 依賴追蹤實例的 URL
2. 要加載 SBOM 的依賴追蹤專案 ID
3. 授權上傳的 API 金鑰

可以通過單擊專案視圖中的「查看詳細資訊」輕鬆找到專案 ID：

然後複製底部的物件識別碼：

在左側面板的管理菜單中，可以在自動化團隊的同名輸入欄位中找到API 金鑰：

結論

過去的事件教訓表明，利用弱點往往會導致服務中斷，並可能擴散到相鄰的系統或行業。這會造成意外的支出和不便。從中恢復將使開發者和資源偏離團隊目標。

此外，開放專案的許可證可能會轉為商業性，導致組織被追索過去的許可費。另一方面，由於掠奪性許可條件，可能會要求開放使用的關鍵 IP，以獲得競爭優勢。

因此，每位開發者都有責任實施和支持主動策略，以應對這些風險。如果您的代碼在 BitBucket 上，上述方法可以幫助您的系統符合要求。然而，依賴追蹤 API 不僅限於 BitBucket，還必須有其他 CI/CD 管道技術可以將軟體物料清單傳送到這裡。