Preparing Your Security Program for AI Assisted Vulnerability Discovery

What Is AI Assisted Vulnerability Discovery

AI assisted vulnerability discovery is the practice of using a general purpose AI model, rather than a purpose built scanner, to read software and reason about how it can be made to fail. A traditional scanner matches code against a catalogue of known bad patterns, so it finds the classes of bug someone has already written down. A capable model works differently. It reads the code the way an experienced reviewer would, forms a theory about how authentication or session handling is meant to work, notices where the implementation departs from that intent, and then chains several small weaknesses into one usable path. The chaining is the part that matters most, because serious breaches are rarely a single dramatic flaw. They are usually three ordinary oversights that happen to line up.

The same capability serves both sides of the fence. Security researchers use it to find and report flaws before criminals do, which is the entire basis of coordinated disclosure and bug bounty programmes. Attackers use it to find the same flaws and say nothing. Nothing about the technique is inherently offensive or defensive. What separates the two is authorization, and what the finder chooses to do next.

Why It Matters

The cost of ignoring this sits inside a timing assumption that most security programmes never state out loud. Patch cycles, annual penetration tests, and vendor review cadences were all designed around the belief that discovering an exploitable flaw is slow, skilled, expensive work. When discovery gets cheaper, the window between a vulnerability existing and somebody finding it narrows, but your patch cycle does not narrow with it. That widening gap is your exposure, and it grows quietly without anything visibly changing on your side of the wall.

For a business this shows up in three concrete places. Your own software carries flaws that would once have sat undiscovered for years and now will not. Every vendor and open source dependency you rely on is under exactly the same pressure, so your real exposure includes their patch speed and not only yours. And the skill required to attempt this has dropped, which means the threat is no longer limited to well funded specialists with years of training. The competitive argument is simpler still. Enterprise buyers now ask how you handle vulnerability disclosure as part of procurement, and a company that can answer that question credibly wins contracts that a company improvising an answer loses.

How It Works

Whether the person at the keyboard is a researcher or a criminal, the working sequence is much the same.

1. The work starts with reconnaissance, where the model is given whatever is visible, such as public source code, a running application, published documentation, or simply the observable behaviour of a login flow, and is asked to describe how the system appears to be designed to work.

2. The model then forms hypotheses about where intent and implementation diverge, concentrating on the points where two systems hand something to each other, because trust boundaries between components are where assumptions go unexamined by both teams.

3. Each hypothesis is tested against the real system, and the great majority of them fail, which matters more than it sounds, because the entire economic shift here is that testing a hundred wrong theories has become cheap enough to be worth doing.

4. A confirmed weakness is then chained with others to turn a minor issue into a usable path, for instance by combining a session token that was issued more broadly than necessary with a secondary system that accepts that token without questioning its scope.

5. At the final step the two paths separate completely, because a researcher documents the finding, reports it privately to the vendor, and waits for a patch before publishing anything, while an attacker uses the access quietly and tells nobody at all.

How It Works

Visual representation of how it works concepts and implementation strategies.

Common Mistakes

Treating an annual penetration test as coverage. A yearly test tells you the state of your software on one day, judged against the techniques available on that day. It is a useful baseline and a poor defence, because the code changes every sprint and the discovery techniques improve continuously between tests. Organisations that treat the annual report as a clean bill of health are measuring the wrong thing.

Having no way for a stranger to report a problem. This is the most common and most avoidable failure I see. A researcher who finds a flaw in your product and cannot find an email address, a form, or a named contact within a few minutes will give up, post publicly, or move on. You do not get to choose whether people find your vulnerabilities. You only get to choose whether they can tell you.

Assuming your dependencies are somebody else's responsibility. Most business software is assembled rather than written, and a flaw in a widely used library or a vendor platform lands in your environment regardless of the quality of your own code. Treating vendor and open source risk as external is how companies end up genuinely surprised by an incident that was publicly disclosed and patched upstream weeks earlier.

Banning AI tools internally while attackers use them freely. Some organisations respond to this shift by restricting the tools for their own engineers, usually for understandable intellectual property reasons. The effect is asymmetric. It does nothing to slow anyone attacking you, and it removes the same capability from the only people with legitimate access to your source code.

Confusing a compliance certificate with security. Passing an audit demonstrates that you have documented controls and followed a process. It does not demonstrate that a determined party with modern tooling cannot get into your systems. Both matter, but treating the certificate as the finish line leaves a real gap between what you have proven and what you have actually achieved.

Best Practices

Publish a security contact and a disclosure policy, and do it this week. A single page stating where to send a report, what is in scope, how quickly you will acknowledge receipt, and your commitment not to pursue researchers acting in good faith is one of the highest value pages on any company website. It costs almost nothing and it converts a potential public embarrassment into a private email.

Measure time from report to patch, not the number of flaws found. Counting vulnerabilities rewards the wrong behaviour, because a team that finds more is often doing better work than a team that finds fewer. The number that actually governs your risk is how long a known flaw stays unfixed in production. Track that figure, review it monthly, and set a target for your most critical systems.

