Start with four lists: repositories, deployed services, machines and SaaS accounts. For each, note the owner and where its dependencies are declared. An afternoon of this work gives you a usable inventory, and it answers the first question in every incident, which is whether the affected thing is yours.
Why the inventory comes first
When a new advisory lands, the first question is "do we use this?" Without an inventory, you search by memory. NIST's patch management guide places identification of what needs patching at the start of the cycle for this reason. Alert tools also depend on it: Dependabot alerts require your manifest and lock files to be present and current, so an unlisted repository gets no alerts at all.
The four lists
| List | Where to get it | Fields |
|---|---|---|
| Repositories | Your code host, including archived and forgotten ones | Name, owner, language, deployed or not |
| Services | Cloud console, hosting dashboard, DNS records | URL, repository, internet-facing yes or no |
| Machines | Laptops, build runners, servers | Owner, operating system, auto-update on |
| Accounts | Domain registrar, cloud, payment, email, CI | Owner, MFA on, recovery contact |
DNS records are a good truth source for services, because forgotten test sites often still resolve.
Dependencies inside each repository
For each repository, record where dependencies are declared and whether a lockfile is committed. A command line scan can discover many of them. OSV-Scanner can scan a directory recursively with the scan -r option and will find supported lockfiles below it, which is handy for a folder of old projects.
Mark what is exposed
Add one column that matters more than the rest: is it reachable from the internet? An exposed service with an old framework is a more urgent item than an internal script with the same library.
Keep it current without a project
- Add a line to your new-project checklist: add it to the inventory.
- Add a line to your offboarding checklist: remove access, update owner.
- Review the lists in your monthly slot and delete what is dead.
Delete is a legitimate outcome. Retiring an unused service is the cheapest patch there is.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a software bill of materials the same as an inventory?
No. An SBOM lists components inside one piece of software. An inventory lists the pieces of software and systems you run. You want both over time.
How detailed should the first version be?
Name, owner, exposure and where dependencies live. Add detail only when a question needs it.
Safeguard asset discovery and SBOM generation can build and refresh this view for you, and the free scan at gold.safeguard.sh/scan shows what it finds in one project.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- GitHub Docs, about Dependabot alerts
- OSV-Scanner usage
Last reviewed: 19 October 2026.
