SonarQube
Continuous code quality and security inspection. Automatically find bugs, vulnerabilities, and code smells in 25+ languages.
Overview
SonarQube is an open-source platform for continuous inspection of code quality and security. It performs static code analysis (SAST — Static Application Security Testing) on source code to detect bugs, vulnerabilities, code smells, and technical debt. SonarQube supports 25+ programming languages and integrates with all major CI/CD platforms.
For NZ teams, SonarQube is the standard "shift-left" security tool — catching vulnerabilities in code before they reach production. It is often the first security tool added to a CI/CD pipeline.
What it's used for
SonarQube is essential for:
- Shift-left security: Find vulnerabilities in code before deployment.
- Code quality gates: Block merges that introduce new bugs or security issues.
- Technical debt tracking: Measure and monitor code quality over time.
- Compliance: Generate reports for security audits and standards (OWASP, CWE, SANS).
Pros & Cons
Pros
- Supports 25+ languages including Java, C#, Python, JavaScript, Go
- Comprehensive rule set for security, bugs, and code smells
- Excellent CI/CD integration
- Detailed dashboards and historical trends
- Free Community Edition covers most needs
Cons
- Can generate false positives — requires tuning
- Developer Edition and Enterprise Edition are expensive
- Large projects require significant server resources
- Not a substitute for dynamic testing (DAST) like ZAP or Burp
- Learning curve for custom rule development
Platforms & Integrations
SonarQube runs on Windows, macOS, and Linux. It requires Java and a database (PostgreSQL, MySQL, or embedded H2). SonarCloud is the SaaS alternative.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Community | Free | SAST, code quality, basic reporting |
| Developer | $150/yr per instance | PR decoration, branch analysis, additional languages |
| Enterprise | Custom | Portfolio management, security reports, support |
| SonarCloud | From $10/mo | SaaS, automatic analysis, GitHub/GitLab/Bitbucket integration |
NZ Context
SonarQube is widely used in NZ software teams. It is frequently mentioned in NZ job postings for developers and DevOps engineers. The NZ Government's Digital Service Standards encourage automated code quality checks, and SonarQube is the most common tool for this. For NZ teams using GitHub, SonarCloud provides zero-setup integration.
Alternatives
- Snyk Code — SAST with better developer experience and IDE integration.
- Checkmarx — Enterprise SAST with advanced customisation and reporting.
- Veracode — Cloud-based SAST/DAST combined platform.
When to choose SonarQube
A quick decision guide for NZ teams evaluating code quality options.
| Choose SonarQube when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team runs Java, C#, or Python in a Jenkins or Azure DevOps pipeline and needs SAST baked into every PR | Your codebase is purely JavaScript/TypeScript on GitHub — Snyk Code gives better IDE feedback and zero-config GitHub integration | OWASP ZAP — SonarQube catches static vulnerabilities; ZAP finds runtime issues like auth bypass and session flaws |
| You need to enforce quality gates across 10+ repositories and want a single dashboard tracking technical debt organisation-wide | You're a solo developer or a two-person startup — the self-hosted server overhead isn't worth it; use SonarCloud's free tier instead | Dependabot or Snyk Open Source — SonarQube scans your own code; these scan third-party dependencies for known CVEs |
| A compliance audit (PCI-DSS, ISO 27001) requires documented evidence of automated security scanning on every code change | You need to test a deployed API or web application for vulnerabilities — that's DAST territory; use Burp Suite or ZAP, not SonarQube | Checkmarx — for enterprise teams that need customised security rules and detailed remediation guidance beyond SonarQube's defaults |
| Your team is onboarding junior developers and you want automated, inline feedback on code quality before code review | Your primary concern is secrets accidentally committed to Git — use GitLeaks or Trufflehog, which are purpose-built for secret scanning | SonarLint (IDE plugin) — extends SonarQube rules directly into VS Code or IntelliJ so developers catch issues before they even commit |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
The bottom line: SonarQube's value is in the quality gate, not the issue count. A gate that nobody takes seriously is noise. A gate that blocks a deploy gets fixed. Tune it to be strict on security issues from day one, lenient on style issues until the team builds trust in the tool.
Interview questions
Questions you are likely to get if you list SonarQube on your CV — with what interviewers are really testing for.
What is the difference between a bug, a vulnerability, and a code smell in SonarQube — and which would you prioritise fixing first?
What they’re really testing: Whether you understand SonarQube’s issue taxonomy and can make risk-based prioritisation decisions, not just parrot the definitions.
Strong answer covers: Bugs = code that will likely fail at runtime; vulnerabilities = exploitable security weaknesses (OWASP-mapped); code smells = maintainability issues that slow future development. Prioritise vulnerabilities first, especially in NZ government or financial services contexts where a Privacy Act breach or NZISM non-compliance carries regulatory consequences. Bugs second. Code smells are backlog items, not blockers.
When would you use SonarQube over Snyk Code for a NZ development team, and when would you choose the other way around?
What they’re really testing: Whether you can compare tools on merit rather than just advocating for the one you’ve used, and whether you understand the difference between SAST and SCA (software composition analysis).
Strong answer covers: SonarQube wins when the team uses multiple languages (Java, C#, Python) in a Jenkins or Azure DevOps pipeline and needs a single quality gate dashboard across repos. Snyk wins when the codebase is JavaScript/TypeScript on GitHub and the team wants IDE-level feedback and dependency scanning in one tool. For a NZ government team with data sovereignty requirements, self-hosted SonarQube is the safer option since source code stays on-premises.
You’re a QA engineer at a NZ financial services company and SonarQube is blocking deployments due to 900 existing issues on a legacy codebase you’ve just inherited. How do you handle this?
What they’re really testing: Whether you understand the “new code period” concept and can apply pragmatic quality strategy without either ignoring the tool or halting delivery.
Strong answer covers: Configure SonarQube’s New Code Period to only gate on code changed since a set date, so the pipeline blocks new problems without surfacing 900 inherited ones. Log existing issues as a technical debt backlog and triage by severity. Escalate any critical or blocker-severity vulnerabilities in the legacy code immediately, as these carry risk regardless of origin — particularly relevant under the NZ Privacy Act 2020 if personal data is involved.
Your SonarQube scan passes locally but the CI pipeline flags a critical vulnerability on the same code. What would you investigate?
What they’re really testing: Whether you understand that SonarQube analysis results depend on scanner version, quality profile, and branch configuration — and that “it passed locally” is not a sufficient response.
Strong answer covers: Check whether the local SonarLint plugin is using a connected mode profile that matches the CI server’s quality profile — mismatches are the most common cause. Verify the scanner version matches between local and CI. Confirm the CI scan is targeting the correct branch (SonarQube tracks branches separately). If the issue is real, raise it as a finding; if it’s a false positive, document the suppression with a justification comment rather than silently marking it “won’t fix.”
How would you structure SonarQube quality gates for a NZ organisation running five product teams, where some teams own greenfield APIs and others maintain decade-old monoliths?
What they’re really testing: Whether you understand that quality gates are not one-size-fits-all, and whether you can balance organisational consistency with team autonomy.
Strong answer covers: Define a base “organisation” quality gate that enforces zero new critical or blocker vulnerabilities for all teams — this is non-negotiable for NZISM or Privacy Act compliance. Greenfield teams get the full gate including coverage thresholds (e.g. 80% coverage on new code). Legacy monolith teams use new-code-period gates with coverage requirements waived until refactoring progresses. Review gate settings in a quarterly engineering governance session so legacy teams have a path to full compliance over 12–18 months.