AI That Hunts Logic Bugs Before Attackers Do - Taylor Luttrell-Williams, Sonar
Read the talk
AI That Hunts Logic Bugs Before Attackers Do
Taylor Luttrell-Williams introduces SonarQube Hunter Agent through a Python application whose findings include self-assigned admin access and an MFA bypass. The walkthrough connects repository-wide reasoning, specialist agents, validation, issue triage, and scheduled remediation.
From a talk by Taylor Luttrell-Williams
At a glance
Ideas worth remembering
Logic vulnerabilities can arise from relationships between otherwise working components: the demo's admin check trusts a role field that users can write themselves.
Hunter Agent maps the repository, feeds three specialist investigations, and applies adversarial validation and noise gates before surfacing findings in SonarQube.
The demonstrated Python scan took about an hour and returned 46 open findings, including self-assigned admin access and protected-route access without completing MFA.
Accepting a valid issue excludes it from quality-gate impact; confirming it lets it affect the gate. Detection and release blocking are separate decisions.
Scans support schedules and branch selection. Automatic, scheduled remediation is announced through SonarQube Remediation Agent, without a demonstrated fix in this recording.
When valid code violates the business rules
Code can work as written and still violate the application's security expectations. That is the gap Taylor Luttrell-Williams, who creates developer content at Sonar, introduces with SonarQube Hunter Agent. Traditional pattern-based static application security testing, or SAST, looks for recognizable problems in code. A logic vulnerability instead requires understanding whether the behavior makes sense under the application's business rules.
The distinction turns on intent: an operation may be technically valid while allowing a user to do something the application should forbid. Luttrell-Williams frames the urgency around faster, higher-volume agent-generated changes and attackers with stronger models. Periodic penetration tests—described here as occurring twice a year or quarterly in many companies—leave intervals in which those changes can introduce new vulnerabilities. Hunter Agent is presented as a way to investigate that class of problem more frequently.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
One repository map feeds three specialist investigations
Hunter Agent begins by mapping the repository globally. That map then supplies three specialist agents, one for each supported vulnerability class. Their task is to examine relationships among components and infer the security expectations those relationships should enforce. The shared map matters because a locally reasonable check can become unsafe when another part of the application controls the data it trusts.
A suspected issue must then survive adversarial validation. Noise gates also filter weak findings and behavior that appears intentional. The playbooks handle this orchestration and return issues with severity, impact, and a location where a developer can address the problem. Those issues appear alongside existing SAST findings in SonarQube, preserving the assignment and inspection workflow.
How does one repository-wide investigation become three distinct kinds of finding? The branching below shows the shared map feeding separate specialist investigations, which then feed validation before issues reach developers. The branches represent separate responsibilities; they do not imply that one specialist runs after another.
Shared context, separate specialist investigations
Read the diagram as text
- Repository. Source input to the investigation playbooks.
- Global repository map. Captures components and their relationships.
- Broken access control. specialists — Investigates authorization and privilege problems.
- Business logic. specialists — Investigates workflow and repeatable-action abuse.
- Authentication and sessions. specialists — Investigates login, session, and authentication gaps.
- Adversarial validation and noise gates. Checks candidate findings and filters weak or intentional behavior.
- SonarQube issues. Severity, impact, source location, and developer assignment.
- Repository → Global repository map: Maps globally.
- Global repository map → Broken access control: Supplies context.
- Global repository map → Business logic: Supplies context.
- Global repository map → Authentication and sessions: Supplies context.
- Broken access control → Adversarial validation and noise gates: Submits candidate findings.
- Business logic → Adversarial validation and noise gates: Submits candidate findings.
- Authentication and sessions → Adversarial validation and noise gates: Submits candidate findings.
- Adversarial validation and noise gates → SonarQube issues: Surfaces retained findings.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Frontier reasoning joins the existing security layers
The talk announces Sonar joining the OpenAI Daybreak Cyber Partner Program, described as bringing governed access to advanced cybersecurity models into products such as Hunter Agent. The intended role is deeper reasoning inside the repository-wide playbooks: investigate leads, validate them before surfacing them, and produce findings that are precise, repeatable, and auditable.
Sonar recommends combining Hunter Agent with SAST and software composition analysis, or SCA, in the same platform. The existing scanners remain one layer; Hunter Agent adds investigation of contextual and logic-level failures. The recording supplies no comparative evaluation or precision and recall measurements, so its promises of comprehensive coverage and repeatable zero-day discovery remain product claims rather than demonstrated guarantees.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An hour-long Python scan returns 46 open findings
The demonstration moves into a simple Python application in SonarQube Cloud. Under Hunter Agent, Scan Now estimates the number of units required for a deep, whole-codebase reasoning pass. The product also supports the self-hosted SonarQube Server. Scan duration depends on project size and complexity and can exceed an hour; this application's scan took about an hour, so the walkthrough uses an already completed run.
The scan first securely clones the repository to give the AI engine access to its source. Architecture analysis maps potential attack surfaces and builds a threat model. Contextual scans then investigate vulnerabilities, and findings from the specialist agents are aggregated and deduplicated into a unified list. Validated vulnerabilities are exported into SonarQube's issue list.
What does that run produce for a developer to inspect? Scan Results shows 46 open issues across broken access control, business logic, and authentication and session vulnerabilities. This is the output count for the demonstrated application, rather than a general detection-rate measure. The category breakdown separates different security expectations that the specialists investigate.
- Broken access control: The listed examples include insecure direct object references, or IDOR; missing or incorrect authorization checks; privilege escalation; sensitive data exposure; and cross-site request forgery. The central question is whether a user can reach data or actions they should not control.
- Business logic: Examples include skipping required workflow steps, abusing repeatable actions, and missing rate limits. Here the problem concerns allowed operations being performed in an unsafe order or quantity.
- Authentication and sessions: Examples include broken authentication, session fixation, non-expiring sessions, weak password recovery, missing multi-factor authentication, and brute-force gaps.
Opening the access-control category leads to the familiar SonarQube issues list. A high-severity finding carries both a Hunter Agent tag and its vulnerability-class tag. The integration lets developers inspect these results alongside other findings without moving into a separate dashboard.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A user-writable role defeats the admin check
The first detailed finding exposes the opening distinction between valid code and flawed intent: any signed-in user can pass the admin access check because they can write their own role field. The authorization decision relies on a value that the person being authorized can change. That relationship makes the check ineffective even if reading the role and checking it both work as implemented.
Where does the user's ability to change their role connect to the admin decision? The issue view points to a source location and explains why the behavior is vulnerable, then provides guidance on fixing it. The important relationship to inspect is the write permission on the role field and the later trust placed in that field. The recording does not specify the patch; the supported correction is to prevent users from granting themselves the privilege the check is meant to enforce.
The issue also has an activity history and can be assigned to a developer. Findings begin in an open state, after which triage determines both the team's judgment and the quality-gate consequence:
- Accept: Treat the finding as valid while excluding it from quality-gate impact, so it does not prevent shipment on that basis.
- Confirm: Treat the finding as valid and let it affect the quality gate.
- False positive: Reject the finding as incorrect.
Accepting an issue therefore records a different decision from confirming it, even though both recognize a real vulnerability.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A password reaches routes that should require MFA
Returning to the scan reveals five business-logic findings before the walkthrough opens an authentication and session finding. This second high-severity issue asks a different question: what can a user reach after supplying only an account password? The reported answer is every protected route, including admin functions, without completing multi-factor authentication. The issue view again provides the source location, explanation, and fix guidance.
The failure is the missing requirement between password authentication and access to protected routes. If those routes admit the user before MFA is complete, the additional factor does not constrain access to them. The security expectation must hold where protected functionality becomes reachable; having an MFA step elsewhere in the application is insufficient.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Schedule the investigation, then assign remediation
How can the same investigation run as the repository changes? Hunter Agent supports scheduled scans as well as on-demand runs, with daily, weekly, or monthly frequency and a selectable branch. The demonstrated scan used the main branch, but recurring scans can target another branch. These settings turn the deep analysis into a recurring task rather than a one-time inspection.
The closing announcement extends the workflow from finding issues and suggesting fixes to assigning them to SonarQube Remediation Agent. Luttrell-Williams announces automatic remediation as becoming available that week and says remediation can also run on a schedule. The ending does not demonstrate a generated patch or its verification, so it establishes the announced handoff rather than the correctness of an automatic fix.
That handoff completes the product's proposed path: investigate logic-level vulnerabilities, put findings into the existing issue workflow, and assign work to developers or the remediation agent. The closing invitation keeps the talk's hunting metaphor: “hunt for issues before you yourself are hunted.”
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- SonarQube + OpenAI: Agentic Development — Killian Carlsen-Phelan, Sonar
Shows the complementary development-loop workflow: source-to-sink analysis, SonarQube findings inside Codex, and remediation of a demonstrated SQL injection.
- How to Build Quality Gates into Agentic Coding Workflows — Nnenna Ndukwe, Qodo AI
Develops the quality-gate and remediation side through a payments API example, including severity-based blocking and verification after automatic fixes.
Read the complete timestamped transcript
- 0:12
Well, hello, good afternoon, and welcome all to my session on the SonarQube Hunter Agent. It's an AI security agent and built to detect the classes of vulnerabilities that SAST cannot and before attackers can. My name is Taylor Luttrell. I create developer content at Sonar. We're the makers of the SonarQube. Today, I am very hyped to get y'all
- 0:42
up and running with SonarQube Hunter Agent. So to start, as we all know, in the agentic era, code is shipping at both agentic velocity and agentic volume, and as a result, an unprecedented number of vulnerabilities are reaching production environments, leaving companies exposed and vulnerable. And if you're familiar or you actively use traditional pattern-based scanners like SAST, you may very
- 1:12
well understand that there are classes of issues which it is simply not designed to account for. These are issues of intent rather than the patterns that it is adept at finding. And so in explaining this, um, basically not all vulnerabilities are bugs in your code, at least according to SAST. And that's to say that the issues that it can find
- 1:42
are not always accounted for. These are issues of intent, issues related to logic-level vulnerabilities wherein the code may very well be valid, but the intent itself is not. And that's to say that it's technically or it's functionally correct, but the intent behind it is flawed, right? It contradicts your underlying business logic, for example. Now, in many companies, pen tests happen
- 2:12
at most twice per year, perhaps once per quarter. But as attackers are now enabled with better models than ever, um, and as the time between which these, uh, agent-generated changes are shipping, we need a new class of agents to suss out, to detect, and to fix these vulnerabilities. So I introduced SonarQube Hunter Agent to fill that gap
- 2:41
exactly. So in order to accomplish this, there's first an agent that maps the repository globally, and then based on that global map, it starts three specialized agents, one per class of issue that it can find. And these issues look at relationships between all the components and try to define the security expectations, if you will. We then run adversarial validation to make sure that the issues are
- 3:11
actually correct and not false positives, and we have noise gates as well to reduce the really low, um, validity, uh, issues or issues that would be by design. And so these playbooks essentially take a repository as input. They handle all the complex agent orchestration, and they output high-quality issues that you can then assign to your developers. In doing so, we assign a severity to these issues, we determine the impact that it can have on your
- 3:41
overall code base, and we point you to the exact location where they can be addressed directly.
- 3:51
So in representing these findings, if you already use SonarQube, these issues will surface alongside all of the other issues that we already look for using our SAST tool. As I said, you can assign a, um, you can assign a severity to all of these. Um, in the agentic era, where attackers are moving faster than ever, you need a solution that can
- 4:21
keep pace with just that. As the time between a vulnerability being discovered and weaponized is shrinking, and it's shrinking now ever faster.
- 4:32
And so we are very excited to announce today, y'all are among the first to hear this, that Sonar is joining the OpenAI Daybreak Cyber Partner Program, which is gonna bring you governed access to advanced cybersecurity frontier models directly in products like SonarQube Hunter Agent.
- 4:55
Because we recognize that security teams need frontier intelligence too. We have to keep pace with the very attackers that we are fighting against. And so we saw fit to include this as part of the very agent that susses out the classes of vulnerabilities that may be slipping through the cracks. We provide frontier reasoning inside SonarQube Hunter Agent. Playbooks run across
- 5:25
the whole code base. Every lead is investigated and validated before it surfaces, and these Daybreak class reasonings deepen the reasoning behind each playbook to ensure that all the findings are precise, they are repeatable, and are auditable as well. In doing so, we recommend combining SAST and Hunter Agent, and we do so in a single platform to provide two layers of verification so that nothing
- 5:55
slips through the cracks. SAST and SCA on one hand, and Hunter Agent picking up the slack. This is layered security by design. It's zero trust, it's multi-layered, and it's independent to ensure that we can find zero-day vulnerabilities with precision in a repeatable manner.
- 6:22
And that is SonarQube Hunter Agent in a nutshell. I'm now going to switch gears, and I'm going to demo the product directly to give you all a sense of how it works in a real production setting. So I have on screen a simple Python application of mine, which I have scanned with SonarQube Hunter Agent. I've logged into my SonarQube Cloud dashboard here, and if I navigate to Hunter Agent, you can
- 6:52
see that within the very same UI, you can trigger an on-demand scan by clicking the Scan Now button. This is going to give you an estimation of the number of units required to perform the deep whole codebase reasoning pass over your project on SonarQube. You should also note that this works either with SonarQube Cloud or with our self-hosted variant SonarQube Server.
- 7:24
So were I to click Scan Now, it would kick off a scan of the project. Depending on the size and the complexity of the project, it can take upwards of an hour. So I've-- I went ahead and ran a scan on this project already, which I'm going to walk you through now. The scan took about an hour to complete, and in scanning the project, it first securely clones the target repository to grant the AI engine direct access to the source code. It then
- 7:53
analyzes the application architecture to map potential attack surfaces and build a comprehensive threat model. It next executes deep contextual scans to detect critical flaws like IDOR, broken access control, and business logic vulnerabilities. And it aggregates and deduplicates findings from all specialized AI sub-agents into a single unified issue list. Before lastly, automatically exporting and
- 8:23
logging validated vulnerabilities directly into your SonarQube's issue list. So after having completed, I can click into Scan Results to surface all of those issues that the Hunter agent found. You can see here that there are forty-six open issues on this project, broken across the three issue categories that I touched on earlier. Those being broken access control vulnerabilities, business logic vulnerabilities, and
- 8:53
authentication and session vulnerabilities. So to quickly recap, these broken access control vulnerabilities relate to such things as insecure direct object references or IDOR, missing or incorrect authorization checks, privilege escalation, sensitive data exposure, and cross-site request forgery. Moving on to business logic, this relates to such things as skipping required workflow steps, abusing repeatable actions, and missing rate
- 9:23
limits. And then lastly, those authentication and sesh issues, as I had mentioned, pertaining to broken access or, or broken authentication, I should say, session fixation, non-expiring sessions, weak password recovery, missing multi-factor authentication, and brute force gaps. So I'll go ahead and click into these broken access control, and I'll pick an issue at random. Note that these surface in the same issues list as every other issue that's scanned by SonarQube, so you don't have to
- 9:53
navigate to a new dashboard to surface, um, and inspect all of these. So I'll go ahead and click into broken access control. You can see at the very top we have a-- an issue which has been rated high in severity. All of the issues are tagged with Hunter Agent, as this was the AI agent used to surface them in the first place, and then also the class of issue that it pertains to as well.
- 10:22
In trying to help you remediate these issues, we first show you where specifically within your codebase the issue has surfaced, as well as providing an explanation as to why this is an issue. So in this instance, as you can see, the issue pertains to any signed-in user being able to pass the admin access check because they can write their own role field. So you-- we walk you through basically why this is an issue and then also point
- 10:52
you to how you can go about fixing it as well. Any activity as well related to the issue at hand, and you can assign the issue like you can any other SonarQube issue to the developers of your choosing. All issues, um, open, uh, are, uh, started in an open state by default, and you can either accept the issue, meaning that it is indeed valid, it's not a false positive, but it will not affect your quality gates, and
- 11:21
therefore it will not prevent the code you're trying to ship from entering, uh, production. You can confirm it, meaning that the issue is valid and it will in fact have an impact on the quality gate. Or you can mark it as a false positive if you really and truly believe that the fix is incorrect. So navigate back to the scan that we had conducted. We have also, uh, five business logic findings and a number of authentication and
- 11:51
session findings as well. I'll go ahead and click into one of these just for more breadth. You can see here at the very top, we have another high-severity security vulnerability, this one pertaining to any user with only an account password being able to reach every protected route, including admin functions, without completing multi-factor authentication. Again, we point you to where in your code the issue resides, as well as why it's an issue. How you can fix the issue,
- 12:22
and then again, any activity related to it. Note that while the Hunter agent can be run on demand, it can also be run on a scheduled basis. So if I navigate here to Hunter agent, I can configure a scheduled scan whereby I can run it at the frequency of my choosing. It's highly configurable, uh, be that daily or weekly or monthly, and I can also
- 12:51
select a specific branch should I not want to scan the main branch specifically. In this case, I've scanned the main branch.
- 13:08
And that is Hunter agent in a nutshell. In pointing you towards these classes of business logic-level vulnerabilities, we suggest fixes, but I am excited to announce that as of this week, these issues will also be able to be fixed in a remediated or, or in a automatic fashion, I should note. You can, in fact, assign these issues to the SonarQube Remediation Agent,
- 13:38
which can take care of remediating these classes of security issues for you and also on a scheduled basis. And that is SonarQube Hunter Agent, which will enable you to catch logic-level vulnerabilities before anybody else does, so that you can hunt for issues before you yourself are hunted. Thank you very much.