Software composition analysis (SCA)

Software composition analysis works on the dependency graph rather than on code anybody at your organisation wrote. It resolves what a build actually pulls in, including the transitive packages nobody chose deliberately, matches each component and version against public vulnerability databases, and reports what is known to be affected. Licence obligations usually come out of the same scan, which is why the tooling tends to be bought by legal and engineering jointly.

It is genuinely essential and reliably overwhelming, and both facts follow from the same property: it reports on what is present, not on what is reachable. A vulnerability in a parser your application never calls, in a development dependency that never ships, and in the request path of your authentication flow are all rendered as the same coloured row. Teams that adopt the tooling without a triage discipline get a queue that grows faster than anybody can process, and the predictable outcome is that the whole feed stops being read.

Making the output usable

• Separate runtime dependencies from build and development ones before looking at severity, because a critical finding in a tool that never leaves the pipeline is not a critical finding for the product.
• Ask whether the vulnerable function is called at all. Reachability analysis, where the tooling supports it, removes a large share of the queue on evidence rather than on assumption.
• Fix by upgrading the direct dependency that pulls the vulnerable package in, since patching a transitive version directly produces a resolution nobody can reproduce from the manifest.
• Keep an inventory you can query when the next widely-publicised vulnerability lands, so the question of whether you are affected takes minutes rather than a week.

This tooling finds what is publicly known about somebody else’s code, which makes it complementary to static analysis rather than a substitute: neither one looks at what the other examines.