ID.AM-02 says inventories of software, services, and systems managed by the organization are maintained. That includes commercial software, open source libraries, custom applications, API services and cloud based tools. The inventory is what you consult the morning a new critical vulnerability is announced and someone asks, "Are we running it?"
CSF is voluntary guidance and there is no CSF certification. Nobody should describe a company as "NIST compliant" because of an inventory.
What good looks like
You can answer three questions quickly: what systems do we run, what software and services are in each, and who owns them. The inventory updates when platforms change, including containers and virtual machines, because those change daily.
How to implement it
- Start at the system level. List each application and environment with an owner and a purpose.
- Add services: SaaS tools from your SSO list, cloud accounts and external APIs.
- Add software components. For your own code, generate a software bill of materials from the build so open source dependencies are listed with versions.
- Automate collection where you can: cloud APIs for resources, container registry scans for images, package manifests for libraries.
- Reconcile monthly. Anything running that is not on the list is a finding, and anything listed but not running is cleanup.
- Keep the inventory queryable, so a search by package name takes minutes.
Evidence to collect
- The system inventory with owners and dates.
- SBOMs for key applications.
- A reconciliation record showing differences found and resolved.
- Screenshots or exports from cloud and container inventories.
What to record per entry
Keep the schema small enough that people fill it in. For a system: name, owner, environment, purpose, tier and where the code or configuration lives. For a service: supplier, owner, data shared and renewal date. For a software component: name, version, ecosystem, where it is used and its license. A column for end of life date pays for itself the first time a runtime loses support.
Making it stay current
Manual inventories decay within a quarter. Three habits prevent that.
- Generate component lists in the build pipeline, so every release produces a fresh bill of materials.
- Pull cloud resources and container images from the provider and registry APIs on a schedule, and diff against the last run.
- Treat the inventory as part of the definition of done. A new service is not live until it is listed with an owner.
Answering the zero day question
The real test is the next widely reported library flaw. With a good inventory you search for the package name and version range, get the list of affected applications and owners, and start work within the hour. Without it, the answer comes from asking around in chat. Time yourself on a past example, such as a famous logging library flaw, and note how long it would take today. That number is your baseline for improvement.
Containers and virtual machines
Short lived workloads need special care. Inventory the image, not just the running instance, and record which base image and packages it contains. Rebuild and rescan on a schedule so a long lived image does not carry old components forever. For virtual machines, tie the record to the template or configuration code so drift is visible.
Try it yourself
The demo shows asset discovery building an inventory from connected sources.
Click through it at your own pace, or open it full screen.
To see what a dependency list looks like for one project, the free in browser scan at https://gold.safeguard.sh/scan reads a manifest and lists its packages.
Common gaps
- Only the top level dependencies are listed, so transitive packages stay invisible.
- The inventory is a spreadsheet updated at audit time.
- SaaS tools bought on a company card never appear.
- No owner, so nobody reacts when an end of life notice arrives.
Quick check
Is a list of applications enough?
Not for vulnerability response. You also need the components inside each application, otherwise you cannot tell whether a newly disclosed flaw affects you.
How current does it need to be?
Current enough that its answers are trusted during an incident. For fast changing environments that means automated collection rather than manual updates.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
