How SonarQube establishes a practical baseline for code verification

Executive Summary

Organizations implementing code verification need a common standard against which software can be assessed consistently across teams, projects, and delivery environments. That standard must be sufficiently clear and specific to support automated enforcement, so that tools can evaluate code objectively and at scale. Defining such a standard independently can be difficult and resource-intensive for individual organizations, which is why a broadly applicable baseline such as the Sonar way serves an important practical and governance function.

The Sonar way quality profile and Sonar way quality gate are designed as baseline software quality controls for broad organizational use. Their purpose is not to encode every possible engineering rule, but to establish a practical and scalable minimum standard for codebase health. When implemented by SonarQube, … 

From an audit and governance perspective, the Sonar way (implemented via the quality profile and quality gate) is built around three principles: 

1. It assesses code across the dimensions of code quality (security, reliability, and maintainability) and assigns severity proportional to issues with operational and risk significance, because weaknesses in these areas are most likely to lead to vulnerabilities, production failures, or increased cost and complexity of change.
2. It places primary emphasis on newly added or modified code, where teams have the clearest accountability and the strongest ability to remediate issues promptly, before they create external-facing risk. 
3. It limits the default ruleset to controls that are widely applicable, non-controversial, non-conflicting, and low in false positives.

This design is intentional. A default standard that is overly restrictive tends to generate exceptions and noise, reduce developer trust, and weaken adoption. A default standard that is too permissive fails to provide meaningful assurance. The Sonar way is built to balance those competing concerns. It establishes a credible baseline, supports gradual improvement of legacy code, and leaves room for organizations to implement stricter or more specialized controls where required. 

Additionally, as AI-assisted development increases the speed and volume of code creation, organizations need verification controls that can operate effectively at the same scale. Those controls must produce repeatable, reliable, and defensible results so that higher output does not reduce confidence in code quality or weaken governance oversight. This makes automated verification tools an increasingly important part of maintaining consistent codebase health in AI-enabled development environments.

1. Purpose and scope

This paper explains why the Sonar way quality profile and quality gate are structured as they are, and why that structure is appropriate as a default control model for codebase health.

In SonarQube terms, a quality profile defines the set of rules used during code analysis. A quality gate defines the conditions that code must satisfy in order to pass a release-readiness check.

The two controls operate together: the profile determines what is assessed; the gate determines whether the result is acceptable.

For audit purposes, the Sonar way should be understood as a baseline automated control within the software development lifecycle. It is intended to prevent the introduction of material new risks, promote consistent engineering practice, and provide objective evidence that code changes have been assessed against a defined standard.

2. Design logic behind Sonar way

The Sonar way is built as a default standard for heterogeneous engineering environments. That means it must work reasonably well across a wide variety of projects, languages, teams, and delivery models. The design therefore favors consistency and control effectiveness over maximum strictness.

The underlying logic is that code quality controls are most effective when they are actionable, trusted, and consistently applied. If the default standard includes too many project-specific, technology-specific, or highly debated rules, it becomes difficult to adopt and difficult to govern. If findings are too noisy, developers and reviewers begin to treat them as background noise rather than as meaningful control signals. This becomes even more important in AI-assisted development, where coding tools can generate large volumes of code quickly but may also respond inefficiently to ambiguous feedback, repeat unsuccessful remediation attempts, or produce plausible but incorrect changes. The Sonar way is designed to avoid that outcome by providing a clear and broadly usable baseline for automated verification.

As a result, the Sonar way focuses on rules and conditions that support general best practice in codebase health rather than niche or stylistic preferences. It is intended to be strong enough to reduce risk, but general enough to serve as a baseline across a broad portfolio. It also serves as a foundation for organizations to build upon as needed, based on their own requirements and risk tolerance. 

3. Why the quality profile is built this way

The Sonar way quality profile is designed to be broadly suitable for most projects and is the default profile for each language in a newly set up SonarQube instance. For many projects, this baseline will be sufficient to support general code health objectives. However, organizations should assess whether it is adequate for their purposes by considering the project’s risk profile, applicable regulatory or contractual obligations, technology stack, and internal engineering standards. Where those factors require more specific or more stringent controls, the Sonar way profile should be supplemented with custom quality profiles. This makes it a starting point for organizational control, not an endpoint.

