How frontier AI is rewriting software security rules

For decades, software security rested on two primary assumptions: Finding and exploiting vulnerabilities required rare expertise, and defenders had time to assess the severity of and fix what they found. With the emergence of frontier AI, those assumptions are no longer valid. Flaws can now often be found at a scale and pace no security, development, or infrastructure team was built to absorb, and attackers can usually exploit them faster than most organizations can patch. As evidenced by the recent discovery of the flaw in the PHP programming language and its packages,¹ the binding constraint has shifted from finding vulnerabilities to fixing them, and to changing software so that the same flaws do not return.

Many private- and public-sector actors agree that defense must alter its approach. What most technology leaders lack is a clear way forward—a practical, comprehensive program that can keep up with the unprecedented discovery capabilities of frontier AI. Speed by itself is not enough to handle the job; effective security organizations have shown that it requires moving four key levers in concert: cyber practices, the operating model, the risk and control framework, and technology. Based on our extensive work with chief information officers (CIOs), chief technology officers (CTOs), and chief information security officers (CISOs) at these organizations, this article lays out why a new type of approach to software security is necessary, the four levers essential for that response, and how to begin to put those levers into place.

The shifting software security landscape

Frontier models can now read software—its configuration and code—with a security mindset, to produce working exploits or simply deploy armies of agents to find and exploit vulnerabilities, and the capability may be spreading, including to open-weight models. After Anthropic launched Project Glasswing in April 2026, it reported in May that its partners had found more than 10,000 high- or critical-severity vulnerabilities using Claude Mythos Preview; several partners said that their rate of bug-finding had increased more than tenfold.² Among the findings were a 20-year-old Firefox bug revealed by Mozilla and a 27-year-old OpenBSD flaw reported by Anthropic.³

The effect is visible across the public software ecosystem. For instance, the number of common vulnerabilities and exposures (CVEs) fixed per Linux kernel release rose from roughly 500 across versions 6.9 to 6.19, to more than 1,000 from version 7.0, according to figures shared by a kernel maintainer.⁴ In April, HackerOne reported that vulnerability submissions on its platform rose 76 percent year over year, with the share of valid findings holding steady.⁵

In October, two critical PHP vulnerabilities (PHP2Shell) and a high-severity Node.js flaw (Node2Shell) that could enable remote code execution in affected environments were identified; researchers have observed PHP2Shell exploitation attempts.⁶ Earlier this year, CrowdStrike reported that 2025 saw an 89 percent year-over-year increase in attacks by AI-enabled adversaries.⁷ Taken together, these incidents underscore the urgency of rapid patching, stronger identity and certificate controls, and AI-aware cyberdefenses.

The time to respond is shrinking

Attackers are moving faster, with the average time between the disclosure of a critical vulnerability and active exploitation now just a matter of hours, compared to a few weeks as recently as a year ago.⁸ By 2026, about two-thirds of exploited vulnerabilities were being exploited on or before the day of disclosure.⁹ Defenders, meanwhile, have slowed. In Verizon’s 2026 Data Breach Investigations Report analysis of CISA-listed known exploited vulnerabilities from its 2025 data set, the median time to full remediation rose from 32 days to 43 days, and only 26 percent were fully remediated.¹⁰

Attackers are moving faster, with the average time between the disclosure of a critical vulnerability and active exploitation now just a matter of hours, compared to a few weeks as recently as a year ago.

Unlike attackers, who work in hours, most enterprises still work in weeks. The practical form of this gap is the weekend advisory in a widely deployed remote-access or edge product, arriving with incomplete vendor guidance. Most enterprises already generate more alerts than anyone reads, and AI-driven discovery will add to that volume. Even when they are read, the most practical move in the hours that matter is often to switch the exposed service off and accept the operational consequences. Leading organizations are closing the speed gap by automating the detection, prioritization, and containment of threats wherever possible, while retaining human oversight for critical decisions.

The costs of fixing flaws are growing

The economics are now asymmetric. From an attacker’s perspective, asking a model to look for vulnerabilities can be cheap and fast. But as a defender, comprehensive vulnerability scanning with frontier AI models to ensure gaps are thoroughly identified, can cost much more. Remediating the vulnerabilities found can be slow, and even more expensive. Early-adopting enterprises tell us that the first scan of their crown-jewel systems finished within days to weeks. The remediation behind it may take up to months.

