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.How GitLab uncovers vulnerable dependenciesSBOM-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 materialsThe 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.What’s possible with SBOM-based dependency scanningSBOM-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.See SBOM-based dependency scanning in action