In the first hour, confirm the finding is real, scope which products use the component, check whether it is known to be exploited, choose a fix path, and tell the owners. Do not start by patching. Start by knowing what you have and how exposed it is.
Minutes 0 to 10: confirm
Read the advisory itself, not only the platform's summary. Check that the version you run falls in the affected range, and that the package name matches. Many alerts are false matches caused by name collisions or by distribution patches that keep an old version number.
Ask: is the vulnerable function reachable from our code? Reachability analysis can answer that quickly, and it changes urgency.
Minutes 10 to 25: scope
Use your inventory to list every product, service, and image that contains the component, including through transitive dependencies. This is where a single shared inventory pays off. Without one, you ask each team by chat and wait.
| Question | Where the answer comes from |
|---|---|
| Which repos include it? | Dependency inventory |
| Which images contain it? | Image scan or SBOM |
| Which are internet facing? | Asset records |
| Who owns each? | Ownership mapping |
Minutes 25 to 35: rank by exploitation
Check the CISA Known Exploited Vulnerabilities catalog, which CISA calls an authoritative source of vulnerabilities exploited in the wild and recommends as an input to prioritization. Then check the EPSS probability, which FIRST describes as an estimate that a published CVE will be exploited in the next 30 days. Known exploited plus internet facing means treat as an incident. Neither signal means a normal sprint ticket.
Minutes 35 to 50: choose a fix path
- Upgrade. Is there a fixed version, and is the jump safe? A fix pull request helps here.
- Mitigate. Can you disable the feature, add a filter, or block a route while the upgrade is tested?
- Replace. If the project is abandoned, start a replacement plan and mitigate in the meantime.
- Accept briefly. Only with a documented exception and expiry.
Pick one owner per product. Write the plan in the ticket in two lines.
Minutes 50 to 60: communicate
Send one message to owners and the security lead: what it is, which products are affected, how exposed, the plan, and the next update time. Plain words, no jargon. Then update at the time you promised, even if nothing changed.
After the hour
Verify the fix shipped by rescanning the built artifact, not by trusting the ticket status. Record the timeline for your next review, noting which step was slowest. Slow scoping points to inventory gaps. Slow fixing points to test or ownership gaps.
A worked example
Take a hypothetical Tuesday morning. The platform flags a critical advisory in a widely used HTTP library. The on-call engineer starts a timer and follows the runbook.
At minute five she opens the advisory and confirms the library name and affected range. Her service runs a version in the range. She asks the platform whether the vulnerable function is reachable. It shows a call path from a public request handler. That raises the urgency.
At minute fifteen she queries the inventory. Seven services include the library, two directly and five through a parent package. Three are internet facing. She opens a parent ticket and lists the owners.
At minute thirty she checks the CISA Known Exploited Vulnerabilities catalog and the EPSS value. The flaw is not yet in the catalog, but its probability has risen compared with the previous day. She classifies it as urgent, not an incident.
At minute forty she picks paths. A fixed release exists. For the three internet facing services she proposes an upgrade, and for the rest a normal sprint ticket. One service cannot upgrade without a framework change, so she adds a temporary web server rule to block the vulnerable path and records a short exception.
At minute fifty she sends one message with the summary, the plan, and the time of the next update. She sets a reminder to rescan after the fixes ship.
A message template
Use plain, short text.
| Part | Example wording |
|---|---|
| What | A critical flaw was found in a library we use |
| Where | Seven services, three internet facing |
| Risk | Reachable in two services, not known exploited yet |
| Plan | Upgrade the three exposed services today, others this sprint |
| Owners | Named people per service |
| Next update | Time and channel |
Decisions that should be made before the day comes
- Who is on call for supply chain issues, and who is their backup.
- Which level of finding triggers this runbook.
- Who may approve an emergency change, and how.
- Where parent tickets and updates are posted.
- How mitigations are recorded and removed.
Decide these in a calm week. Nobody wants to invent them at minute thirty.
After action review
Within a week, hold a thirty minute review. Ask which step took longest. If scoping took the longest, improve your inventory. If fix approval took the longest, set an emergency change path. If communication confused people, adjust the template. Write one improvement and an owner, and check it next time.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the fix version and the proposed change appear next to the finding.
Safeguard combines SBOM and dependency scanning, reachability analysis, and autonomous remediation with fix pull requests, which are off by default with every category on Manual. A free scan at gold.safeguard.sh/scan shows your current exposure.
Quick check
Should we patch immediately?
Confirm and scope first. Patching blind can break production, and you may find the code is not reachable.
What if there is no fix?
Mitigate, then record a time limited exception and watch for a release.
What if we cannot tell whether the code is reachable?
Treat it as reachable until an owner shows otherwise, and prioritize by exposure and exploitation data.
Sources
Last reviewed: 19 October 2026.