The money is only one part of the cost. Fixes compete for scarce engineering talent and change windows. Every squad ring-fenced to clear vulnerabilities is a squad not building the products the business depends on. Left unmanaged, the backlog saturates security and engineering teams, as well as the third-party (often open-source) maintainers organizations also depend on.

Early-adopting enterprises tell us that the first scan of their crown-jewel systems finished within days to weeks. The remediation behind it may take up to months.

The regulators are raising the bar

Regulators have noticed these sudden shifts. In April 2026, US Treasury Secretary Scott Bessent and then Federal Reserve Chair Jerome Powell convened leaders of major banks to discuss the cybersecurity implications associated with Anthropic’s Mythos AI model.¹¹ On July 7, 2026, European Central Bank’s Banking Supervision division asked “significant institutions” to submit by October 31 action plans to accelerate vulnerability and patch management, improve monitoring and AI-enabled defenses, and strengthen supplier and exposed-asset safeguards. The letter places responsibility with management bodies and states that “ICT investments, resource allocation, and ICT risk-related risk tolerance frameworks (RTFs) may need to be revisited.”¹²

The Bank of England, Financial Conduct Authority and HM Treasury, as well as CERT-EU and national cyber agencies, have also published guidance on responding to frontier-AI-enabled cyber risks.¹³

Four levers for a new software security model

Most technology leaders are attempting to adapt to this new environment with little spare capacity, yet they recognize that processing a large patch queue the old way will likely fail at both cost and speed. Hiring a large permanent team to chase every finding isn’t a compelling alternative, as it can pull product development into the backlog. Instead, the most practical, long-term solution is an integrated program in which four key levers move together, because each depends on the others to reduce immediate exposure, prevent growing backlogs, and address underlying flaws.

1. Cyber practices: Make discovery AI-native, and smarter

Early adopters have learned five lessons. All serve the same purpose: spending scarce human effort on flaws that are real and relevant.

Go multimodel. Different AI models and traditional tools find largely different sets of flaws. Relying on one tool, even the most advanced one, can leave blind spots. High-performing security organizations tend to run a frontier model where they have access: a generally available or open-weight model deployed inside their perimeter where source code cannot leave; and the scanning tools they already license on the same scope. They use the most capable and expensive model on the most complex and critical code, and cheaper models for volume.
Bring every finding into one place. Weaknesses in application code, cloud configuration, third-party components, and exposed passwords and keys are usually found by different tools and land in different queues. Relatively moderate flaws on their own—a weak cloud setting, for instance, with a low-level code bug—can become critical, often overlooked issues in combination. For this reason, high performers treat infrastructure and code as a single element, building a unified vulnerability record that brings all findings together, removes duplicates, and links each to an owner.
Enrich with context. The real risk of a vulnerability depends on whether it is reachable, internet-facing, and near critical data or a critical business action. A critical-severity finding in dead code on an isolated system is a very different matter than a high-severity finding on the authentication path into the system that holds client assets. Understanding and acting on these distinctions requires an accurate inventory of assets, underlying software components, and their exposure—work many organizations have deferred for years.
Require reproducible proof before a developer is engaged. Responding to the discovery of a problem can be slow and costly, so forward-thinking enterprises have strict criteria for escalating vulnerabilities. In this model, an engineer is looped in only where there is a reproducible trigger, confirmation that the vulnerable component is deployed, and evidence that the recommended mitigation applies to the version in use. Unproven findings, by contrast, go to a holding queue with an expiry, because an inability to reproduce a finding can still warrant further inquiry. The exception is an indication of active exploitation or severe exposure on a critical system; such issues typically go straight to expert triage, and to containment where warranted, while validation continues.
Move from periodic campaigns to continuous discovery. A one-off scan of the crown jewels is the right first step, but the long-term difference maker is AI-assisted testing embedded in the delivery pipeline, so that new and changed code is examined before it ships.

Different AI models and traditional tools find largely different sets of flaws. Relying on one tool, even the most advanced one, can leave blind spots.

2. Operating model: Build security into the engineering system

AI increases the value of preventing recurring vulnerabilities across the organization. For enterprises that develop or modify software, whether in house or through external partners, achieving this requires establishing common safeguards across software development activities: approved components, secure defaults, constrained environments for coding agents, and automated checks built into the delivery process. This is a challenging undertaking, in and of itself. While product teams are accountable for the security of their services, platform teams need funding and a mandate to make these capabilities practical for them to adopt. Security specialists also play an important role, defining the requirements and independently challenging whether they work.

