What Is Software Composition Analysis (SCA)?

Your own code is a minority of what ships. Composition analysis inventories the open-source and third-party components an application pulls in, matches them against known vulnerability data, and flags licence obligations — which is a different job from every other tool in the application security stack, all of which look at code you wrote.

It is also the category where the finding count most reliably overwhelms the team.

Transitive dependencies are the real problem

You chose perhaps forty libraries. Those libraries chose others, and so on, and the resulting tree routinely runs to many hundreds of components. Most vulnerabilities appear somewhere in that inherited depth, in packages nobody selected and nobody has heard of.

Reachability analysis is what makes the output usable. A critical vulnerability in a function your application never calls is not a critical risk, and treating it as one is how teams learn to ignore the whole report.

The inventory has value beyond vulnerabilities

The bill of materials a composition tool produces answers a question that arrives urgently every time a widely used component is found vulnerable: are we affected, and where?

Regulatory and customer expectations are moving the same way — a software bill of materials is increasingly requested contractually, particularly by public sector and regulated buyers.

Operating it without drowning

• Prioritise by reachability and exploitation, not by severity score alone
• Automate the trivial upgrades, since a large share are low-risk patch bumps
• Fail the build on known-exploited vulnerabilities and on nothing else initially
• Track licence obligations, because a copyleft component in a distributed product is a legal exposure, not a security one
• Watch for abandoned packages, where no fix will ever arrive and replacement is the only remedy

The upgrade is sometimes the larger risk

Composition tools produce a recommendation — move to the patched version — that is usually correct and occasionally worse than the vulnerability. A major version bump to resolve a low-severity issue in an unreachable code path can introduce breaking changes, behavioural differences and a testing burden that outweighs the risk being addressed.

This is where reachability analysis earns its keep a second time. Knowing that the vulnerable function is never called converts an urgent upgrade into a scheduled one, and lets the team batch dependency work into a planned cycle rather than reacting to each advisory.

For genuinely unmaintained components the calculation is different again. No fix is coming, so the options are replacement, forking and patching yourself, or isolating the component so the vulnerable path is unreachable. All three are projects, and spotting abandoned dependencies early is what gives you time to plan one rather than discover it during an incident.

Where to start

Generate a bill of materials for your most important application and see how many components are in it. The number is almost always several times what the team expects, and it makes the case for the programme without any further argument.

See supply chain security. GuardsArm delivers vulnerability scanning.