Your security attestation expires when the exploit begins

A clean annual security attestation can become commercially irrelevant the moment a serious vulnerability appears. It may indicate that controls existed when an assessment was completed. It cannot tell a buyer whether the supplier can find an exposed system, contain the danger and restore confidence before an attacker acts. When exploitation accelerates, that operational gap matters more than the date on a certificate.

Software buyers should therefore contract for risk-adjusted remediation latency. The 22 October edition of The AI Daily Brief reported that knowledge of a PHP exploit spread roughly ten hours ahead of disclosure, before organisations could patch. It also reported that Cloudflare saw thousands of exploit attempts before the announcement, tens of thousands shortly afterwards and millions later. Those are attributed claims from the episode, not independent verification of the incident or its causes. Their commercial significance lies in the possibility they illustrate: a supplier’s response process may be overtaken before its formal communications process has finished.

Patch management already has a broader meaning than installing an update. The United States National Institute of Standards and Technology defines enterprise patch management as identifying, prioritising, acquiring, installing and verifying patches, updates and upgrades throughout an organisation. That sequence exposes the weakness in a contractual promise merely to apply critical patches promptly. A patch cannot protect an asset the supplier has not identified, and installation is not the same as verified recovery.

Prioritisation also needs better inputs than a severity label alone. The United States Cybersecurity and Infrastructure Security Agency describes its Known Exploited Vulnerabilities catalogue as an authoritative source of vulnerabilities exploited in the wild and recommends using it as an input to prioritisation. The Exploit Prediction Scoring System estimates the probability that a published vulnerability will be exploited in the wild within the next 30 days. These sources answer different questions: one records observed exploitation, while the other estimates near-term likelihood. A sensible contract can use both without pretending either removes the need to consider internet exposure, data sensitivity and operational consequence.

Risk-adjusted remediation latency is the elapsed time between a credible warning and a verified reduction in customer risk. The clock should start from an agreed trigger, such as a vendor advisory, confirmed supplier discovery or addition to a recognised exploitation catalogue. It should not wait for the supplier to finish an internal classification exercise. For a vulnerability already being exploited, the first obligation may be containment rather than a permanent repair. For a high-probability vulnerability affecting an internet-facing service, the deadline should be tighter than for an inaccessible component with no practical path to exploitation.

The measure must follow the service boundary. A hosted provider controls deployment and should report when affected assets were found, when exposure was mitigated and when the repair was verified. A software vendor that cannot deploy into the customer’s environment should instead be accountable for diagnosis, workable mitigation, patch availability and accurate deployment guidance. Buyers retain responsibility for the actions they control. Calling everything shared responsibility merely obscures who owns each hour of delay.

Procurement teams should test this capability before signature. Ask the supplier to reconstruct its response to a previous serious vulnerability using timestamps, affected asset counts, mitigation decisions and verification records. If the supplier cannot produce that history, a contractual deadline may amount to theatre. Evidence should arrive in a form that lets the customer distinguish investigation, containment, patch deployment and confirmation. A dashboard showing that a ticket is in progress proves little about residual exposure.

Contractual consequences should reflect business harm rather than reward polished reporting. Service credits may be appropriate for a modest miss, but repeated failures on exploited vulnerabilities should support stronger remedies, including termination assistance and data portability. The buyer should also examine its own contribution to delay. If customer approval, a frozen release window or an undocumented integration blocks remediation, the contract should record that dependency instead of assigning every lost hour to the supplier.

Consider a hypothetical choice between two suppliers with equivalent annual attestations. In this scenario, one can identify affected customer assets immediately, apply a safe containment measure and provide evidence of recovery. The other begins with a manual asset search and cannot explain which customers remain exposed. The attestations look equal, but the commercial risks do not. Risk-adjusted remediation latency makes that difference visible before an incident forces the buyer to discover it.

If AI materially shortens the path from vulnerability discovery to exploitation, suppliers with disciplined asset knowledge and governed response automation will become more valuable. If that acceleration fails to materialise, faster verified remediation still reduces the period in which a known weakness remains open. Either way, buyers should stop treating last year’s attestation as the final word on next hour’s risk.