Security for a World of Constant AI-Assisted Discovery

AI Is Finding the Hidden Flaws

Software is written by people, and people make mistakes. A few of those mistakes leave a way in for a stranger, and they are there from the day the code is written. For most of computing history, finding them took rare specialists reading code line by line. There were never enough of them, so most flaws stayed hidden for years.

That has changed. AI models now read code without tiring, and in October 2026 they were part of how serious flaws came to light in software nearly every organization runs, including one in Linux that had sat unnoticed for about a decade.

Atozy, a commentary YouTuber I enjoy, covered the month in a video, "Hackers Found the Master Key to the Entire Internet". It gives a good sense of how much came to light at once.

So can AI find security vulnerabilities? Yes, and faster than the people who repair software can keep up with. Many flaws that would have stayed hidden for another decade will be found in the next few years.

Discovery Now Outruns Repair

This is the real way AI is changing cybersecurity risk. Finding a flaw has become fast. Repairing one safely still means testing the fix, packaging it, and installing it on every affected system, and that work moves at the speed of careful people. For weeks, a flaw can be public and still open. Verizon's 2026 Data Breach Investigations Report put the median time to fully fix a flaw that attackers were already using at 43 days, up from 32 the year before.

For any one organization, the risk is the length of that stretch on its own systems. Some teams close it the same day. Some take until next quarter's maintenance window. Same flaw, and one of them carries it for months.

The Defense Is the Ability to Change

For a long time, the question leaders asked about security was "Are we safe?", as if there were a final answer. When flaws are being found this quickly, the answer is always "probably not entirely." A more useful question is "When a flaw is found in something we run, how quickly can we change it?" That question has a real answer, and you can improve it.

In our cryptography work we call this agility, and it is a process: find where a piece of technology lives in your environment, map what depends on it, then replace it in steps you can test and roll back. Crypto-agility is the methodology behind how we approach encryption, because the methods that protect data will have to change on a schedule nobody fully controls. October showed the same discipline applies to everything else you run. Software, settings, access and encryption all need to be things you can change quickly and safely, because that is what protects the data people trust you with.

Two Nights Put It to the Test

The first night, a client website we look after ran an affected version of PHP. The repair existed, so we took the site offline for a few minutes, installed it, changed the site's credentials, and brought it back.

The second night, the flaw was in Linux servers we look after, and there was no repair yet. We put a narrow stopgap in place the same evening, following the vendor's guidance, and wrote down who owns it and when it comes out.

Neither night was dramatic. The work that made them uneventful had happened months earlier, in knowing what we ran and having a way to change it quickly.

Leaders Set the Speed

Most of that speed is decided in leadership, well before anything breaks: how much downtime you will accept to close a flaw quickly, who may make that call at one in the morning without waiting for a meeting, and what you expect to hear from your team the morning after a flaw makes the news. Those are business decisions, and they are easiest to make calmly, months ahead.

A ready team answers "Are we exposed?" within hours, with three things: whether you run the affected software and where, what has already been done, and when the permanent fix lands. If that first answer takes days today, it's usually a sign the team hasn't been given the inventory or tooling to do it faster, and that is one of the most worthwhile things a leader can fund.

Where Security Is Headed

Atozy ends his video with the observation that AI is running the offense and the defense at the same time. I think that is mostly good news. The same tools that help an attacker find a flaw help the people who build the software find it first.

We are in a bumpy stretch. Decades of hidden mistakes are surfacing within a few years, faster than the repair process was built to handle. On the far side of it, I expect software with far fewer hidden flaws, because so much of it will finally have been read closely. The organizations that come through the surfacing well will be the ones that treat the ability to change as a standing capability, built and practiced before it is needed.

In Vulnerability Remediation we close the flaws already on your list, and engineer and document the stopgap when a repair isn't out yet. Building the ability to change is the thread through all of our work.

Four Questions to Ask Your Team

1. Do we know what we run? If a flaw were announced in a common piece of software tomorrow, could we say within an hour whether we use it, and where?
2. Could we change it today? Is there a way to update every affected system the same day, without waiting for the next maintenance window?
3. Who can pull the plug? Has someone been given permission, in advance, to take a system offline when it's the safest move?
4. Are our stopgaps written down? For every temporary fix in place right now, does someone own it, and does anyone know when it comes out?

Common Questions