Its rules are selected according to four practical criteria.

1. The rules should be applicable to nearly every type of project. The default profile should not assume a specific architecture, framework, or development style.
2. The rules should be non-controversial. The Sonar way avoids defaults based on subjective coding preferences or heavily disputed interpretations of good practice. This is important because auditors and engineering leaders need a control baseline that can be defended as reasonable across teams.
3. The rules should be non-conflicting. A baseline profile should not contain rules that compete with one another or require mutually incompatible coding choices. This issue often arises with stylistic rules and is a common source of frustration in overly prescriptive rule sets.
4. The rules should have a low false-positive rate. A quality control is only useful if its findings are sufficiently reliable to drive action. High-noise controls create unnecessary work, weaken confidence in the tool, and reduce the quality of evidence generated by the process.

Rules included in SonarQube and the Sonar way quality profile focus on detecting security, reliability, and maintainability issues. These are the areas in which weaknesses most directly translate into organizational risk.

• Security-related rules reduce the likelihood that code introduces exploitable weaknesses or unsafe patterns.
• Reliability-related rules reduce the probability of defects, failures, and unstable runtime behavior.
• Maintainability-related rules reduce the long-term cost and risk of change by encouraging clarity of intent, controlled complexity, and sustainable structure.

Together, these three domains provide a balanced governance of codebase health and align well with common expectations from risk, audit, and compliance functions.

The Sonar way does not include every available rule. That exclusion is deliberate. Some rules are too restrictive to be appropriate as universal defaults, some are mutually exclusive, others only become relevant when a team uses a specific language level, framework, or test technology. Those rules may be valuable, but they are better introduced through custom profiles after team discussion and governance approval. This keeps the default profile useful to a broad audience and reduces unnecessary friction.

4. Why the quality gate is built this way

The Sonar way quality gate is designed to answer a practical governance question: is the code in a fit state to proceed? Its design reflects the view that a quality gate should be stringent where teams have direct control and proportionate where they inherit historical technical debt.

For that reason, the Sonar way quality gate focuses primarily on newly added or modified code rather than on the entire codebase. 

From a control standpoint, newly changed code is the most appropriate point of enforcement: it is where accountability is clearest, remediation is fastest, and release decisions are most directly affected. By contrast, blocking delivery on the basis of long-standing legacy issues can be counterproductive in large or mature codebases, particularly where those issues predate the current change. A control that fails for reasons the delivery team cannot realistically remediate in the scope of a change often becomes administratively burdensome rather than operationally effective.

The Sonar way approach therefore emphasizes non-deterioration of the codebase. It prevents new risk from being introduced while allowing organizations to improve older code incrementally as it is touched through normal development activity. This is a pragmatic and sustainable model for codebase health management.

The standard Sonar way quality gate contains four conditions on newly added or modified code:

• No new issues are introduced.
• All new Security Hotspots are reviewed.
• New code test coverage is greater than or equal to 80%.
• Duplication in new code is less than or equal to 3%.

Each condition serves a distinct governance purpose.

The requirement that no new issues be introduced establishes a straightforward non-deterioration principle. It prevents incremental accumulation of defects and quality debt.

1. The requirement that all new Security Hotspots be reviewed ensures that potentially sensitive patterns receive explicit human assessment. This is important because not every hotspot represents a confirmed defect, but each requires accountable review.
2. The minimum 80% test coverage threshold on newly changed code promotes adequate verification of behavior. It does not require complete theoretical coverage, but it sets a high enough bar to provide confidence that new logic has been meaningfully exercised.
3. The maximum 3% duplication threshold protects maintainability. Duplication increases change effort, promotes inconsistent fixes, and raises the likelihood of future defects. Keeping duplication low in newly changed code helps prevent avoidable technical debt from being introduced.

Taken together, these conditions create a gate that is clear, measurable, and operationally realistic. They define a release-readiness standard that is both understandable to engineering teams and defensible to auditors.

5. Why the AI variant adds overall-code conditions

The Sonar way for AI code quality gate extends the baseline model. In addition to the four conditions on newly changed code, it adds three conditions on the overall codebase:

