It commonly resolves direct and transitive dependencies, component names and versions, licenses, provenance, and matches to published vulnerability records or organization-defined policies. Analysis may use manifests, lockfiles, source trees, package metadata, build outputs, container images, or binary signatures.
The central evidence is component identity, not an analysis of the application’s original code or a live attack. Accurate identification helps teams investigate newly disclosed vulnerabilities, manage unsupported dependencies, review license obligations, and produce or verify software bills of materials. Results need continuing maintenance because dependencies and external intelligence change after release.
Key points
Evidence examinedPackage manifests and locks, dependency graphs, artifact contents, package identifiers, checksums, build metadata, and component databases.
Typical outputsComponent inventory, dependency relationships, version and license information, policy findings, vulnerability matches, and upgrade or remediation candidates.
Sound operationScan the artifacts actually built and deployed, include transitive and embedded components, preserve version evidence, update intelligence, and assign owners for remediation decisions.
Important limitationA component-to-advisory match does not establish that vulnerable code is present, reachable, or exploitable in a particular product. Missing metadata and incorrect version resolution can also create false negatives or positives.