第三方套件與AI產生的程式碼大量進入企業專案，也讓軟體供應鏈風險更難追蹤。DevSecOps平臺業者GitLab於5月26日說明GitLab 19.0的新功能，正式推出以軟體物料清單（Software Bill of Materials，SBOM）為基礎的相依性掃描（dependency scanning），協助企業盤點直接與間接相依套件，追蹤有漏洞套件如何進入專案，並依照程式碼的實際使用情況排定修補優先順序。
GitLab指出，近期多起軟體供應鏈事件顯示，單一套件一旦遭到入侵，可能連帶影響所有依賴該套件的專案。另一方面，AI產生程式碼的應用增加，也讓企業更難掌握程式碼與相依套件風險。一般而言，傳統的相依性掃描工具，包括GitLab既有的Gemnasium分析器，主要用來檢查專案宣告使用的套件是否存在已被通用漏洞揭露（Common Vulnerabilities and Exposures，CVE）記錄的漏洞；但在相依套件層級變深、軟體發布速度加快後，企業還需要知道漏洞套件是透過哪一條相依鏈進入專案，以及應用程式是否真的會使用到這些套件。
GitLab 19.0的SBOM相依性掃描分析器，會將專案使用的第三方函式庫與套件整理成SBOM，並以CycloneDX格式輸出SBOM檔案，再與GitLab維護的漏洞資料庫GitLab Advisory Database比對，標示已知漏洞。掃描結果可顯示在合併請求（Merge Request，MR）、漏洞儀表板與報告中，讓開發者能在程式碼發布前修正，也讓資安團隊集中檢視不同專案的風險。CycloneDX是常用於描述軟體元件清單與供應鏈資訊的機器可讀格式，可供GitLab內部流程、法規遵循報告或其他供應鏈安全工具使用。
這項新功能的重點之一，是追蹤間接相依套件來源。GitLab舉例，若library-a依賴library-b，而library-b又依賴有漏洞的library-c，分析器會呈現這條相依路徑，協助團隊判斷應從哪一層套件介入。針對Java、JavaScript／TypeScript與Python專案，分析器也會檢查程式碼是否直接匯入或引用有漏洞套件，區分哪些套件是程式碼可觸及的，哪些只是被間接帶入、但未被應用程式引用，讓團隊能把修補資源優先放在程式碼實際會用到的套件上。
這項相依性掃描也支援持續風險檢查。GitLab文件指出，當新的安全公告發布時，系統可針對已回報的SBOM元件進行持續漏洞掃描；而在每次MR或管線（pipeline）執行時，分析器也會重新檢查專案相依套件，讓企業不只在導入套件或修改程式碼時掌握風險，也能追蹤既有專案是否因後續發布的新漏洞公告而增加安全風險。這項機制對於開發活動已放緩、但仍在正式環境運作的專案尤其重要，因為即使程式碼沒有更新，既有相依套件仍可能因新的安全公告而暴露於漏洞風險。
此外，GitLab 19.0也提供相依性掃描的安全組態設定檔（security configuration profile），讓資安與平臺團隊能以標準化設定集中管理掃描規則，並一次套用到多個專案，減少逐一調整每個專案管線設定的負擔。
GitLab表示，SBOM相依性掃描功能提供給GitLab Ultimate客戶，已在GitLab.com上線，並依標準發布時程提供給GitLab Dedicated與自行管理部署用戶。