Once any serious vulnerability is remediated, it’s equally important to figure out how to change the shared engineering system to prevent the same failure elsewhere. Moves in four main areas are the foundation of this operating model shift: design, development, verification, and release and accountability.

Design. Languages, frameworks, and platform controls should automatically enforce a shortlist of default security properties, which teams can configure within defined boundaries. Enterprise applications need to have the following: defenses against broken access control, injection,¹⁴ unsafe deserialization,¹⁵ server-side request forgery,¹⁶ exposed secrets, and misconfiguration¹⁷; use authorization that denies access unless policy allows it; vetted primitives¹⁸ for queries, commands, and parsing; short-lived workload identities¹⁹; and dependencies resolved from approved registries.²⁰ For system-level and edge code, new components should default to memory-safe languages,²¹ with remaining unsafe modules isolated and inventoried.
Development. Coding-agent access should be designed as privileged access. Write rights should be restricted to the task branch through a short-lived credential tied to the agent’s identity. Though the agent may propose a dependency change, it should not be able to add a registry, relax the approved list, or bypass dependency controls. It should also have no access to production credentials, production systems, production data, or secret stores. Since agents read untrusted issue text, documentation, and third-party code that can carry injected instructions, access limits should be enforced outside the model.
Verification. The development pipeline produces the evidence required for release, and the reliability of the process requires a clear separation of authority: A human or agent proposing a code change must not be able to weaken mandatory checks, make changes to security requirements or release controls, or approve its own exception. The development pipeline should execute the checks in a controlled environment and retain the results against the exact version being released. For material changes, evidence should include security and regression test results; checks that demonstrate a reported finding and its fix where reproducible; and provenance²² recording the authoring identity, base commit,²³ toolchain, model version where applicable, and resolved dependencies. A second “checking” model can help identify issues, but its assessment alone is insufficient, especially as it may share the authoring model’s blind spots or favor answers from its own model family. For this reason, it’s advisable to use a checking model from a different provider, review its dismissals as carefully as its confirmations, and test it against human judgment.
Release and accountability. A change should proceed only when its required evidence is complete and passing, it falls inside a preagreed envelope, and the service tier allows it. Changes to trust boundaries, authorization policy, cryptography, parsing of untrusted input on critical systems, or dependencies outside the approved list should require a human signoff. The product engineering owner is responsible for the outcome, including agent-written changes. Platform engineering oversees the release gates, while security defines the mandatory properties and assures that those gates enforce them. Accountability continues through deployment. The application owner must verify that the fix has reached the affected systems and addressed the vulnerability.

As they work to implement this new operating model, CIOs and CTOs can act across several dimensions, as leading organizations have already shown:

Apply the model according to what you control.
- New development: Make the approved engineering platform the default.
- Existing systems: First establish whether changes can be made safely. Where automated tests, ownership, or reliable deployment are lacking, invest in those foundations alongside targeted fixes.
- Commercial software, including SaaS: Require evidence of secure development and timely remediation from suppliers, while managing the access, configuration, integrations, and data exposure that the company controls. Critical services need a practical contingency if the supplier cannot remediate within tolerance.
Give critical dependencies an owner and an update path. Critical shared libraries, base images, and dependency sets should be treated as maintained products. Assign a team to manage approved versions, validate updates, and coordinate their adoption across affected services. Product teams remain responsible for deploying those updates and verifying the results.
Organize remediation and make capacity decisions explicit. Run remediation at three speeds. Credible urgent threats and exploitable vulnerabilities on critical systems are routed to a rapid-response team with preagreed authority to act, including degrading or disabling a service. Other findings enter normal delivery, with agents proposing and testing fixes, and engineers assessing the evidence. The third route is retirement: Give systems whose business value no longer justifies their exposure and maintenance burden a funded decommissioning or replacement plan.
Measure the reduction in exposure and recurrence. Time to effective containment, when verified controls block the relevant attack path, is distinct from time to verified remediation, when the underlying flaw has been addressed across affected systems—and both need to be closely monitored. Early adopters also track the material exposure that remains against agreed-to tolerances, alongside whether changed code reintroduces the types of flaws the platform is meant to prevent. As part of these reviews of the security outcomes, it’s important to monitor how much engineering staff was used and any product commitments that were displaced.

3. Risk and control framework: From paperwork to a North Star

Most control frameworks were built for periodic, after-the-fact assurance of systems that behave predictably. Neither assumption holds anymore.

