Finding is faster. The gap before fixing matters more.

Last week we wrote about PHP2Shell and node2shell landing in the same week, flaws that had sat in widely deployed code until AI-assisted research surfaced them. In PHP’s case, they had been there for more than a decade (Wiz). The day after our post, a16z published a survey of 100 CISOs at companies with more than 1,000 employees on their priorities for 2027.

Read together, they describe one problem from two sides. Finding vulnerabilities is getting faster. Fixing them still takes review, testing and deployment. Protection has to work during that time, not only after the patch ships.

The attack side got faster

Three things moved at once.

Volume. CVE submissions grew by 263% from 2020 to 2025 (NIST). AI-assisted research is also surfacing longstanding flaws in software that runs much of the internet, as the PHP findings show.

Speed. Bain estimates that AI compresses a typical attack sequence from roughly four weeks to about eighteen hours (Bain). In that estimate, reconnaissance drops from a week to about an hour, and lateral movement from a week to about three hours. These are estimates of attack duration, not a deadline measured from vulnerability disclosure.

Autonomy. This summer, agents in an OpenAI security evaluation chained vulnerabilities and stolen credentials to reach another company’s production systems on their own (OpenAI, and our analysis). An evaluation goal pursued beyond its boundaries, without a human attacker directing the intrusion.

Shorter attack cycles make it harder to rely on a patch window measured in weeks.

The fix side has a floor

A fintech CISO in the a16z survey put it plainly: “With a lot of these AI tools, you’re able to find vulnerabilities faster, but you’re not able to patch faster.”

A fix is not one action. It is a sequence of human steps. Find the owner. Work out what to change, and what that change breaks. Build it, test it, push it through the release pipeline without taking production down. Then confirm it actually closed the exposure. In the survey, 70% of CISOs want to retest and verify that their vulnerabilities have been fixed.

AI and better workflows can shorten the release cycle. They do not eliminate the need to establish that a change is safe. Protection cannot depend on every patch arriving before exploitation. Without more capacity to resolve findings, faster discovery adds to the backlog: Bain reports vulnerability alerts rising by as much as eightfold at large companies that put frontier AI to work on defence.

What happens before the fix ships

Counting critical findings is not enough. For each one, ask: is it exploitable in our environment, what impact could it have, and what protection is in place until the fix ships? Time exposed matters, alongside impact and how vulnerabilities can be chained.

Two levers matter here: reduce the list that needs urgent attention, and constrain what exploitation can achieve while the remaining fixes are prepared.

Shortening the list

In the survey, 67% of CISOs want to prioritise remediation using validated exploitability. A CVSS score alone does not establish that. Exploitability depends on the workload, its configuration and the protection in place.

Does the process load the vulnerable code at all? If an exploit lands, does the path it needs exist in how the service actually behaves: spawning a shell, writing and executing a file, opening an outbound connection?

bifrost combines runtime behaviour with the SBOM, CVE information and deployment context to assess each vulnerability. Those assessments produce three verdicts, scoped to the workload and its current context:

• Reachable. The assessed exploit path remains available within the workload’s permitted behaviour. This is the patch list, and it has an order. Where the exploit’s effect is indistinguishable from what the service does anyway, patch first. Where the exploit lands but escalation and persistence still fall outside the profile, the enforced profile holds those steps back while the patch is prepared.

• Mitigated by the profile. The vulnerable code is present, but the assessed exploit path requires an operation the profile denies. In enforce mode, the kernel blocks that operation.

• Never loaded. The package is in the image, but the assessment establishes that the vulnerable code is not loaded in this workload. A short period without observing it is not enough on its own.

With bifrost, teams have up to 90% fewer CVEs to triage. The reduction comes from assessing each finding against its workload context and protection, not from sorting alone. We will go through the mechanics of assessing a CVE in the next post.

Protection while the fix is prepared

The second lever is constraining operations an exploit would need while you patch: a default-deny profile at the container, built from workload behaviour and bifrost’s evaluation of it, then applied in enforce mode.

Consider a php-fpm workload whose assessed behaviour requires no shell execution, executable-file creation or access to the cluster’s service account token. Its tailored profile denies those operations. In enforce mode, the kernel refuses an attempt to execute /bin/sh, create an executable file or read that token, even if the process has been exploited.

The vulnerability still needs a patch, and any impact possible through the service’s permitted behaviour remains a priority. The PHP findings include disclosure of sensitive process memory without remote code execution. Blocking a shell or a token-file read does not, by itself, stop that disclosure.

The value is specific: operations outside the enforced profile stay unavailable while the team prepares the fix. Patch urgency follows the remaining exposure, rather than an assumption that every blocked escalation makes the vulnerability safe to defer.

A scan identifies vulnerable components. Runtime context establishes which findings matter in the deployment, and enforcement constrains operations while the fix is prepared. These are complementary jobs. Runtime enforcement sits alongside the scanner, not instead of it.

Where this sits

We describe the path as a maturity ladder: inventory, then context, then runtime. Inventory tells you what is present. Context narrows the list that needs attention. In enforce mode, the tailored profile constrains what exploitation can achieve.

Finding faster is progress. The next step is to reduce what needs urgent attention and constrain what exploitation can achieve while the fix is prepared.

Start with one workload in observe mode to gather behaviour for an assessment. Nothing is blocked in observe mode; your team decides when to move to enforce. Book a demo to see how that assessment works for your workloads.