GitLab 19.0 introduces SBOM-based dependency scanning for vulnerability protection

Third-party software makes up the majority of code bases, and recent supply chain incidents show: one compromised package can affect all projects that depend on it. The problem is compounded by AI — research shows that almost half of AI-generated code contains vulnerabilities.

What Changed

Traditional dependency scanners, including GitLab Gemnasium, asked one question: which of my declared packages have known CVEs? When dependency trees were less deep and release cycles significantly slower, this approach worked fine. But today reality is more complex. Application security teams now need to answer far more sophisticated questions. How did a vulnerable package get into the project? What came with it as a side effect? And most importantly — which dependencies does your code actually use? Old tools don't answer these questions.

SBOM-Scanning in GitLab 19.0

In the new GitLab 19.0 version, SBOM (Software Bill of Materials) based dependency scanning moves into general availability. This means the feature is no longer in beta testing and is available to all Ultimate clients. The analyzer inventories each direct and transitive dependency of the project and shows which vulnerable packages your application actually uses. Results are compared with the GitLab Advisory Database and known issues are flagged. Vulnerabilities appear directly in merge requests — developers see problems before sending code to production. This prevents vulnerabilities from reaching live systems and accelerates the fix process.

Three Main Advantages

Full dependency chain. The analyzer traces transitive dependencies, regardless of nesting depth. If library-a depends on library-b, which depends on vulnerable library-c, you see the complete path and know exactly where to intervene. This is especially important when working with large projects where the dependency graph can contain thousands of packages.

Only genuinely used vulnerabilities. Not every dependency from the manifest actually works in the application. For Java, JavaScript/TypeScript and Python projects, the analyzer checks whether your code actually imports vulnerable packages. This allows you to defer fixing vulnerabilities in unused packages and focus where there is real risk.

Continuous scanning. Run the analyzer when new advisories are published, with every merge request and build. This is especially important for projects where development has slowed, but code still runs in production and requires protection.

What This Means

SBOM-scanning is a serious step toward smarter supply chain management. Instead of a long list of all vulnerabilities, teams get ratings by actual risk, saving weeks on fixes that aren't actually needed. For growing organizations, built-in security profiles allow you to configure scanning once and apply it to all projects at once — without manual editing of each .gitlab-ci.yml file.