The discussion about AI in security has changed radically in recent years. Whereas the central question used to be whether an AI model could find vulnerabilities as effectively as a security specialist, it is now clear that AI can identify potential vulnerabilities at scale. This makes finding vulnerabilities accessible to everyone: from a developer to a potential hacker, as the NCSC also warns .
The real question is no longer about finding vulnerabilities. It is about what you do with all those findings. Prioritizing, validating, and resolving potential vulnerabilities also takes time. The longer the list of potential findings (and the more false positives), the more intensive this process becomes.
In addition, security is not only about finding and resolving vulnerabilities. The real benefit emerges when you understand the underlying cause and feed that knowledge back into the development process. This way, you not only resolve one problem but also prevent the same error from recurring elsewhere.
That shift from "finding" to "assessing" is endorsed by well-known and leading organizations. Cloudflare draws the same conclusion and describes exactly why. Its key insight: AI will always find something.
"Ask a model to find bugs and you will find them, whether or not the code actually contains them. Findings are surrounded by disclaimers such as 'possibly', 'potentially' and 'it could theoretically'. Such uncertain findings are far more common than well-substantiated ones."
Cloudflare calls that "a good bias for an exploratory tool, but desastrous for a triage process: every speculative finding costs human attention and tokens to disprove, and with thousands of findings, those costs add up". The essence of its message: that problem cannot be solved with a better model, but with specialized tooling. Cloudflare therefore developed a system with several validation steps that a finding must pass before a person reviews it. Without those steps, the result is primarily a faster way to produce a lot of noise.
An important insight is that an attacker faces the same problem. An attacker can run the same models but faces the same mountain of speculative findings. Whoever is best able to assess what is genuinely dangerous in your environment therefore has a real advantage.
A vulnerability exists within the context of an application and an organization. Whether something is exploitable depends on your environment: which versions you run, what is publicly accessible, what is behind your firewall, and more. In addition, there is an impact, which depends on your specific organization.
An AI tool sees code but does not know this context. It does not know that an outage in a payment system immediately costs revenue, that a seemingly harmless export function contains the entire customer database, or that an outdated administration panel is only accessible internally. This context is precisely what determines which finding must be resolved today and which can wait. That judgment requires access to your systems, knowledge of your risk profile, and insight into what is important to your business.
AI helps us understand large volumes of code more quickly and discover potentially interesting locations. When we suspect a vulnerability, we use AI, for example, to write a proof of concept more quickly.
The tooling to which AI is given access is crucial in this regard. For the HTTP Terminator, for example, PortSwigger researcher James Kettle translated four years of spezialized experience into a method that the system could apply at scale. AI generated attack vectors based on this expertise, which could then be tested and validated automatically. In this way, AI increased the reach and speed of a methodology developed by the researcher.
Without specialized tooling, a well-considered research method, and practical validation, a great deal of noise quickly emerges. That is why we also develop specialized tools for important aspects of application security. The following two practical examples show how AI added concrete value during our assessments.
During our initial experiments, we had AI analyze source code independently. Among the hundreds of potential findings, including many false positives, one immediately stood out: AI had investigated further in an endpoint where we had already found a SSRF vulnerability. AI linked an unvalidated parameter to an optimization path for image processing, allowing an attacker without authentication to write controlled data outside the cache directory.
The required payload depended heavily on unusual application logic and a specific property of the programming language. AI helped us understand this context quickly and develop a suitable payload. Within the test environment, we confirmed the hypothesis that it was possible to write files to arbitrary locations. By placing files in a strategic location, this write primitive could be extended to remote code execution.
AI accelerated the in-depth assessment and the development of a suitable payload. As a result, we were able to substantiate remote code execution in addition to SSRF within the same assessment duration. This enabled us to achieve greater depth without compromising the breadth or quality of the assessment. This case showed us at an early stage how AI can deepen existing research and reveal additional impact more quickly.
In a more recent hardware assessment, we identified a buffer overflow in microcontroller firmware that could potentially be triggered remotely. Because our assessments provide a broad view of the security posture, this type of in-depth exploit development was previously not always possible within the available time.
We gave AI the specific task of reconstructing the attack path from external input to the vulnerable memory operation and determining the conditions for exploitation. Under the supervision of our specialists, AI was given interactive access to the firmware through GDB and JTAG. Substantive guidance from an expert who could interpret the observed interactions was essential in this process. Without this guidance, AI tended to test new hypotheses aimlessly when unexpected results occurred. By analyzing the heap, registers, and crash information after each test, we were able to refine hypotheses in a targeted manner and test modified payloads.
These short iterations took the validation beyond a reproducible crash. We proved that attacker-controlled bytes could overwrite critical heap metadata and ultimately lead to the execution of arbitrary code without authentication. AI therefore accelerated the technical follow-up assessment, while the specialists determined the research direction, exploit validation, and risk assessment.
Software is created by people, and making mistakes is part of development. Not all security risks are immediately visible, especially when different parts of an application come together. AI tools accelerate the development process and quickly produce convincing-looking code, but they can also introduce subtle errors in areas such as input validation, authorization, or data processing.
That is why we look beyond individual vulnerabilities. We combine AI-assisted research with specialized knowledge, manual validation, and business context. In a comprehensive report, we outline as complete a picture as possible of the security posture, the underlying patterns, and the actual risk of incidents, supported by validated vulnerabilities, clear priorities, and concrete improvement actions.
Through knowledge sharing and strategic advice, we help prevent the same errors from recurring elsewhere. This allows your development team to work not only on more secure code but also on a development process in which security has a lasting place.
