Your code is the small part. The libraries you pull in are the big part — and that is where most of your CVEs live. In Part 3 of the GitLab DevSecOps series, Patrick Steger and I bring up a tiny Spring Boot demo, wire it into a GitLab pipeline, and then add Software Composition Analysis with a single include line.
The Demo Project#
To make SCA tangible we need something to scan. We create a new GitLab project from the Spring template and call it videodemo. What you get is a minimal Spring Boot application: a web service that returns “Spring is here!”, a unit test that calls the service and asserts the response, and a Maven build with a pom.xml. Tiny — but exactly the point. The handful of lines we wrote drag in dozens of third-party JARs.
A Minimal Pipeline First#
Before we touch security, we need a pipeline. We add a .gitlab-ci.yml at the repo root with two jobs: build and test. The build job uses a versioned Maven Docker image, runs in the default build stage, and stores the resulting JAR as an artifact. The test job runs in the default test stage, executes the unit tests, and publishes the test report so GitLab can render it in the UI. Commit, push, and GitLab kicks off the run. Both jobs go green. Now we have a baseline to add security on top of.
What SCA Actually Is#
Software Composition Analysis — also called dependency scanning — looks for known vulnerabilities in the libraries your application uses. The scanner walks your dependency tree, matches each library and version against public CVE databases, and reports anything with a known issue. In GitLab, SCA is part of the Ultimate tier and is implemented with Gemnasium, an open source scanner that GitLab acquired and now maintains.
Why do we need it for an application this small? Look at the build log. A Spring Boot app pulls in a long list of JARs — Spring, Jackson, Tomcat, logging, the works. Your code is a thin layer on top of someone else’s code. If one of those someones shipped a CVE, you shipped a CVE. The only way to know is to scan.
Adding SCA to the Pipeline#
Enabling Gemnasium is a one-liner. We include the GitLab template Security/Dependency-Scanning.gitlab-ci.yml, commit, and push. GitLab adds a gemnasium-maven-dependency_scanning job to the next pipeline run. It pulls the Gemnasium image, walks the Maven dependency tree, and uploads the findings as a pipeline artifact.
Because the template is open source, you can also copy it into your own repository if you need more control — pin versions, change rules, run it on a schedule. For most teams the include is enough.
Where the Findings Live#
Two places. First, the raw scan output is available as a JSON artifact under Pipelines → your run → Artifacts. You can feed that into any vulnerability management system you already have. Second, GitLab itself ships a vulnerability management view under Security & Compliance → Vulnerability Report. Gemnasium populated it automatically, sorted by severity. The full management workflow (triage, dismiss, link to issues) is an Ultimate feature and gets its own session later in the series.
The first scan on our toy project surfaced 28 critical and 61 high vulnerabilities. From a few lines of demo code. That is the reality of modern dependencies.
Do You Have to Fix All of Them?#
Generally yes — but be pragmatic. Patrick’s recommendation, which matches mine: do not start by deeply analyzing each CVE to decide whether it actually affects your code path. That work eats more time than just upgrading. Bump every dependency to a fixed version first. Only for the ones you cannot upgrade — no patched version exists, or the upgrade breaks you — do the deeper analysis. Then decide on compensating controls or document the accepted risk.
The point of SCA in CI is to make this a routine, not a project. Every commit gets scanned. New CVEs get caught the next time the pipeline runs. The cost of staying current is low. The cost of getting behind is a panic upgrade under audit pressure.
Key Takeaways#
Most of your code is not yours. A small Spring Boot demo pulls dozens of JARs. SCA is non-optional for any real application.
GitLab makes SCA a one-liner.
includetheSecurity/Dependency-Scanning.gitlab-ci.ymltemplate. The Gemnasium job appears in your next run.Findings live in two places. A JSON artifact for your own tooling, and the built-in vulnerability report under Security & Compliance for the GitLab-native workflow.
The template is open source. Copy it into your repo when you need to pin, schedule, or customize. The default include is enough for most teams.
Upgrade first, analyze second. Do not spend hours proving a CVE does not affect you. Bump to a fixed version. Save the deep analysis for the dependencies you genuinely cannot move.
SCA is Ultimate-tier on GitLab. The scanner runs everywhere, but the integrated vulnerability management UI is paid. Know what you are buying before you wire your reporting around it.