Third-party code dominates most codebases, and four recent supply chain incidents show how a single compromised package can ripple into every project that depends on it. AI is compounding this problem: Research suggests nearly half of AI-generated code contains vulnerabilities.
Traditional dependency scanners, including GitLab's Gemnasium analyzer, were engineered to answer one question: Which of my declared packages have known CVEs? When dependency trees weren’t as deep and release cycles weren’t as fast, that approach worked.
Today’s application security teams must answer harder questions: How did a vulnerable package end up in the project? What else came with it? And which dependencies does your code actually reach? With GitLab 19.0, dependency scanning using a software bill of materials (SBOM) becomes generally available to help answer these questions. This feature inventories every direct and transitive dependency in your project and tells you which vulnerable packages your application actually uses.
SBOM-based dependency scanning is a lightweight analyzer that detects vulnerabilities in your project's third-party libraries and packages. It catalogs dependencies in an SBOM and matches those components against the GitLab Advisory Database to flag known issues.
GitLab surfaces findings where practitioners work. The vulnerabilities introduced by a change appear on the merge request, so developers can fix them before shipping. Findings are also shown in vulnerability dashboards and reports, so security teams can see results across every project in one place.
Dependency scanning report showing software bill of materials
The analyzer generates both an SBOM in CycloneDX format and a dependency scanning report — machine-readable outputs you can use within GitLab, for compliance reporting, or in broader supply chain tooling.
SBOM-based dependency scanning introduces capabilities that go beyond our Gemnasium-based analyzer:
Trace transitive dependencies to their source. The analyzer traces transitive dependencies, no matter how deeply nested. When the analyzer flags a vulnerable package, it shows you the chain that brought it into your project. If library-a depends on library-b, which depends on the vulnerable library-c, you can trace that path and know where to intervene.
Focus on vulnerabilities your code actually uses. Not every dependency included in manifest and build files runs in your application. For Java, JavaScript/TypeScript, and Python projects, the analyzer checks whether your code directly imports or requires vulnerable packages, distinguishing dependencies that are reachable from those that are pulled in transitively but never referenced by your application. GitLab surfaces reachability status on each finding, so teams can deprioritize vulnerabilities in packages their code never imports and focus remediation effort where exposure is plausible.
Continuously scan for new vulnerabilities. Invoke the analyzer when new advisories are published, and for each MR and pipeline run. This matters most for projects where active development has slowed but the code is still in production.
This release supports 24+ package ecosystems, with more planned in future releases. Adding support for new languages and file formats is now simpler because the analyzer parses lockfiles and dependency graphs directly, rather than replicating each package manager's build toolchain.
When a supported lockfile or dependency graph isn't available, the analyzer falls back to parsing manifest files such as pom.xml, requirements.txt, and Gradle build files. This surfaces direct dependencies but not transitive ones, so coverage is less complete than a lockfile-based scan. Lockfiles remain the recommended approach, but manifest parsing gives teams a starting point for projects that don’t have one.
As project counts grow, manually configuring scanners across every project becomes a significant operational burden. Projects get skipped, configurations drift, and audits surface gaps no one knew existed.
GitLab 19.0 ships with a security configuration profile for dependency scanning. Security and platform teams configure scanning once and apply it across hundreds of projects, instead of editing each pipeline by hand.
You can mandate these security standards using scan execution policies and pipeline execution policies. They allow teams to enforce dependency scanning across multiple projects without touching a single .gitlab-ci.yml file. By defining the requirement once at the group or instance level, the policy applies everywhere automatically.
SBOM-based dependency scanning is available for GitLab Ultimate customers. The feature is live on GitLab.com and rolling out to GitLab Dedicated and self-managed customers on our standard release cadence.
Teams moving from the Gemnasium dependency scanner can run both analyzers side by side during the transition. The migration guide walks you through the switch, including how to compare results between the two.
To start fresh, follow the step-by-step instructions in our set-up tutorial. Our technical documentation covers configuration, supported languages, and advanced options.
Please share your requests and ideas for dependency scanning in our feedback epic.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。