Software Composition Analysis (SCA)

This skill covers Software Composition Analysis — identifying and managing vulnerabilities and license risks in open-source and third-party dependencies.

How to Approach Tasks

1. Identify the tool -- Read the relevant sibling skill when a tool is named.
2. Identify the concern:
   • Vulnerability management -- CVEs in dependencies, patch availability
   • License compliance -- Copyleft licenses, commercial restrictions
   • SBOM -- Software Bill of Materials generation and management
   • Supply chain security -- Package integrity, provenance, dependency confusion
   • Automation -- Auto-fix PRs, update management

Tool Routing

User mentions	Route to
Snyk, Snyk Open Source, Snyk OSS, snyk test	snyk-oss
Dependabot, dependabot.yml, GitHub security updates	dependabot
Mend, WhiteSource, Renovate, mend.io	mend
Black Duck, Synopsys, binary SCA, SOUP	black-duck

SCA Fundamentals

Vulnerability Data Sources

SCA tools compare your dependencies against vulnerability databases:

Database	Source	Notes
NVD (National Vulnerability Database)	NIST	Authoritative CVE database, US government
OSV (Open Source Vulnerabilities)	Google	Open, machine-readable, aggregates many sources
GitHub Advisory Database	GitHub	Includes private research, curated
Snyk Vulnerability DB	Snyk	Proprietary + curated, faster publication
OSS Index	Sonatype	Free lookup service
VulnDB	Risk Based Security	Commercial, broadest coverage

Coverage gaps: NVD can lag weeks to months behind disclosure. Commercial databases (Snyk, Mend) publish vulnerabilities faster due to active research teams.

CVSS Scoring

SCA tools use CVSS (Common Vulnerability Scoring System) to score severity:

CVSS v3.1 Base Score components:

• Attack Vector (AV): Network (highest risk) / Adjacent / Local / Physical
• Attack Complexity (AC): Low / High
• Privileges Required (PR): None / Low / High
• User Interaction (UI): None / Required
• Scope (S): Changed / Unchanged
• Confidentiality (C): High / Low / None
• Integrity (I): High / Low / None
• Availability (A): High / Low / None

Score ranges:

• Critical: 9.0-10.0
• High: 7.0-8.9
• Medium: 4.0-6.9
• Low: 0.1-3.9

CVSS limitations: Base score is context-free. Use Temporal score (exploit maturity, patch availability) and Environmental score (actual impact to your system) for prioritization.

Transitive Dependencies

The majority of open-source vulnerabilities are in transitive (indirect) dependencies — packages your direct dependencies depend on.

Your app
├── express@4.18.0 (direct)
│   ├── path-to-regexp@0.1.7 ← Vulnerable (transitive)
│   └── body-parser@1.20.0
│       └── qs@6.10.0 ← Vulnerable (transitive)
└── lodash@4.17.21 (direct)

Resolution strategies:

1. Upgrade direct dependency (easiest) — if newer version of your direct dep ships a patched transitive dep
2. Override transitive version — npm resolutions field, pip direct pinning, Maven dependencyManagement
3. Accept and track — if no fixed version exists, document risk in SBOM

License Compliance

Open-source licenses range from permissive to restrictive:

Permissive (generally safe for commercial use):

• MIT, BSD 2/3-Clause, Apache 2.0, ISC
• Requires: attribution in documentation

Weak copyleft (file/component-level):

• LGPL (v2, v3) — Dynamic linking typically permitted; static linking may trigger copyleft
• Mozilla MPL 2.0 — Copyleft only for modified files

Strong copyleft (network use triggers):

• GPL v2, GPL v3 — Distributing modified code requires opening source
• AGPL v3 — Using over a network may trigger open-source requirement (highest risk for SaaS)

Commercial restrictions:

• CC BY-NC — Non-commercial only
• Custom BUSL, SSPL — May restrict commercial use

SCA license policy approach:

