It is 3:40 on a Friday afternoon. CISA has just added a vulnerability in a widely used open-source library to its Known Exploited Vulnerabilities catalog. Within the hour the CEO has forwarded a news article with one line: “Are we affected?” How long it takes to answer that question, and how confident the answer is, says more about a security programme than any maturity assessment.
In short
- “Are we affected?” is an inventory question, not a scanning question. If you have current SBOMs for every repository and image, it is a search. If you do not, it is a week of emails.
- “Where does it matter?” comes next. Twenty affected services are not twenty emergencies. Exposure, data and scope decide which three to fix tonight.
- KEV status should re-score automatically. When a vulnerability you already carry becomes known-exploited, its findings should move up the queue without anyone re-running a scan.
- The answer to the board needs evidence. “We checked” is not an answer. “Three internet-facing services, all patched by Sunday, here is the list” is.
The situation
This scenario is illustrative, but the pattern is a familiar one. The CISA KEV catalog lists vulnerabilities with reliable evidence of active exploitation. US federal civilian agencies must remediate entries by a due date under Binding Operational Directive 22-01, typically within weeks of the listing, and most private-sector programmes now treat KEV as their own fix-first list. When a new entry lands in a library that is everywhere, three questions arrive in quick succession:
- Do we run it? Which repositories, images and running services contain an affected version, including as a transitive dependency nobody chose directly?
- Where does it matter? Which of those are internet-facing, handle regulated data, or sit on an attack path to something sensitive?
- When will it be gone? Who owns each affected service, what is the deadline, and how will we know it is actually fixed?
data
When Log4Shell was disclosed in December 2021, many organisations spent days or weeks just establishing where Log4j ran. The US Cyber Safety Review Board later described it as an “endemic” vulnerability that would remain in systems for years, and pointed to software inventory as a core weakness. The KEV catalog has since grown to well over a thousand entries.
Sources: Cyber Safety Review Board, Review of the December 2021 Log4j Event (July 2022); CISA Binding Operational Directive 22-01 and the Known Exploited Vulnerabilities catalog.
Why this takes days in most organisations
Most organisations have the raw material to answer the first question. They have scanners on many repositories and some container images. What they lack is a single place where all of that is current and searchable.
- Inventory is scattered. Dependency results sit in one tool, container results in another, and some teams’ repositories are not scanned at all.
- Transitive dependencies hide. The affected library is rarely in the manifest a developer wrote. It is three levels down, pulled in by a framework.
- Severity does not change, so nothing moves. The vulnerability may have been in the backlog for months as one more High. KEV listing does not change its CVSS score, so a severity-sorted backlog does not reorder itself.
- Exposure is tribal knowledge. Which of the affected services face the internet is known to the platform team, not to the scanner.
Security posts the CVE in a channel and asks every team lead to check. Answers arrive over three days, in different formats, with “I think so” in several of them. The board update says “investigation ongoing”.
Search the CVE or the package across every SBOM. Every affected repository and image is listed with its exposure, data class, owner, score and SLA due date. The board update has a number and a deadline.
The response, step by step
Steps 1 and 2 happen without anyone asking. The intel sync runs every six hours by default and can be triggered on demand.
1. KEV status moves the queue on its own
InsightFortify synchronises the CISA KEV catalog, FIRST’s EPSS scores and OSV advisories into its own vulnerability store, every six hours by default or on demand. When a vulnerability’s KEV status or EPSS score changes, only the findings that carry it are re-scored. A vulnerability that was a medium-priority finding yesterday picks up the “Exploited in the wild” factor, worth +2.0, and in most cases moves to P1 with a seven-day SLA. Nobody has to re-run a scan for that to happen.
2. “Do we run it?” is a search
Every repository scan and image scan produces a CycloneDX SBOM, and every component in it is indexed. Typing the CVE identifier into the console’s search filters the findings queue to every finding that carries it, across all repositories and images, highest score first. The Vulnerabilities page, filtered to known-exploited, opens the CVE with the same list. The Components page answers the package question: every version in use, including transitive ones, even where the scanner’s database has not yet matched the new advisory.
3. “Where does it matter?” is the sort order
The list is not alphabetical. It is ordered by score, and the score already includes the context the platform and data owners set on each repository and image: internet exposure, data classes, business criticality, compensating controls, and whether the dependency is dev-only. A known-exploited vulnerability in an internet-facing payments service sits at the top. The same vulnerability in a dev-only build tool sits much lower, still listed and still on an SLA, but not tonight’s job.
4. “When will it be gone?” is the SLA view
Every P1 carries a due date, seven days by default. Teams fix through their normal pipeline. When the next CI upload or scheduled scan no longer contains the vulnerable version, the finding closes itself, with the scan that proved it. The dashboard’s count of open known-exploited findings and the overdue count are the two numbers to watch until both reach zero.
If the scheduled sync has not run since the listing, trigger it so KEV status and re-scoring are current.
The findings search and the CVE’s vulnerability page show matched findings. The Components search catches versions the advisory database has not matched yet.
Which repositories and images have no recent SBOM? Those are the honest “unknown” in the answer. Schedule scans for them now.
Report the number affected, how many are internet-facing or handle regulated data, and the plan and deadline. Avoid “we are not affected” unless coverage is complete.
Assign each P1 to the service owner and record the ticket link on the finding, so status lives in one place.
If no patched version exists, record the compensating control, such as a WAF rule or disabled feature, so the score reflects it, and keep the finding open.
Fixed versions close findings on the next scan. Track open KEV findings and overdue items until both are zero.
The flow, in one picture
re-score affected findings"] S --> Q{"In any SBOM?"} Q -->|"No, coverage complete"| N["Not affected
record the evidence"] Q -->|"No, coverage gaps"| G["Scan the unscanned
then search again"] Q -->|"Yes"| X["Sort by score
exposure, data, scope"] X --> P1["P1: internet-facing or sensitive
fix within 7 days"] X --> P3["Lower: internal or dev-only
fix on the normal SLA"] P1 --> V["Next scan proves the fix"] P3 --> V style P1 fill:#fee2e2,stroke:#ef4444 style N fill:#ccfbf1,stroke:#0d9488
An illustrative timeline
Below is what the first weekend can look like when the inventory is in place. The times are illustrative, not a benchmark. The point is the shape: the slow parts are the engineering changes, not the finding out.
| When | What happens | Who |
|---|---|---|
| Fri 15:40 | KEV listing published; news coverage starts | — |
| Fri 15:55 | Intel sync triggered; affected findings re-scored, most to P1 | Security analyst |
| Fri 16:10 | Findings search and Components search run; coverage gaps listed | Security analyst |
| Fri 16:30 | CISO replies to the CEO: number affected, how many internet-facing, plan and deadline | CISO |
| Fri 17:00 | P1s assigned to service owners, ticket links recorded on the findings | Security analyst |
| Sat–Sun | Internet-facing services upgraded and redeployed; CI uploads close findings as they land | Service teams |
| Mon 09:00 | Status from the queue: fixed, in progress, mitigated, unscanned gaps closed | Security lead |
| Within SLA | Remaining internal and lower-priority instances fixed on the normal schedule | Service teams |
Two things make that timeline possible, and neither is heroics. The first is that the inventory already existed before Friday, because every repository and image was being scanned on every change. The second is that the context already existed: someone had marked which services face the internet and which handle payment data months earlier, when nothing was urgent. Programmes that try to build either during the incident lose the weekend to spreadsheets.
It is also worth writing down, afterwards, how long each step actually took. Those two durations, time to know and time to fix the exposed instances, are the most honest measure of readiness you will get, and they are exactly what a board or regulator will ask about after the next one.
What it means for each audience
For the CISO
The difference between “investigating” and “three services, fixed by Sunday” is the difference between a security function that reacts and one that is in control. Boards notice which one they are dealing with.
Be honest about coverage. An answer that names the repositories not yet scanned is more credible than a confident “not affected”.
For the AppSec lead
No spreadsheet, no channel roll-call. The SBOM search and the score order replace the first day of manual work, and closure is verified by scans rather than by status updates.
Make sure every deployable image has an SBOM. The search is only as complete as the inventory behind it.
For the board
Ask two questions after any major vulnerability: how long did it take us to know whether we were affected, and how long did it take to fix the exposed instances? Both should be measured in hours and days, not weeks.
These are also the facts a disclosure decision depends on.
Outcome metrics to track
Pitfalls
- Declaring “not affected” on partial coverage. A search over 80% of your estate proves nothing about the other 20%. Name the gaps.
- Forgetting what is running. A repository SBOM tells you what the code depends on today. An old image still deployed in production may carry an older version. Scan registered images too.
- Panic-patching everything. The score order exists so that the internet-facing, sensitive services are fixed first and the rest follow on their normal SLA without a fire drill.
- No fix available. If the maintainers have not shipped a patch, InsightFortify marks the finding “No fix published”. Mitigate, record the control, and keep it visible.
“Are we affected?” should take a search, not a week.
Keep a current SBOM for everything you deploy, let exploitation data re-order the queue automatically, and answer the board with a number, a list and a deadline.