Home / Knowledge hub / SCA
Knowledge hub
SCA
Checking your libraries against databases of published vulnerabilities.
What it means
SCA stands for software composition analysis. It takes the list of third-party libraries your application depends on and checks each version against public databases of known flaws.
It answers dependency risk cheaply, it runs on every build without fuss, and most teams should already have it switched on.
Why it matters
Somebody else wrote most of the code you ship. A known flaw in a popular library is the easiest thing in the world to exploit. Somebody already published the exploit, and attackers can find every site still running that version.
Keeping up is unglamorous work that pays. Upgrading a component before anyone comes looking is the cheapest security outcome available. It also automates well. Once the check runs on every build, staying current becomes routine maintenance. Deleting a dependency you no longer need is faster still. It shortens conversations with buyers too, because a current list of components is the evidence behind half the questions they ask.
How it shows up
Two things go wrong. Volume comes first: a mature application produces hundreds of alerts, most of them for code paths it never calls, and people stop opening the queue.
Scope comes second. Composition analysis only knows about flaws somebody has already published. It says nothing about the code your team wrote last week, which is where the flaws unique to your business live. Treat it as one input beside others. Pair it with a way to tell which alerts touch code you actually run, and with testing aimed at the application you built. Watch the upgrade path as well. A library three major versions behind is a project rather than a patch, and waiting only makes that project larger.
Questions people ask
SCA, answered
What is the difference between SAST and SCA?
Static analysis reads the code your team wrote. Composition analysis checks the libraries you imported against published flaws.
They answer different questions, and neither one covers the other's ground.
Do we need to patch a vulnerable library we never call?
Often not urgently, but decide it rather than assume it. Reachability analysis tells you whether your code touches the vulnerable function.
Without that answer, teams either patch everything or patch nothing. Upgrading anyway is frequently cheaper than the investigation.
Is SCA the same thing as an SBOM?
No. An SBOM is the list of what you ship.
Composition analysis is what you do with that list, checking each version against databases of known flaws.
Why does our tool report hundreds of issues?
Because a mature application pulls in a lot of code, and published flaws accumulate against it over the years.
Most alerts touch paths your application never runs. Filter by what you actually reach, and fix the ones that matter first.
Does composition analysis cover transitive dependencies?
A good one does, and that is rather the point. The flaw usually sits three levels down, in a package nobody on your team chose directly.
A tool that only reads your top level list will walk straight past it.
Sources
Where this comes from
Related
Terms that sit next to this one
SBOM
A list of every component your application includes, with versions.
Dependency vulnerability
A known flaw in a library your application ships.
Known-vulnerable component
A library or runtime with a published flaw that you are still shipping.
Patching
Applying the fixes that vendors and maintainers publish.
Supply chain attack
Reaching you through a library, a build tool or a vendor you trust.
Who checks the code you wrote?
Composition analysis covers published library flaws. Cyberlop tests ten classes across the application you built as well, injection and authorisation included. Book a look at yours.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.