Software Composition Analysis

Identify vulnerable, unmaintained or non-compliant third-party dependencies in your builds.

BeginnerDependency ScanningApplicationSupply Chain

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Code Static analysis, secret detection and secure coding practices.
  • Build Dependency scanning, image scanning, SBOM generation and signing.

Overview

Most application code is third-party code. SCA resolves the dependency graph from lockfiles or built artefacts and matches components against vulnerability databases and licence policy.

Why it matters

Dependency vulnerabilities are the most common route into an application, and transitive dependencies are invisible without tooling. SCA also underpins licence compliance and SBOM generation.

How it works

  1. 01The scanner parses lockfiles or inspects the built artefact.
  2. 02Components are normalised to package URLs (purls).
  3. 03Purls are matched against advisory databases such as OSV, GHSA and vendor feeds.
  4. 04Reachability or fix-availability data is used to prioritise remediation.

Common tools

TrivyOWASP Dependency-CheckSnykGrypeGitHubGitLabPythonDocker

Implementation examples

bashTrivy filesystem scan
trivy fs --scanners vuln,license --severity HIGH,CRITICAL .
Scans lockfiles in the working directory. Restricting severity keeps early adoption manageable.
yamlFail the job on fixable criticals
sca:  stage: test  script:    - trivy fs --exit-code 1 --ignore-unfixed --severity CRITICAL .
`--ignore-unfixed` avoids blocking on issues the team cannot currently resolve.

Best practices

  • Scan lockfiles, not manifests, so transitive versions are exact.
  • Automate dependency updates so remediation is routine.
  • Prioritise by fix availability and exploitability, not raw CVSS.

Common mistakes

  • Only scanning direct dependencies.
  • Suppressing findings globally instead of per component with an expiry.

Hands-on labs

Learning resources