An advisory names a software library and a range of affected versions. Your team has several releases in service, and the library name appears in a dependency file. What can you conclude? The name tells you where to start. To decide what to do, you still need to know which builds are deployed, what they contain, what the advisory covers and how the product uses the component.
A software bill of materials, or SBOM, helps with the inventory part of that work. Think of it as a record for a specific artifact, such as a release package or container image. It can connect components to identifiers and versions and show how some dependencies enter the product. A vulnerability statement can provide additional context for a particular product and issue. The useful result is a decision you can explain and revisit when an artifact, an advisory or the available evidence changes.
Identify the release you actually run
Start with the product and the deployment, rather than the component name. Record the environment, release identifier and immutable artifact identifier when available. A repository's default branch may have moved since your copy was built. A tag in a deployment screen can also be ambiguous if it was reused. Link your investigation to the image digest or package checksum you observed. If you cannot tie the deployment to an artifact, record that gap before relying on any inventory.
Consider a fictional service called Lantern Desk. Its primary environment runs release 4.7, and a maintenance environment still runs 4.6. The two use images with different digests. A dependency inventory attached to 4.7 may be accurate for that release and still tell you little about 4.6. Keep separate rows for the two deployments even if they share a product name. This prevents evidence collected for one release from quietly clearing the other.
CISA's SBOM minimum elements guidance discusses issuing an inventory for each software version or update and making gaps in coverage explicit. For an investigation, ask who produced the document, when it was generated and what it describes. An inventory prepared from a source checkout answers a different question from one prepared against a distributed image. Both can be informative when their scope is clear.
Resolve the component identity before comparing versions
Short component names can collide across ecosystems or vendors. Where you have them, compare the supplier, ecosystem, namespace, package identifier and version with the exact advisory. If an identifier is absent, go back to the underlying package metadata or vendor record. Keep any unresolved match visible. A spreadsheet that silently turns a close name into a definite match makes the next decision harder to defend.
Next, read the affected range and the conditions attached to it. Does the advisory include the version on your system? Does it refer to a specific module, platform or build? A distribution can apply a security fix without adopting the version number used by the upstream project. A supplier advisory tied to the actual package build can clarify that case. Retain the upstream and distribution references separately so another person can see which version scheme each uses.
For Lantern Desk, imagine the issue concerns a parser named SlateReader in versions 2.1 through 2.3 under specified conditions. The 4.7 inventory lists version 2.4 under the same package identity, while 4.6 lists version 2.2. That comparison can help narrow the investigation. It does not prove that 4.7 has no other copy, or that every use of 2.2 reaches the affected code. The names, versions and scenario here are invented to illustrate the method.
Follow the path into the shipped product
A dependency may arrive through another package. Trace that relationship before deciding how to remove or update it. If Lantern Desk depends on an import tool and the import tool depends on SlateReader, the team may need a new version of the import tool. Installing a newer parser alongside the old one may leave the old copy in use. Look for multiple copies and record the paths by which they entered the artifact.
Distinguish a component used to build the software from one included in the distribution. A build-stage tool can have security consequences for the build environment even when it is absent from the running service. Conversely, an inventory taken only from source manifests can miss a copy bundled into the installed artifact. Check what was actually shipped. If the build pipeline and the deployed product are separate subjects, open separate investigation records for them.
CISA's guidance discusses transitive dependencies and asks SBOM authors to identify known gaps. For readers, that means an empty search result needs context. The component may truly be absent, the inventory may omit a part of the product, or the search may have used a name that differs from the one recorded. An inventory with an explained boundary helps you decide where to gather more evidence.
Read a vulnerability statement against your exact product
A Vulnerability Exploitability eXchange statement, often shortened to VEX, can describe how a particular vulnerability relates to a product. Check who issued it and which product, versions and issue it covers. Also look for updates or a more recent statement. A supplier's conclusion about its standard build may have a different scope from your customised distribution. A statement about release 4.7 cannot close the question for release 4.6 by association.
CISA's VEX minimum requirements describe statuses that distinguish affected products, products with fixes, products assessed as not affected, and products still under investigation. Read the explanation that accompanies the status. A component could be absent from the distribution, or the particular vulnerable code could be excluded at build time. Those are distinct claims. Each needs different evidence if it is to support a decision about your deployment.
A vendor may establish that its standard product never calls a vulnerable routine. Before extending that finding to your own deployment, check whether you added plugins, changed supported features or built from different source. If your environment matches, keep a copy of the evidence and the limits of the claim. If you cannot establish that match, keep the applicability question open and ask whoever can confirm the build or configuration. CISA's SBOM FAQ discusses how product-specific statements can add context to component records.
Separate observations from decisions
Return to Lantern Desk. For the maintenance environment, the current inventory says that SlateReader 2.2 appears under the import tool. The team also finds evidence of a copy in the distributed image. Those observations strengthen the case that the component is present. The remaining question is whether the affected feature can operate under the advisory's conditions. An assumption that nobody uses an importer is different from checking whether it is reachable or enabled.
Suppose the supplier's 4.6 statement still says under investigation. The team can record the potential exposure, assign someone to check the affected conditions and start preparing an update in parallel. It can also decide whether a temporary restriction is appropriate under its own incident process. If a restriction is made, document what it changes, how it was verified and when it will be removed. Keep the investigation open while the evidence is incomplete.
Now suppose the team confirms that the configuration for its own 4.7 build excludes the relevant module and records the digest and build evidence. That finding belongs to the 4.7 row. It does not go into the 4.6 row unless somebody establishes the same fact there. Keeping the two decisions separate makes it possible for another engineer to pick up the record without reconstructing the whole incident from chat.
Work out what to verify after an update
Choose a target artifact using the relevant supplier or maintainer information. When the new build is ready, record what changed in the component inventory and whether a second copy remains through another dependency. Keep the initial evidence so you can explain the difference. If the import tool was updated, look at its resolved dependencies and the shipped distribution. A changed manifest alone cannot show that the deployed image changed.
During rollout, check the artifact actually running in each environment. A scheduled job, a standby instance or a separately maintained customer release can be missed if you only inspect the main service. Verify that the updated feature still behaves as expected and retain the version-specific results with the deployment record. If rollout must pause, list the deployments that still run the earlier build. A patch becoming available, a new image being built and a live instance receiving the image are three separate events.
For the example, if maintenance release 4.6 is replaced with an image that carries the new import tool and only SlateReader 2.4, the team can record the new digest and the inventory observation. It can then test a representative import and verify that the intended maintenance instances have been replaced. If one remains on the earlier image, that instance stays on the follow-up list until it is handled.
Leave a record a second person can use
A useful decision record can fit on one screen per release. Give it the advisory reference and revision date, product and environment, artifact identity, inventory author and timestamp, matched component identity and version, evidence of presence or absence, relevant product statement, decision, responsible person and follow-up time. Where information is incomplete, say what is missing and what source can resolve it. Use links to internal evidence that the intended reviewers can actually open.
If the issue is being tracked for multiple environments, keep a summary that points back to the separate records. Use status labels that reflect what you know. One deployment may have an update verified, one may have a documented reason the advisory does not apply, and another may still be waiting for build evidence. A single company-wide label hides those differences. If a decision is later revised, preserve its earlier evidence and record what changed your conclusion.
Before closing the record, ask a colleague to read it without the original conversation. Can they identify the running artifact and the exact advisory? Can they tell why your conclusion applies to that release? Do they know what would require another review? An evidence gap revealed by these questions is easier to address while the people and build records are still available.
Keep the record current when an advisory changes
An advisory can change after the first notice. A maintainer might narrow the affected range, add a previously omitted platform, or describe a mitigation that was unavailable on the first day. Capture when you read the advisory and which revision you used. In a shared record, avoid copying a conclusion without its date. The team can then distinguish a decision that was sound on the available evidence from one that needs to be revisited today.
Set a trigger for review. An investigation can reopen when the supplier publishes a new statement, a product team changes the deployment or an inventory generator learns to see a previously invisible class of dependency. Assign a person to watch for the trigger and make the next review date explicit. When a decision changes, add the new evidence alongside the earlier reasoning. That history helps another team decide whether its own record also needs attention.
Decide what the next person should do
Start by finding the artifact that is running. Compare the advisory with the inventory for that artifact, then check the shipped component and the conditions under which the issue applies. Use product-specific statements to sharpen the decision. If the record remains uncertain, name the open question and assign the next check. If a new build is needed, verify it in the places that were actually running the earlier one.
The inventory earns its place in incident response by helping a team get from an advisory to a traceable action. Its strongest result is a release-specific record that another person can confirm, challenge or update as new evidence arrives.
The same habit helps outside software: compare claims with the underlying evidence before treating an announcement as a verified outcome.
Sources and research note
Sources checked November 3, 2026. The article uses CISA guidance for the purposes of component inventories and product-specific vulnerability statements. Lantern Desk and SlateReader are fictional. The conceptual examples describe an investigation workflow and do not report a real vulnerability.