GitLab dependency scanning finds known vulnerabilities in the packages your project uses, including runtime, development and transitive ones. The recommended method produces a CycloneDX SBOM in your pipeline and checks it against the GitLab advisory database, then rescans stored components when advisories change.
The three ideas inside it
Dependency scanning using SBOM. The analyzer runs in CI and produces a CycloneDX software bill of materials. GitLab checks those components against its advisory database and its malware advisories. The documentation recommends this method for new projects.
Continuous dependency scanning. After a pipeline succeeds on the default branch, GitLab keeps the component list. When the advisory database or malware advisories are updated, it rescans that list. A vulnerability disclosed next week can therefore show up without a new pipeline run.
The older Gemnasium method. This is the original pipeline analyzer. The documentation marks it deprecated in 17.9 and proposed for removal in 20.0, with a migration guide. If your configuration still uses it, plan the move.
Why the SBOM step matters
An SBOM is an inventory. Once you hold one, the question "are we affected?" becomes a lookup and not a repository crawl. The continuous scan relies on that inventory, which is why the order of operations matters: inventory first, matching second, rematching whenever data changes.
What the page does not say
Honest reading matters here. The page we reviewed lists Ultimate as the tier. It does not describe supported package managers and file types in detail, does not describe limitations of the scanners, and does not mention reachability analysis. If any of those decide your buying question, check the linked subpages or test on your own repositories.
| Question to answer | Where to look |
|---|---|
| Which ecosystems are supported? | The language support reference in GitLab docs |
| Do I get alerts without a pipeline? | Continuous dependency scanning, default branch only |
| Is the vulnerable code called? | Not described on the page; test it |
A short evaluation plan
- Pick three repositories: one small, one with a large lock file, one in a language you worry about.
- Run the analyzer and open the generated SBOM.
- Compare the component list with what you expect the build to ship.
- Note findings with no fix available, since those need a decision and not a patch.
- Check whether a newly published advisory appears without a new pipeline.
Where a dedicated scanner fits
If you need one inventory across several hosts, or want findings ranked by whether the vulnerable code is reachable, a dedicated scanner adds that. Safeguard provides SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and find a transitive package you never chose directly.
Quick check
Does continuous dependency scanning need a new pipeline run?
No. It rescans components from the latest successful default branch pipeline when advisory data updates.
Is the Gemnasium analyzer still the recommended method?
No. The documentation marks it deprecated in 17.9 and recommends the SBOM based method for new projects.
Sources
Last reviewed: 19 October 2026.