Turn risk appetite into exposure tolerances. Most cyber-risk appetite statements are qualitative and cannot settle an argument about what to fix first. Tolerances can. Define, by asset tier, how long a proven, exploitable flaw may stay open: days for a tier-one, internet-facing system; a quarter for an internal tool with no path to critical data. Tolerances determine where remediation effort and funding go, so every finding doesn’t risk becoming a board issue.
Rate risk on exploitability and business impact, not severity labels. Policies that require every finding rated critical to be fixed within a certain number of days cannot be met once volumes rise tenfold. The risk function should devise and oversee a rating method that combines proof of exploitability, reachability, evidence of exploitation in the wild, and the tier of the affected asset, and rewrite remediation policies around it. That gives the first line a defensible basis for prioritization, and the second line a basis for challenge.
Make risk acceptance explicit, owned, and timebound. Not every flaw can be fixed within tolerance. Where it cannot, the framework should require a compensating control, a named business owner who accepts the residual exposure, and an expiry date after which the issue is escalated rather than renewed by default.
Move from periodic attestation to continuous control monitoring. Key controls should be expressed as rules that systems check automatically and regularly in the delivery pipeline, in identity platforms, at trust boundaries—not sampled once or twice a year. The evidence the pipeline produces for every change is also the evidence the second line and audit need. Each quarter, the board should see three numbers set against the risk appetite it approved: exposure window, the remediation backlog on critical systems, and supplier patch speed.
Bring AI agents into the control framework. Agents break two assumptions most controls rely on: that the same instruction produces the same action, and that an actor approved once can be trusted thereafter. The framework should treat agents as a distinct class of privileged actor, each with their own identity and accountable owner, a documented envelope of permitted actions, logging that attributes every action, and outcomes verified by deterministic tests rather than by another model. Model risk management should extend to agents, with reevaluation, including against adversarial inputs, whenever the model or its instructions change.
Hold suppliers to the same standards. Third-party risk management typically assesses a vendor at onboarding and once a year. That is no longer sufficient, with exposure often depending on how quickly a vendor patches. Contracts with critical suppliers should carry patching commitments whose clocks match the tolerance of the tier they serve, and supplier patch speed should be tracked as a risk indicator. Finally, an isolate-or-disable decision should be agreed to in advance in case a supplier misses a deadline.

Policies that require every finding rated critical to be fixed within a certain number of days cannot be met once volumes rise tenfold.

4. Technology: Assume breach, and contain the blast radius

When vulnerabilities are continuous rather than occasional, the realistic goal becomes effective downside protection: limiting how far an unpatched flaw can reach and how much an adversary can do with it.

Start with trust boundaries, and segment more finely only where the blast radius requires it. Leaders should define the boundaries that matter most—between crown-jewel systems and the rest of the estate, between production and build environments, between identity infrastructure and application data, and between the company and each critical third party—and enforce them rigorously. They should then tighten segmentation within those boundaries where a single compromise would still travel too far, in some cases down to the level of individual workloads.
Protect the data and strengthen the basics. Encrypt data in transit and at rest within the crown-jewel boundary and set a road map to quantum-safe cryptography. Starting such a road map means taking an inventory of where cryptography is used on critical systems and a sequence for replacement, not a completed migration that same year.

At the same time, multifactor authentication, least-privilege access, and identity security matter more as the time available to patch shrinks. Automatic updates, tested recovery, and immutable backups complete the picture.

Put experts and agents together on the security logs. The same AI that finds flaws in code can help defenders search the alerts and logs most organizations collect but cannot fully review. In an effective pairing, the expert decides what to look for and judges the results, and the agent does the volume work of searching, correlating, and summarizing.
Aggressively buy down technical debt. Retiring systems is often the cheapest, best remediation option. Those systems that don’t deliver enough business value for the remediation they require should be given a funded decommissioning or replacement date. Unused components, features, and dependencies can be stripped from the systems that remain, so there is less code to scan and fix. End-of-life platforms and libraries can go back into vendor support or be isolated behind hard boundaries until they are replaced.
Extend the same discipline to the ecosystem. Having a software bill of materials²⁴ and component visibility means an organization can respond successfully to a weekend advisory, fully aware of what they are running. The use of open source also requires deliberate choices: which repositories are allowed, which are allowed only with a pinned version and review, and which are declined to keep the attack surface small. The projects the business genuinely relies on also need support, in funding, maintainers’ time, or both.

Retiring systems is often the cheapest, best remediation option. Those systems that don’t deliver enough business value for the remediation they require should be given a funded decommissioning or replacement date.

