Dependency scanning (SCA)

The CVEs you inherited from your libraries.

Modern applications are mostly other people’s code — a typical service pulls in hundreds of transitive dependencies, and you inherit every vulnerability in all of them. Software Composition Analysis (SCA), also called dependency scanning, reads your lockfiles, resolves the full dependency tree, and matches it against vulnerability databases. It is how you learn that a library three levels down has a critical CVE, before an attacker does.

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml   # GitLab built-in SCA
 
# or standalone (Trivy scans the filesystem’s lockfiles too):
dep-scan:
  stage: test
  image: aquasec/trivy:0.53.0
  script:
    - trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 --ignore-unfixed .

Gate on fixable, not on everything

A large dependency tree always has some open CVEs, many with no available fix — blocking the build on those just teaches people to disable the scanner. Add --ignore-unfixed so you only fail on vulnerabilities that actually have a patch (which developers can act on), and gate on HIGH/CRITICAL rather than everything. Report the full list for visibility, block on the actionable subset. This is the same two-tier pattern as image scanning.

The real payoff: an inventory for the next zero-day

Dependency scanning’s biggest value shows up on the day a new critical CVE drops in a popular library. If you have been scanning (and, better, generating SBOMs — next section), answering "are we affected, and where?" takes minutes: query your inventory for the vulnerable version across every service. Without it, that same triage is days of manually grepping repos while the clock runs. SCA turns a fire drill into a query.

# the Log4Shell-style question, answered fast when you scan/inventory dependencies:
$ trivy fs --scanners vuln . | grep -i log4j
# CVE-2021-44228  log4j-core 2.14.1  -> FIXED in 2.17.1     (found in minutes, not days)