Inventory Exposed Software Components
Map software versions to internet-facing services and owners so dependency alerts reach the systems that can be affected.
A package list does not show where code runs. A vulnerable library may be in a build tool, a private worker, or an internet-facing API. For useful triage, join software identity to deployed service, environment, and exposure. OWASP recommends knowing dependencies and assessing their use; provenance can help tie an artifact to a build, but neither source alone supplies a full runtime inventory.
Component exposure record
| Field | Example evidence |
|---|---|
| Service and owner | Deployment manifest and team record |
| Environment | Production, staging, or build only |
| Artifact | Immutable image or package digest |
| Component | Ecosystem, name, resolved version |
| Entry point | Route, queue, scheduled job, or none |
| Exposure | Public, partner, internal, or isolated |
| Last checked | Inventory timestamp |
Start from deployment records and owned build manifests. Do not scan public targets to create this inventory. Extract component versions from a lockfile or software bill of materials tied to the artifact digest. Mark unknown versions as unknown; a guessed major version can cause a wrong remediation decision. Map direct and transitive components separately. If several services use one image, record each deployment because exposure and controls may differ.
Use the map in triage
When an advisory arrives, match its ecosystem and affected version range to the deployed component. Then check whether the component is loaded or reachable in the relevant service. Do not treat lack of a public route as proof that the code cannot be exploited; internal and build paths still matter. Keep evidence for a non-applicable decision and recheck it after deployment changes.
Give each exposed service an accountable owner and a review date. Refresh inventory when a release changes an artifact, not only during a quarterly audit. Export a compact list for responders: service, digest, component, version, exposure, owner, and last verification. This makes alert routing faster without claiming that an inventory by itself prevents exploitation.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.