• Security rating: A, meaning that the overall codebase contains no vulnerabilities and no security findings above informational level.
• All security hotspots are reviewed
• Reliability rating: C or better, meaning that the overall codebase may contain one or more medium reliability issues, but no high or blocker reliability issues. 

This expanded design reflects a need for broader assurance where code may be produced or modified at greater speed and scale. In such settings, controlling only newly changed code may not be sufficient on its own as evidence of acceptable risk. Additional overall-code conditions provide stronger assurance that the broader codebase remains within defined tolerance levels.

The thresholds themselves also reflect a deliberate balance. Security is held to the strictest overall threshold, which is consistent with the higher impact and lower tolerance typically associated with security risk. Reliability is also controlled at the overall level, but with a threshold that functions as a minimum acceptable floor rather than a claim of excellence. This is consistent with the role of the Sonar way as a scalable baseline rather than a premium or highly customized control regime. Organizations are always free to customize these levels to meet their needs.

6. Governance positioning

The Sonar way is intentionally designed as a starting point. Organizations can and should create custom quality profiles and quality gates where business context, regulatory obligations, technology choices, or internal engineering standards require more specific controls.

This extensibility is part of the design rationale, not a limitation. A baseline control should be broadly adoptable and consistently enforced. More specialized controls should be layered on top where justified. That separation improves governance by distinguishing universal minimum standards from organization-specific policy decisions.

In practice, this means the Sonar way supports two governance outcomes at the same time. It gives all projects an immediate and defensible baseline, and it provides a structured foundation for future tightening as control maturity increases or increasing AI coding adoption drives the need for tighter guardrails.

Yes. I’d add it as a governance paragraph within that section. Here is the revised version:

7. Continuous review and ongoing relevance

The Sonar way quality profile and quality gate are reviewed on an ongoing basis rather than through a fixed periodic cycle. Both are maintained continuously as part of Sonar’s overall product development process, so their evolution is driven by substantive changes in available rules, analysis capabilities, and software development practices rather than by the passage of time alone.

In practice, the quality profile is updated more frequently than the quality gate. As new rules and capabilities are introduced, they are assessed for potential inclusion in the Sonar way quality profile against the principles set out in this paper, including broad applicability, low controversy, non-conflict, and low false-positive rates. Because rule coverage evolves continuously, the profile naturally changes more often.

This process is informed by contributions from teams across the organization, reflecting expertise in areas such as rule development, language analysis, security, product direction, and customer use cases. Final decision-making authority, however, sits with a dedicated team, which ensures that Sonar way evolves consistently and remains aligned with its intended purpose as a broadly applicable baseline standard.

The quality gate is also reviewed continuously, but changes are made less frequently and with greater selectivity. This reflects its role as a stable baseline release control. Adjustments to the gate are considered when new product capabilities or meaningful shifts in development practices justify revising the minimum control threshold, rather than each time an individual rule is added.

This review model is deliberate. By linking change to overall product progress instead of a fixed calendar cycle, Sonar ensures that the Sonar way quality profile and quality gate evolve in step with innovation and remain relevant to changing development practices. This approach helps maintain a baseline that is both current and operationally credible, including in environments where development patterns are changing rapidly through the use of AI coding tools.

Conclusion

The Sonar way is built to be an effective default quality standard that is both rigorous and usable. Its quality profile emphasizes rules that are broadly relevant, low-noise, and material to codebase health. Its quality gate concentrates enforcement on newly added or modified code, where remediation is practical and accountability is clear. Together, they operate as complementary controls: the quality profile defines the standards against which code is assessed, and the quality gate determines whether the outcome meets the threshold required to proceed. The overall focus on security, reliability, and maintainability reflects the aspects of software quality most closely tied to operational risk and long-term sustainability.

The Sonar way is not intended to be exhaustive—it is intended to be a credible baseline control that can be applied consistently, evidenced clearly, and strengthened where necessary. That design choice is precisely what makes it suitable for enterprise-wide adoption. This is particularly important in AI-assisted development environments, where the speed and volume of code generation increase the need for verification controls that can operate consistently at scale. A clear, automatable baseline helps ensure that increased development throughput does not come at the expense of repeatability, governance, or codebase health.