Insight
A CVE Is Not an Answer to "Are We Affected?"
When a serious CVE lands, "do we use it?" is the first question. It isn't the answer a CTO, customer or board needs. The questions that follow decide what you patch first.
When a serious CVE lands, the first question is usually:
“Do we use it?”
It’s a necessary question, but the answer isn’t what the CTO, a customer or the board actually needs.
The questions that follow
As soon as the answer is “yes, somewhere”, harder questions arrive:
- Where does it run? Which hosts, containers, functions and accounts?
- Is that service reachable from the internet? Directly, or through a load balancer, a proxy or a forgotten port forward?
- What could an attacker reach from there? Which networks, databases, credentials and roles does that workload hold?
- Who can change the route, rule or configuration that matters? And are they awake?
Each of those has a different source of truth. For a growing company the answers sit across cloud accounts, firewall rules, identity settings, container images and the knowledge of several people.
That’s why a vulnerability response can turn into days of checking, even when the team knows the software well.
Separate the two questions
A useful habit is to split the response into two questions:
- Is the affected software present? That’s an inventory question. You answer it from package lists, lockfiles, image metadata and, where those fall short, by asking the running systems.
- If it is, what is the real exposure around it? That’s a reachability question. You answer it from network paths, identity and what each workload can touch.
The first question tells you how much work there is. The second tells you the order to do it in.
A vulnerable library inside a batch job with no inbound route and read-only access to one bucket is real, but it can wait. The same library behind a public load balancer, running as a role that can read production secrets, can’t.
What good looks like
A team that handles this well can usually answer within an hour:
- every place the affected software runs, with versions
- which of those are reachable from outside, and how
- what each of those could reach next
- who owns each one
None of that needs a new process. It needs the answers to be joined up before the CVE arrives, rather than assembled by hand after it.