The Race to Answer 'Are We Exposed?' Is Getting Harder
A new CVE drops and the clock starts. Security teams still hop between six tools to find out if it matters. AI is making that lag more dangerous.
Key points
- A new critical vulnerability alert forces security teams to find out fast: does this affect us, and where?
- Most organisations still stitch that answer together by hand from vulnerability scanners, endpoint tools, cloud inventories, code repositories, SBOMs and source code.
- AI tools are now helping attackers find and weaponise flaws faster, shrinking the window defenders have to respond.
- The delay between a CVE (Common Vulnerabilities and Exposures ID, the standard label given to a software flaw) being published and a company knowing its own exposure is where most breaches happen.
A critical bug gets published. Within minutes, a security team's phone lights up.
Then the real work starts. Not patching, not yet. First they have to figure out whether the flaw actually touches anything they own.
That sounds simple. It isn't.
Why is it so hard to know if you're affected?
The answer lives in six different places. To confirm exposure to a single CVE, a defender typically has to check a vulnerability scanner (software that probes systems for known flaws), an endpoint tool (the agent running on laptops and servers), a cloud inventory (a list of what's running in a public data centre), an SBOM (a software bill of materials, an ingredient list of every component inside an application) and the source code repositories where developers keep the app itself.
Each of those systems speaks its own language. None of them agree on what a "host" or an "asset" is. Analysts spend hours reconciling names and owners before they can even start writing a patch ticket. As we reported on 25 August, one vendor's early-warning feature was built specifically to cut that days-long gap between a flaw going public and teams being able to scan for it.
That manual stitching is the bottleneck. Not the fix.
What changed in 2024 and 2025?
Attackers got faster. AI-assisted research is speeding up the discovery of new bugs on both sides of the fence, and exploitation windows are shrinking. Our 2 September story tracked nearly 40,000 vulnerability reports across a year of real data and found the headline numbers alarming even if the fine print was more reassuring.
The defender's timeline has not kept up. Security teams are still measuring initial triage in days. That gap is the story.
What does a faster answer actually look like?
A single view of the estate, tied to live vulnerability intelligence, so that when a CVE lands the question "are we exposed?" returns a real answer in minutes rather than a spreadsheet in three days.
That means one inventory covering cloud workloads, endpoints and their software components, with owners attached. It means feeding new CVE data straight into that inventory instead of into an analyst's inbox. The output is a prioritised list of what to fix first, not a pile of raw scanner results.
None of this is new advice. What is new is how badly the old workflow now scales.
| Stage | Typical manual approach | What breaks under pressure |
|---|---|---|
| Asset discovery | Multiple inventories, reconciled by hand | Cloud assets missed, ownership unclear |
| Vulnerability match | Scanner output cross-checked against CVE feed | Version data stale or incomplete |
| Prioritisation | Analyst judgement plus CVSS score | No business context, everything looks critical |
| Response | Ticket to the owning team | Owner unknown or wrong |
What should ordinary users take from this?
Not much directly, but this is worth knowing: when a company you deal with is slow to patch a known flaw, it's often not laziness. It's that they genuinely don't know yet whether they are affected. Push the vendors and platforms you rely on to talk publicly about their mean time to respond, not just their mean time to patch.
The teams that will do well are the ones that treat "are we exposed?" as a product question, not a project.
