What it means
Modern applications rely on libraries, packages, and other reused components. SCA examines those dependencies and compares them with information such as vulnerability advisories and license metadata. It often includes indirect dependencies introduced by another package. Its output is a list of candidates requiring investigation, not a verdict that every application is exploitable. Matching quality depends on accurate component identity and version information; practical risk also depends on how the component is built, configured, exposed, and used. License questions may need specialist review separate from the security decision.
The idea at a glance / Software
Compare the packages in two builds.
SCA compares component identities and versions with advisory information; a rebuilt artifact and the running artifact are separate records.
ShopCart, its suppliers, and advisory AD17 are fictional. Scan S42 describes B42 / D42; S43 describes rebuilt B43 / D43. Each records the parent and its nested package in the selected artifact. Both use the same advisory. Production still runs B42 / D42.
READ THE PICTURE
Compare the evidence
B42 contains the version AD17 names as affected. B43 contains the stated fixed version, so that selected dependency no longer matches AD17’s affected range. Production still runs B42 / D42. Neither scan establishes runtime exploitability or a completed production repair.
Keep in mindThis comparison assumes accurate component identities and selected package coverage. It does not establish runtime exploitability, acceptable licenses, or absence of other vulnerabilities. Functional checks remain separate. B43 has not been deployed; production retains B42 and its AD17 match.
Read the complete example
- Compare the evidence. B42 contains the version AD17 names as affected. B43 contains the stated fixed version, so that selected dependency no longer matches AD17’s affected range. Production still runs B42 / D42. Neither scan establishes runtime exploitability or a completed production repair. AD17 identifies ParseWorks parse-lite versions 1.0.0 through 1.4.9 inclusive and names 1.5.0 as fixed. Its affected runtime conditions require legacy parsing enabled and untrusted input reaching it. Those conditions are not evaluated here. Updating the parent cart-core changes the packaged transitive dependency; adding a second, newer parse-lite copy while leaving 1.4.0 in the artifact would not support this result. License metadata is not evaluated in this example. Scan IDs bind the findings to their respective artifacts, not to whichever version happens to be running later. S42 records CartWorks cart-core 2.3.0 directly including ParseWorks parse-lite 1.4.0. S43 records cart-core 2.4.0 including parse-lite 1.5.0, with no older parse-lite copy remaining in that selected snapshot. These authored scan records do not incorporate the separate condition check from the SBOM lesson. D42 and D43 stand for recorded artifact digest references, not displayed hash bytes or live verification.
This comparison assumes accurate component identities and selected package coverage. It does not establish runtime exploitability, acceptable licenses, or absence of other vulnerabilities. Functional checks remain separate. B43 has not been deployed; production retains B42 and its AD17 match.
Diagram references: OWASP: Vulnerable Dependency Management
AN ILLUSTRATIVE SCENARIO
A rebuilt package is not a production repair
Chronos Hub’s scan S42 identifies parse-lite 1.4.0 nested inside cart-core 2.3.0 in artifact D42. Fictional advisory AD17 includes that version. Rebuilt D43 replaces the parent package and contains parse-lite 1.5.0, outside the stated affected range. Scan S43 checks that selected dependency snapshot; it does not evaluate runtime conditions or license acceptability. Production still runs D42. The owner must investigate applicability, test the rebuild, and separately verify any deployment. Adding a newer copy while retaining the old one would not support the same conclusion.
Put it to work
- Run dependency analysis on the manifests and packaged artifacts relevant to production. Include indirect dependencies and record the release or commit associated with each result.
- Triage findings with the application owner using advisory details, exposure, available fixes, and operational impact. Give accepted exceptions a reason, owner, and review condition.
- Apply a supported update or remove the unused component. Rebuild and test the application, then scan the resulting artifact to confirm which dependency versions it actually contains.
How to check your work
Choose a test dependency with a documented advisory and confirm the tool detects it. After updating, inspect the resolved dependency tree and final artifact, and verify that the application’s important workflows still behave correctly.
Connect the ideas
- SBOM
An inventory of software components and their relationships, used to investigate exposure when vulnerabilities are disclosed.
- Vulnerability
A weakness in a system, process, or person that makes a loss easier to cause.
- Patch
A vendor or internal change that removes or reduces a vulnerability in running software.