During an incident, your open source inventory must tell you which services run the affected package, which releases shipped it, and who to contact. S2C2F's Inventory It practice frames this: know where artifacts are deployed in production, so affected teams can be reached and act.
The scenario behind the practice
The S2C2F specification describes the case this way: a critical vulnerability is found in log4j, and the incident response team wants to know all the production services using log4j so they can staff and coordinate a response. The practice says that once artifacts are ingested and scanned, you need an inventory of where each one is used, including the services it is deployed in and the products it was released in.
It also says this is what lets teams affected by a compromised package be contacted so that the package can be removed. An inventory that lists packages but not owners fails that test.
Ten questions to test your inventory
Run these as a drill. If you cannot answer one in minutes, that is a gap to fix.
| Question | Field you need |
|---|---|
| Which services use package X? | Component to service mapping |
| Which versions are deployed? | Version per deployment |
| Is it a direct or transitive dependency? | Dependency path |
| Which released products contain it? | Release to component mapping |
| Who owns each affected service? | Named owner or team |
| Is it in production, staging or only in tests? | Environment |
| Where did we get it from? | Source or registry |
| Is a fixed version available? | Advisory and version data |
| Has the affected code path been reached? | Reachability information |
| What did we change, and when? | History of updates |
The OSPO book makes a related point in its day-to-day operations chapter: managing an inventory of open source used in the organization gives the OSPO awareness of its surface area, and a base for overall risk management and for dealing with issues about specific projects such as security problems, license changes and lifecycle issues.
Include more than package manifests
An inventory built only from lockfiles misses things. The OSPO book mentions that risk management can include generating SBOMs that cover software from vendors, legacy software and proprietary software, not only open source. The S2C2F specification lists ways open source enters that never touch a package manager, such as cloned repositories, pasted source and checked-in binaries. Add a periodic sweep to find those.
Keep it fresh
An inventory drifts. Rebuild it from builds and deployments, not from a spreadsheet someone edits. Then run the drill above every quarter and record how long it took. A falling time is a simple, honest metric.
Try it yourself
Click through it at your own pace, or open it full screen. Try finding one package and see how many of the ten questions the view answers.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, asset discovery and reachability analysis, which together address several of the questions above. Try the free scan at gold.safeguard.sh/scan.
Quick check
How often should we run the inventory drill?
Quarterly is a reasonable start. Record how long it takes so you can see improvement.
Is a list of packages enough?
No. Without service, owner and release mapping you cannot contact affected teams quickly.
Sources
Last reviewed: 19 October 2026.
