Software composition analysis (SCA)
In application security, software composition analysis is the identification of the third-party and open source components an application depends on, and of the known vulnerabilities and licence obligations attached to them. Most of the code in a modern application was written by somebody else, and this is the tooling that reads it.
How it works
The analyser resolves the dependency graph, usually from lockfiles, build output or a container image, identifies each component and version, and matches those against vulnerability data. Because most components are pulled in by other components rather than declared directly, the graph goes several levels deep, and the majority of findings are typically transitive.
Better tools add reachability analysis: rather than reporting that a vulnerable version is present, they attempt to determine whether the affected function is actually called from your code. That distinction usually removes a large share of the queue, which is the difference between a list a team works through and a list a team ignores.
What goes wrong
Version matching without context produces volume, and volume produces indifference. A vulnerability in a parsing routine of a library your application only uses for formatting is present and not reachable, and reporting it at the same priority as a reachable one is how backlogs reach five figures.
The second problem is what the graph misses. Vendored code copied into the repository, components installed into a container by a package manager rather than by the application build, statically linked libraries, and a bundled front-end asset served from your own domain are all real dependencies that many configurations do not see. Container images are where this bites hardest, because the base layer contains an operating system nobody in the application team considers to be theirs.
Third, upgrading is a decision with two sides. Pinning versions makes builds reproducible and leaves you behind; floating them keeps you current and lets an upstream compromise reach you automatically, which is precisely the mechanism of a supply chain attack. Neither is free, and a policy that does not acknowledge the trade-off is not a policy.
Where this shows up in an audit
We use the component list as a map into the running application and then confirm by hand: an old library reported by the tool becomes a finding when we reach the vulnerable path through the deployed system, and an observation when we cannot. That is what separates our report from the tool’s output, and it is also how insecure deserialisation gets found, since the gadget chains come from libraries rather than from the client’s own code. Where an SBOM exists we reconcile it against what we observe. This is part of how dependency findings are confirmed against a running application.