Practice : Software Composition Analysis (SCA)

Purpose and Strategic Importance

Software Composition Analysis (SCA) identifies known vulnerabilities, licensing risks, and versioning issues in open-source and third-party components. It helps teams manage the security and compliance posture of their software supply chain, reducing exposure to widely exploited threats.

SCA is a critical part of modern software development, enabling secure reuse of dependencies without compromising agility, innovation, or regulatory obligations.

Description of the Practice

  • SCA scans application dependencies, transitive packages, and container layers for known issues in public vulnerability databases (e.g. CVE, NVD).
  • Tools include OWASP Dependency-Check, Snyk, GitHub Dependabot, WhiteSource, and Sonatype Nexus Lifecycle.
  • SCA helps ensure compliance with software licenses (e.g. GPL, MIT, Apache) and internal policies.
  • Results highlight affected versions, available patches, and risk severity.

How to Practise It (Playbook)

1. Getting Started

  • Choose an SCA tool that integrates with your source control, build pipelines, and languages.
  • Perform a baseline scan to identify existing vulnerabilities and license issues.
  • Enable automatic or manual pull requests for upgrades (e.g. Dependabot PRs).
  • Educate teams on how to interpret SCA results and triage issues.

2. Scaling and Maturing

  • Automate SCA scans in CI/CD workflows with visibility into severity, age, and fixability.
  • Establish policies for acceptable license types and CVSS score thresholds.
  • Track metrics like mean time to remediation (MTTR) and fix rate over time.
  • Pair SCA with inventory tools to map component usage across services and teams.
  • Treat dependency upgrades as routine engineering work - not crisis-driven.

3. Team Behaviours to Encourage

  • Keep dependencies current - “evergreen” projects reduce surprise risk.
  • Discuss dependency hygiene during code reviews and sprint planning.
  • Celebrate quick remediation of high-severity CVEs.
  • Involve legal or compliance stakeholders early when dealing with restrictive licenses.

4. Watch Out For…

  • Ignoring transitive dependencies - many issues lie deeper in the tree.
  • Failing to upgrade due to version lock-in or test coverage gaps.
  • Overwhelming teams with unactionable noise - prioritise by impact.
  • Delayed remediation that leaves critical CVEs unaddressed for months.

5. Signals of Success

  • High-severity vulnerabilities are remediated quickly and reliably.
  • Teams proactively manage their dependency risk and technical debt.
  • Open-source usage is secure, transparent, and policy-aligned.
  • SCA is a default part of project setup and delivery pipelines.
  • Software supply chain risk is actively measured and reduced.