What matters first
- Tie the inventory to a specific build or deployed artifact.
- Include transitive dependencies and relevant runtime or image components.
- Combine component data with deployment and reachability context.
Define which artifact the inventory describes
Record the application, source revision, build process, and artifact identity associated with the inventory. A repository dependency list can differ from a final container image or packaged release. Choose an inventory process that represents the deliverable your team needs to assess.
GitHub supports exporting a software bill of materials from a repository’s dependency information. That can provide a useful starting point, but coverage depends on the dependency data available. Review additional runtime, operating-system, or bundled components where they affect your deployment.
References: [1] GitHub, [2] OWASP
Connect components to ownership and deployment
Map each application release to its environments and engineering owner. Retain the inventory with release evidence so a new advisory can be checked against what was running during the relevant period. A current manifest alone may not answer a question about last month’s deployed worker.
Distinguish direct dependencies, transitive packages, build tools, runtime libraries, and base-image components. Their execution and update paths differ. A dependency used only during installation can still be important if it ran with access to source, credentials, or publishing authority.
References: [3] npm, [4] Axios maintainer
Use the inventory to investigate advisories
Match the affected package, version range, ecosystem, and relevant configuration to your artifact. Then examine whether the vulnerable component or behavior is present and reachable. Keep the difference between component presence, vulnerability applicability, execution, and confirmed misuse explicit.
Assign a component owner who can choose the appropriate update or mitigation and verify the resulting release. A component list without that handover can generate alerts without producing a practical response. Use the inventory to narrow uncertainty rather than manufacture a claim that every alert represents a breach.
Verify the updated artifact and maintain the record
After remediation, generate or refresh the inventory for the rebuilt artifact and connect it to deployment evidence. Check that older images, runners, or rollback releases are addressed where the risk requires it. Preserve the historical record needed for later investigation.
Review inventory coverage as the build changes. A new language, packaging mechanism, or generated component can create a blind spot in the existing process. The useful outcome is a repeatable answer to what software was delivered, where it ran, and who can act on an advisory.
References: [2] OWASP, [1] GitHub
Your next steps
- Choose the software artifact and release evidence your inventory must describe.
- Export dependency information and identify runtime or bundled coverage gaps.
- Connect releases to environments and remediation owners.
- Discuss how an inventory can support an application and dependency review.
Questions teams ask
Does an SBOM prove that software is secure?
No. It describes components within its coverage. Risk assessment still needs vulnerability, deployment, reachability, and permission context.
Should an SBOM include transitive dependencies?
A useful inventory should account for relevant transitive components, while making the generator’s coverage and the artifact being described clear.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .