GitLab 19.0 introduces SBOM-based dependency scanning to guard against vulnerabilities

Third-party software makes up most codebases, and recent supply chain incidents show that a single compromised package can hit every project that depends on it. AI makes the problem worse: research shows that almost half of AI-generated code contains vulnerabilities.

What changed

Traditional dependency scanners, including GitLab Gemnasium, asked a single question: which of my declared packages have known CVEs? That approach worked well enough when dependency trees were shallower and release cycles were much slower. Today's reality is more complicated.

Application security teams now have to answer much harder questions. How did a vulnerable package get into the project? What else came along with it as a side effect? And most importantly, which dependencies does your code actually use? Older tools can't answer these questions.

SBOM scanning in GitLab 19.0

With GitLab 19.0, SBOM-based (Software Bill of Materials) dependency scanning reaches general availability. The feature is no longer in beta and is available to all Ultimate customers.

The analyzer inventories every direct and transitive dependency in a project and shows which vulnerable packages your application actually uses. It checks the results against the GitLab Advisory Database and flags known issues.

Vulnerabilities appear directly in the merge request, so developers see problems before code ships to production. This keeps vulnerabilities out of live systems and speeds up remediation.

Three key benefits

The full dependency chain. The analyzer traces transitive dependencies no matter how many levels deep they go. If library-a depends on library-b, which depends on a vulnerable library-c, you see the complete path and know exactly where to step in. This matters most in large projects, where the dependency graph can include thousands of packages.

Only vulnerabilities that are actually used. Not every dependency in a manifest actually runs in the application. For Java, JavaScript/TypeScript and Python projects, the analyzer checks whether your code actually imports the vulnerable packages. Teams can defer fixes for vulnerabilities in unused packages and focus where the real risk is.

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

What it means

SBOM scanning is a serious step toward smarter supply chain management. Instead of a long list of every vulnerability, teams get a ranking by real risk and save weeks on fixes they don't actually need.

For growing organizations, built-in security profiles let teams configure scanning once and apply it to every project at once, without manually editing each .gitlab-ci.yml file.