Put the same class of review into your own pipeline before you ship. If a model can read your code and reason about how it breaks, that capability belongs in your development process, not only in the hands of people outside it. Run AI assisted review on changes to authentication, permissions, payment handling, and anything that crosses a trust boundary, and treat its output as a prompt for human judgement rather than a verdict.

Maintain an inventory of what you depend on and how fast those suppliers patch. You cannot manage exposure you cannot see. Keep a current list of your third party services and significant open source components, and record how each supplier has historically handled disclosure and patching. Supplier patch speed is a procurement criterion, and it deserves the same weight as price.

Rehearse the response before the report arrives. Decide in advance who receives a vulnerability report, who confirms it, who authorises an out of band release, and who talks to customers. Run the scenario once as an exercise. The first genuine report always arrives on a Friday afternoon, and a team that has practised handles it in hours rather than losing days to deciding who is in charge.

Best Practices

Visual representation of best practices concepts and implementation strategies.

Real-World Examples

Researchers at Hacktron AI, an independent AI security platform that tests software code, reported that they had used one vendor's AI model to find a vulnerability affecting another major AI vendor's product, disclosed it privately, and were paid a bounty for the report, as covered by CBS News. The detail worth taking from that account is not which companies were involved. It is that the disclosure path functioned as designed. The finding was reported privately, the affected vendor coordinated a patch and revoked the affected tokens and sessions, and the researchers waited to publish. That is what a working relationship between a vendor and the research community looks like, and it is only possible because there was a channel for the report to travel down.

Google's Project Zero, established in 2014, offers a longer running illustration of the same principle. The team hunts for previously unknown vulnerabilities in widely used software, including software Google does not own, reports each finding privately to the vendor, and publishes technical details after a fixed disclosure deadline. The deadline is the mechanism that matters, because it converts a vendor's patch timeline from an open ended question into a commitment. For a business consuming that software, the practical lesson is that critical flaws in your supply chain become public on a schedule you do not control.

In our own delivery work at Agility, the most common serious finding when we review a mid-market client's application is not an exotic flaw at all. It is an accumulation of small permission and session handling decisions, each entirely defensible when it was made, that together grant far more access than anyone intended. In one engagement with a mid-market services client, the change that mattered was not a new security product. It was narrowing the scope of a token that had been issued broadly for convenience and then quietly reused by a second internal system. That is precisely the shape of problem an AI assisted review surfaces quickly, because finding it requires reading two systems together rather than scanning either one in isolation.

Key Takeaways

• Discovering software flaws is no longer slow or expensive work, so any security plan that assumes otherwise needs revisiting this quarter.
• Publish a security contact address and a disclosure policy now, because a researcher who cannot reach you will eventually tell somebody else instead.
• Track the time between a vulnerability being reported and being patched, because that figure governs your exposure far more than the number of flaws you find.
• Serious breaches usually come from several ordinary weaknesses chained together, so review how your systems trust one another rather than auditing each one alone.
• Your vendors and open source dependencies are part of your attack surface, which makes their patch speed effectively your patch speed.
• Give your own engineers the same class of AI assisted review tooling that researchers and attackers already use, because restricting it internally disarms only the defenders.
• Rehearse your response to an inbound vulnerability report before you receive one, because the first genuine report always arrives at an inconvenient moment.

Key Takeaways

Visual representation of key takeaways concepts and implementation strategies.

Frequently Asked Questions

Does this mean our annual penetration test is now worthless?

No, but it is a baseline rather than a defence. A penetration test tells you the state of your systems on one day against the techniques the tester used, while your code changes every sprint. Keep the test for its depth and independence, and add continuous review of the changes you ship between tests.

We are a small company with no famous brand. Are we genuinely a target?

Yes, because most attacks are opportunistic rather than targeted. Attackers scan broadly for a class of weakness and then act on whoever has it, which means obscurity protects you far less than people assume. Small companies are often more exposed precisely because they assume nobody is looking.

Should we stop our engineers from using AI coding tools?

Restricting the tools for your own team does nothing to slow anyone attacking you. The legitimate concerns are about source code leaving your environment and about engineers accepting generated code without review, and both are solvable with tool choice and review policy. Address the data handling question directly rather than removing the capability from the people defending you.

What does running a bug bounty programme actually cost?

The direct cost is the bounty payments, which scale with the scope you define and can be capped. The larger and more commonly underestimated cost is the engineering time to triage reports and ship fixes, which is the part that determines whether the programme is useful. Many organisations should start with a published disclosure policy and no payments at all, then add bounties once triage is reliable.

How do we tell a genuine vulnerability report from a scam?

Genuine reports include specific reproduction steps you can follow yourself, and the researcher will usually reproduce the issue on request. Reports that demand payment before revealing any detail, or that describe a vague problem without evidence, are usually not worth engaging with on their terms. Always verify the claim in your own environment before paying anyone anything.

Frequently Asked Questions