Software composition analysis, commonly shortened to SCA, examines the components an application did not implement itself. The result is an inventory tied to exact versions and evidence, rather than a list based on what the team remembers installing.
What the analysis reads
An SCA tool can inspect package manifests, lockfiles, container images, compiled artifacts, or a combination of them. Each source answers a different question. A manifest records direct intent. A lockfile records the versions selected by the package manager. An artifact shows what reached a build. Comparing those sources can reveal unused packages, undeclared components, and differences between development and production.
The inventory includes direct packages and each transitive dependency they bring with them. That matters in an audit of vibe-coded software, where a small number of explicit package choices can resolve into a much larger component tree.
| Evidence source | What it shows | What it can miss |
|---|---|---|
| Package manifest | Declared direct dependencies | Exact resolved versions |
| Lockfile | Resolved dependency graph | Components added outside the package manager |
| Built artifact | Components present in a build | Packages loaded only at runtime |
| Runtime inventory | Components observed in use | Paths not exercised during observation |
What an audit checks
The scan result is a starting point. An auditor still has to determine whether a finding affects the application, whether the vulnerable function is reachable, and whether a package is used in production. The review also checks licences, maintenance status, package sources, and whether separate libraries duplicate the same capability.
A useful review follows a short sequence:
- Establish the inventory: Resolve direct and indirect components to identifiable versions.
- Match known issues: Compare those versions with current vulnerability data.
- Check reachability: Trace whether the application uses the affected code path.
- Review controls: Confirm update policy, source restrictions, tests, and ownership.
- Record the result: Produce a software bill of materials or another maintained inventory.
Why a scan is not the whole answer
SCA can identify a version with a published issue, but it cannot by itself describe the application's full risk. A development-only tool and a package exposed to untrusted input do not have the same effect. A clean scan also does not prove that every component is safe, because vulnerability data and inventories can be incomplete.
The analysis becomes useful when it is combined with dependency risk, application architecture, and test evidence. That combination turns a scanner report into a ranked repair list: remove dead packages, update exposed components, isolate hard-to-replace libraries, and document accepted risk. It is part of the engineering discipline required when generated code moves into production.
