Reduce supply chain risk with SBOM-based dependency scanning (opens in new tab)

SBOM-based dependency scanning in GitLab 19.0 addresses the limits of traditional scanners that focus only on declared packages and known CVEs. It inventories direct and transitive dependencies, traces how vulnerable packages entered a project, and identifies whether application code actually reaches them. The result is more targeted remediation and easier organization-wide enforcement of supply chain security.

Why Traditional Dependency Scanning Falls Short

• Modern applications rely heavily on third-party and deeply nested dependencies.
• Supply chain compromises can affect every project that depends on a vulnerable package.
• AI-generated code further increases risk, with research indicating that nearly half contains vulnerabilities.
• Teams need to know not only which packages are vulnerable, but also:
  • How they entered the project
  • What dependencies they brought with them
  • Whether the application actually uses them

How SBOM-Based Scanning Works

• The analyzer inventories dependencies in a CycloneDX-format software bill of materials.
• Components are matched against the GitLab Advisory Database to identify known vulnerabilities.
• Findings appear in:
  • Merge requests, so developers can address issues before release
  • Vulnerability dashboards and reports, for centralized security oversight
• GitLab produces both an SBOM and a dependency scanning report for compliance and supply chain tooling.

Tracing and Prioritizing Vulnerabilities

• The analyzer follows transitive dependency chains regardless of nesting depth.
• Teams can see the path a vulnerable package took into the project—for example, library-a → library-b → library-c.
• For Java, JavaScript/TypeScript, and Python, GitLab checks whether vulnerable packages are directly imported or required.
• Findings include reachability status, helping teams prioritize vulnerabilities their code can plausibly execute.
• Scans can run on merge requests, pipeline executions, and when new advisories are published, including for production systems with little ongoing development.

Supported Ecosystems and Input Files

• The release supports more than 24 package ecosystems, with additional support planned.
• Lockfiles and dependency graphs are preferred because they provide complete transitive dependency information.
• If those are unavailable, the analyzer can parse manifests such as:
  • pom.xml
  • requirements.txt
  • Gradle build files
• Manifest scanning identifies direct dependencies but offers less complete coverage because transitive dependencies may be missing.

Centralized Configuration and Enforcement

• GitLab 19.0 provides a security configuration profile for applying dependency scanning across many projects.
• Security and platform teams can configure scanning once instead of maintaining individual pipeline files.
• Scan execution policies and pipeline execution policies can enforce requirements at the group or instance level without modifying .gitlab-ci.yml files.
• Centralized policies reduce configuration drift, skipped projects, and audit gaps.

Availability and Migration

• SBOM-based dependency scanning is available to GitLab Ultimate customers on GitLab.com and is rolling out to Dedicated and self-managed installations.
• Teams migrating from Gemnasium can run both analyzers in parallel and compare their results.
• GitLab provides setup instructions, migration guidance, and documentation for supported languages and advanced configuration.

Teams should prefer lockfile-based SBOM scanning, enable it centrally through security policies, and prioritize remediation based on dependency reachability rather than vulnerability presence alone.