Software Composition Analysis: Securing Your Open-Source Dependencies

Most of the code in a modern application was written by someone else. A typical web app pulls in hundreds or thousands of open-source packages. Software Composition Analysis (SCA) tells you what they are and which carry known risks.

What SCA does

• Inventories dependencies from manifests and lockfiles, including transitive ones.
• Matches versions against vulnerability databases.
• Flags licence risks, such as copyleft licences in proprietary products.
• Generates SBOMs, software bills of materials.
• Suggests fixes, usually the minimum safe version.

Direct vs transitive dependencies

You choose your direct dependencies. They bring their own dependencies, which bring more. Many vulnerabilities live deep in this tree, in packages you have never heard of. Updating them may require updating the direct dependency that pulls them in, or using overrides.

Beyond known CVEs: supply chain attacks

Known vulnerabilities are only part of the risk. Software supply chain failures rose to third place in the OWASP Top 10 2025. Attack types include:

• Malicious packages published with names similar to popular ones, known as typosquatting.
• Compromised maintainer accounts pushing malicious updates to legitimate packages.
• Dependency confusion, where a public package with the same name as an internal one is installed instead.
• Install scripts that run arbitrary code at install time.

Managing alert volume

SCA tools often report many vulnerabilities. Prioritise:

1. Reachability: is the vulnerable function actually called by your code? Some tools analyse this.
2. Exposure: production runtime dependencies over development-only tools.
3. Exploitation: known exploited vulnerabilities first.
4. Fix availability: easy upgrades are quick wins.

Supply chain hygiene

• Commit lockfiles and install with exact versions, such as npm ci.
• Review new dependencies before adding them: maintenance activity, popularity and necessity.
• Minimise dependencies; avoid packages for trivial functions.
• Scope internal packages and configure registries to prevent dependency confusion.
• Disable or review install scripts where your package manager allows.
• Consider a delay before adopting new versions, since many malicious releases are caught within days.
• Pin and verify CI actions and build tools, not just application libraries.

SBOMs

An SBOM lists every component in a release. Customers and regulators increasingly ask for them, and they make it fast to answer "are we affected?" when a new vulnerability is announced.

Where SCA fits

SCA runs on every pull request and continuously against your main branch, since new vulnerabilities are disclosed for packages you already use. Combine it with dynamic testing to confirm what is actually exploitable in your deployed app.

SecurityInfinity's static analysis and network agents flag vulnerable components in code and in deployed services, and verify exposure. Start free.

Frequently asked questions

Is SCA the same as dependency scanning?

Broadly, yes. SCA is the formal term and often includes licence analysis and SBOM generation.

How do I fix a vulnerability in a transitive dependency?

Update the direct dependency that pulls it in, or use your package manager's override or resolution feature to force a safe version.

Do lockfiles protect against supply chain attacks?

They prevent unexpected version changes, which helps, but a malicious version already in the lockfile is still installed.