SonarQube Hunter Agent GA and Access Guide

On this page

Quick answer

SonarQube Hunter Agent became generally available for SonarQube Cloud on August 27, 2026. SonarQube Server support is still coming soon. The agent runs full-codebase, playbook-based analysis on demand or on a schedule, then places confirmed findings in the SonarQube issue workflow.

It targets three logic-heavy classes: broken access control, business-logic vulnerabilities, and authentication or session-management gaps. Sonar positions it as a complement to SAST, not a replacement. Before rollout, verify the exact Cloud plan, project eligibility, supported languages, repository scope, scan behavior, data handling, pricing, and current documentation.

Current product boundary

QuestionCurrent answerRequired check
Cloud availabilityGAOrg, plan, region, contract, project, language, and feature flag
Server availabilityComing soonDo not plan a self-managed rollout until documented and observed
Run modeScheduled or on demandTrigger, concurrency, duration, cancellation, retry, and result freshness
Pull-request behaviorBackground and non-blocking per SonarDefine how confirmed high-risk findings affect release decisions
Analysis scopeEntire project codebaseIncluded branches, generated code, dependencies, history, and excluded paths
Result destinationSonarQube issue listPermissions, severity, assignment, status, suppression, and audit

The product page says Hunter Agent works with any language supported by SonarQube Cloud, but implementation coverage can differ by framework, architecture, generated code, and application behavior. Prove coverage with seeded cases in the exact stack.

How the playbook flow works

Sonar describes a curated multi-step prompt sequence with four stages:

  1. Hunt: follow code, data, and identity flows across the codebase to form hypotheses.
  2. Confirm: investigate a suspected vulnerability before surfacing it.
  3. Explain: attach severity, a plain-language account, and code location.
  4. Integrate: send the confirmed issue into SonarQube for triage, assignment, and remediation.

This vendor workflow does not remove the need for your own evidence. Record the repository and commit, playbook or service version where exposed, scan configuration, finding identifier, affected asset, reachable path, environmental preconditions, reviewer, severity rationale, fix commit, regression test, and final status.

A bounded rollout

Start with one non-production project representing the application’s identity, authorization, workflow, and session patterns. Seed or select known cases across all three supported classes, including negative controls that should not produce findings.

Compare Hunter Agent with current SAST/SCA, manual code review, tests, threat models, and recent penetration-test findings. Track unique valid findings, overlaps, misses, reviewer time, time to remediation, regression quality, scan delay, and cost. Do not use only the number of surfaced issues as a success metric.

Then test multi-repository boundaries, monorepos, excluded paths, stale branches, generated code, secrets in source, third-party code, data retention, user permissions, suppression, and scan cancellation. Confirm what source content leaves the repository boundary and which vendor terms govern it.

Use the Hunter Agent versus SAST and pentest guide to place the layer, the three vulnerability classes guide to build cases, and the readiness check to capture rollout evidence.

Frequently asked questions

Is SonarQube Hunter Agent generally available?

Yes for SonarQube Cloud. SonarQube Server support is still described as coming soon.

Does Hunter Agent block pull requests?

Sonar says it runs in the background and does not block a pull request. Define a separate policy for how confirmed high-risk findings affect release.

What vulnerabilities does it target?

The current product surface documents broken access control, business-logic flaws, and authentication or session-management gaps.

Does a finding prove exploitability and severity?

No. Confirm application scope, reachable path, deployment context, exploitability, impact, severity, ownership, remediation, regression, and independent security review.

Official sources

Source check: August 29, 2026. Recheck Cloud and Server availability, plans, regions, language coverage, project scope, data handling, run controls, pricing, and support before rollout.