Getting started with the new security program

Launching the four-lever security approach is a complex undertaking that can often stall, whether because of leadership indecision, cost concerns, or the overall approach to remediation. Successful organizations have shown the value of starting with a clearly defined set of critical systems and one delivery path. They use the first 90 days to establish a working program and produce evidence on which to base expansion. Most importantly, they choose as limited a scope as necessary to be able to achieve the following milestones.

Days 1 to 30

The first month establishes the scope, authority, and foundations for the rest of the program and, as such, requires hitting more (and more detailed) milestones than during the following months. In this critical period, leading organizations take the following steps:

Define the scope and establish ownership. Specify the critical systems, identify their software components and dependencies, and appoint accountable service owners. Assign ownership for critical suppliers and shared components.
Launch targeted discovery, and prioritize findings. Run the first multimodel scan, combining the models with existing scanners; avoid overreliance on just one model provider. Consolidate findings from code, cloud configuration, third-party components, and exposed passwords and keys into a single record. Publish a first ranked view of proven, reachable findings by asset tier, with an estimate of the effort to fix them.
Determine risk tolerances and decision authority. Establish exposure tolerances and emergency authority, including the conditions under which an exposed service may be restricted or disabled. Require every risk acceptance to carry a compensating control, a named business owner, and an expiry date, and list the exceptions already open.
Set up the engineering pilot and establish rules for AI access. Select one delivery path for the engineering-platform pilot. Make three costs visible: discovery, remediation capacity, and platform investment. Align on the initial capacity allocation and how decisions will escalate when material exposure cannot be brought within tolerance. Agree on the rules for source-code access, data handling, retention, and logging, for the named scope.
Verify critical defenses and response readiness. Confirm multifactor authentication, least-privilege access, and a tested restore path for critical systems. Separate vulnerability findings from detection alerts, and confirm that high-severity alerts on critical systems reach a named person who can act within minutes or are contained automatically.

Days 31 to 60

In the second month, early adopters progress from setting the foundations to implementing the program. As part of this shift, they make sure to focus on the operational issues that emerge. Their important moves include the following:

Put the pilot into use with secure defaults, bounded agent access, protected verification controls, maintained dependencies, and staged deployment.
Make the normal delivery process the route for routine fixes, with rapid response available for urgent threats.
Address the constraints revealed by the first fixes: missing regression tests, unclear ownership, scarce change windows, and delayed supplier responses.
Confirm compensating controls and recovery arrangements for exposure that cannot yet be removed.
Fund targeted retirement or replacement where it removes disproportionate risk and maintenance effort.

Days 61 to 90

By the third month, top performers are focused on tracking material impact, staying ahead of continuing risks, and considering how to expand the program. The most impactful actions include the following:

Demonstrate results on the selected scope: time to effective containment and verified remediation, remaining material exposure, recurring defects, and engineering capacity consumed.
Make product commitments displaced by remediation visible.
Review supplier performance and exceptions against the agreed-to tolerances.
Decide which engineering capabilities to expand, which controls or workflows need adjustment, and which unresolved risks require executive action. Expand based on observed results and the capacity to act on findings.

The 12-month board checklist

Once a full year has passed since the program was launched, the board should test whether the initial improvements have spread and persisted, focusing on the following questions:

Exposure and prevention. Is material exposure within tolerance? Are recurring defects falling, and have the shared engineering capabilities spread beyond the pilot?
Ownership and investment. Are service, platform, and supplier responsibilities working in practice? Which capacity trade-offs and risk acceptances still require executive decisions?
Resilience. Have recovery and containment been demonstrated? Which high-exposure legacy systems have been retired or improved, and which critical suppliers or dependencies remain unresolved?

Frontier AI raises the stakes for software security, dramatically increasing the volume of vulnerability discovery and pace of exploitation, while expanding the tools available to defend against attacks. Forward-looking organizations are already adopting a holistic new approach to prevent recurring flaws, verify changes through deployment, and contain failures when they occur. The approach depends on sustained investment in the engineering platform, clear ownership across product and security teams, and explicit decisions about acceptable exposure. Above all, it requires coordinated shifts across four areas: cyber practices, the operating model, the risk and control framework, and technology. For the enterprises that can achieve this transformation, success can translate to fewer recurring defects, less material exposure, and a reliable ability to recover. At a time when flaws are being found and risk is being weaponized at unprecedented levels, that kind of digital resilience could prove to be a long-term competitive advantage.