1. Define an approved license list (MIT, Apache 2.0, BSD, ISC typically safe)
2. Define requires-legal-review list (LGPL, MPL)
3. Define blocked list (GPL, AGPL for proprietary software)
4. Configure SCA tool to fail CI on blocked licenses

SBOM (Software Bill of Materials)

An SBOM is a machine-readable inventory of all software components in an application.

Formats:

• SPDX (Software Package Data Exchange): Linux Foundation standard, NIST recommended
• CycloneDX: OWASP standard, security-focused, widely supported
• SWID Tags: ISO standard, used in enterprise/government

When SBOMs are required:

• US Executive Order 14028 (2021): Federal agencies must require SBOMs from software vendors
• EU Cyber Resilience Act (2024+): Products with digital elements require SBOMs
• Medical devices (FDA guidance): SBOMs for medical device software
• Financial services: Increasing regulatory guidance

Generating SBOMs:

# CycloneDX for npm
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# CycloneDX for Maven
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

# CycloneDX for Python
pip install cyclonedx-bom
cyclonedx-bom -r -o sbom.xml

# SPDX via syft (container + package scanning)
syft my-app:latest -o spdx-json > sbom.spdx.json

Reachability Analysis

Standard SCA flags any CVE in any dependency you use. Reachability analysis asks: "Is the vulnerable code path actually invoked by your application?"

Without reachability: 200 total CVEs across all dependencies → 200 findings.

With reachability: 200 total CVEs → 15 reachable (your code actually calls the vulnerable function) → dramatically fewer actionable findings.

Available in: Snyk Open Source (for JavaScript, Java, Python), Semgrep Supply Chain, GitHub dependency review (for some ecosystems).

Limitation: Reachability requires static analysis of your code. It can still have false positives (paths that appear reachable but are guarded by runtime conditions).

Supply Chain Security

Dependency confusion attacks:

• Attacker publishes malicious package with same name as internal package on public registry
• Build system pulls public package instead of internal one if not configured to prefer internal registry
• Mitigation: Use private registry with scope prefixes (@company/), configure npm config set @company:registry https://internal-registry, use lockfiles

Typosquatting:

• Malicious packages named similarly to popular packages (lodash → 1odash)
• Mitigation: Verify exact package names; use SCA tools with typosquatting detection

Compromised packages:

• Legitimate packages taken over by malicious actors (event-stream, ua-parser-js incidents)
• Mitigation: Pin exact versions in lockfiles, monitor security advisories, evaluate package activity/maintainership before adoption

Package integrity verification:

# npm: enable package provenance verification
npm install --include=dev
# Check SIGSTORE signatures for packages with provenance

# pip: hash checking mode
pip install --require-hashes -r requirements.txt

# Maven: verify artifact checksums (done by default in secure repos)

Remediation Prioritization

Not all CVEs need immediate action. Use a risk-based approach:

Criteria	Weight	Assessment
CVSS score	High	Base + Temporal
Exploitability	Critical	Is there a public exploit? Is it weaponized?
Reachability	Critical	Is the vulnerable code path executed?
Fix available	High	Is there a patched version?
Upgrade effort	Medium	Major version change? Breaking changes?
Asset criticality	High	Production customer data vs. internal tool

Typical SLA guidelines:

• Critical (CVSS 9+) + public exploit: 24-48 hours
• High (CVSS 7-9): 7 days
• Medium (CVSS 4-7): 30 days
• Low: Next sprint or dependency update cycle

SCA in the Pipeline

Developer workflow:

1. snyk test / npm audit / gradle dependencyCheckAnalyze locally before commit
2. IDE plugins (Snyk, Mend Advise) for real-time alerts as dependencies are added

CI pipeline:

1. SCA scan on every PR (quick, 1-2 minutes)
2. Block merge on newly introduced exploitable CVEs
3. SCA scan on main branch merge (full report for security team)

Dependency update automation:

• Dependabot or Renovate runs daily/weekly
• Creates PRs for dependency updates
• Tests run on PR
• Auto-merge safe updates (patch versions, no security risk)
• Flag breaking changes (major versions) for manual review