A new zero-day is announced: how does it move through SCA, ASPM and VM?

SCA answers whether you ship the affected component, ASPM maps each hit to an application and owner, and the vulnerability management process sets the deadline and tracks the fix. The first useful output is a short list of affected, exposed services within hours, not a perfect analysis.

Hour zero: is it real and is it ours?

Start with the advisory. Confirm the affected product and versions from the vendor or a maintainer, not from social posts. Then query your inventory.

This is where stored SBOMs earn their keep. If you keep one per deployed release, you can search by package and version in minutes instead of scanning every repository from scratch. OWASP's guidance on vulnerable and outdated components advises continuously inventorying component versions, and this scenario shows why.

The three layers in sequence

SCA: find hits. Match the new advisory against every inventory. Output: a list of applications and builds containing the affected version, direct or transitive.

ASPM: add context. For each hit, attach the owning team, whether the service is internet facing, what data it handles and whether the vulnerable code path is reachable. Output: a ranked list.

VM process: set the clock. Check whether the vulnerability appears in the CISA Known Exploited Vulnerabilities catalog. If it does, use your shortest deadline. Check EPSS, which publishes a daily probability for every CVE, though a very new CVE may have little history. Output: deadlines and owners.

A first day checklist

1. Name an incident lead and a channel.
2. Confirm affected versions from a primary source.
3. Search inventories and list affected applications.
4. Rank by exposure and reachability.
5. Decide an interim mitigation for the top items, such as a configuration change, a block at the edge, or disabling a feature.
6. Open tickets with owners and deadlines.
7. Write a short status note for leadership and for customers if relevant.
8. Schedule a rescan after each fix.

What to communicate

Keep notes factual. State what is known, what is not, and when you will update. Do not claim you are unaffected until you have checked every inventory, including images in registries and software you distribute to customers. Legal and notification questions go to your counsel, not to a blog.

Common failure points

• No inventory. The team cannot answer "do we use it?" for days.
• Transitive blind spots. The component is three levels deep and the manifest scan missed it.
• Mitigation without owner. A workaround is agreed but nobody applies it.
• No rescan. The fix ships but nobody confirms it.

After the dust settles

Hold a short review. How long did it take to know whether you were affected? Which inventory was missing? Which handoff was slow? Fix those, since the next advisory will arrive without warning.

A worked example

Suppose an advisory appears for a widely used web framework component. You run 20 services. Here is a plausible first day, with illustrative timing.

• Hour 0 to 1. The AppSec engineer reads the maintainer advisory and records the affected versions. An incident channel opens.
• Hour 1 to 2. A search across stored SBOMs lists 6 services with an affected version. Two are direct dependencies, four transitive.
• Hour 2 to 3. Context is added. Three services are internet facing. Reachability shows the vulnerable handler is enabled in two of them.
• Hour 3 to 4. The CVE is not yet in the KEV catalog and EPSS history is thin, so the team ranks by exposure and reachability. Two services go to the top.
• Hour 4 to 6. For those two, an interim mitigation is applied at the edge. Tickets are opened for all 6 services with deadlines.
• Day 1 close. A short status note goes to leadership. A watch is set on the KEV catalog and EPSS for the CVE.

By the end of the day, you know where you are exposed and who is doing what.

Step by step: build a zero-day playbook

1. Define a trigger. For example, an advisory for a component in your inventory, or a KEV addition that matches it.
2. Name roles. Incident lead, analyst, communicator, service owners.
3. Define the search procedure. Where SBOMs live and how to query them by package and version.
4. Define ranking inputs. Exposure, reachability, KEV, EPSS, data sensitivity.
5. Define mitigations menu. Configuration switch, edge rule, isolation.
6. Define communication. Who is told, when, and what is said.
7. Define closure. Rescan, record, and short review.

Rehearse it once with a past advisory. Gaps appear quickly.

What changes in the following days

Common questions during the event

• Do we tell customers? Decide with counsel and your contracts. This post is not legal advice.
• Do we patch before we are sure? Apply low risk mitigations early, schedule the fix, and verify.
• What if the vendor has no fix? Isolate, monitor and consider replacement.

Keep notes in a timeline as you go. They make the review and any customer questions much easier to answer later.

Try it yourself

Watch how a new disclosure is matched against an existing inventory.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard offers zero-day discovery, SBOM and dependency scanning, and reachability analysis, which line up with the find, rank and verify steps above. A free scan is at gold.safeguard.sh/scan.

Quick check

Sources

• OWASP Top 10:2021, A06 Vulnerable and Outdated Components
• CISA Known Exploited Vulnerabilities Catalog
• FIRST, EPSS

Last reviewed: 19 October 2026.