What is SCA (Software Composition Analysis)?

Definition

Software Composition Analysis (SCA) is the process of identifying all open-source and third-party components in a software project and evaluating them for known security vulnerabilities, license compliance issues, and supply chain risks. SCA covers the code your team did not write — the dependencies that make up the majority of most modern applications.

The typical application today is 80–90% open-source code by volume. SCA exists because SAST only analyzes first-party code — it cannot assess the security posture of npm packages, Maven artifacts, or PyPI libraries your application depends on.

How SCA Works

SCA tools analyze your dependency graph rather than your source code:

1. Dependency discovery — the tool reads your package manifests (package.json, requirements.txt, pom.xml, go.mod) and lock files to identify every direct and transitive dependency
2. Version identification — every package version is catalogued
3. CVE matching — each package-version pair is checked against vulnerability databases (NVD, OSV, GitHub Advisory Database, commercial databases)
4. License identification — the license for each dependency is identified and checked against an approved-license list
5. Supply chain analysis — the package's integrity, maintainer history, and known compromise indicators are assessed

What SCA Detects

SCA addresses four categories of risk:

Known CVEs in dependencies

When a vulnerability is disclosed in an open-source library, it is assigned a CVE (Common Vulnerabilities and Exposures) number. SCA tools check whether any of your dependencies have known CVEs and what the severity and exploitability of those CVEs are.

Transitive dependency vulnerabilities

Your direct dependencies have their own dependencies. A vulnerability in a transitive dependency (a package your dependency depends on) is as exploitable as a direct one. SCA tools map the full dependency tree, not just what is in your manifest.

License compliance

Open-source licenses carry obligations. GPL licenses require derivative works to be open-sourced. Commercial products that include GPL-licensed components without compliance may face legal exposure. SCA identifies license conflicts before they become legal issues.

Supply chain risks

Compromised packages, typosquatting, maintainer account takeovers, and malicious code injections in otherwise legitimate packages. SCA tools assess package integrity using cryptographic hashes and monitor for known compromise events.

Remediating SCA Findings

SCA fixes are typically one of:

• Version upgrade — update the vulnerable package to a patched version
• Dependency replacement — replace an unmaintained or high-risk package with a maintained alternative
• Virtual patch — mitigate the vulnerability at the application level when a patched version is not available

SCA and Autonomous Code Governance

Dependency updates are the most automatable category of security remediation: the fix is almost always a version bump. Autonomous code governance systems can take SCA findings, generate the version update, run the test suite to confirm compatibility, and deliver the PR — with no human in the loop until review.

Hydra treats SCA findings as high-priority, high-confidence remediation targets precisely because the fix is deterministic and the impact is immediately measurable in the updated dependency graph.