How to set up SonarQube for SAST: deployment, Quality Gates, and CI/CD

SonarQube: why default configuration misses vulnerabilities

The analyzer is deployed, static code analysis reports open on every merge — but a critical defect reaches release and is found in production.

The cause is usually not the tool itself, but that the rule profile and quality thresholds were left as they came out of the box: the analyzer formally works, but doesn't prevent releasing a vulnerability.

The base profile is designed for an average project. It covers general rules, but doesn't know the context of your stack, so defects specific to the framework remain missed: insecure session handling, concatenation of values in queries, weak password hashing algorithms.

That's how missed vulnerabilities appear — the Quality Gate is in warning mode, the build passes green, and comments accumulate in the queue.

Code debt grows faster than the team can handle. New code check is not enabled for all branches, old modules are not reviewed by anyone, and hundreds of unp prioritised comments merge into one noise — reviewers stop opening the report, and it becomes a formality.

A working SonarQube setup is built from the opposite: the rule profile is assembled for a specific stack, the Quality Gate blocks merge rather than decorates the report, and the new code period is set separately so old modules don't mask fresh changes. Exceptions for generated code and test coverage thresholds are added.

Below we analyze how this is closed in practice — from deployment and profile to thresholds that catch defects before release and don't slow the team.

What changes after implementing static analysis

The first measurable effect is the detection moment. While the check lives only in nightly builds, a defect surfaces a day after the edit, when the context is already lost.

SonarQube in conjunction with the version control system runs analysis on every merge request and blocks it on new violations — the cost of the fix is one line in the description, not an incident investigation in prod.

Check time stays within 2–4 minutes: only changed files are analyzed, the full pass over the entire codebase goes to the nightly schedule. This removes the main argument against static analysis — "the build got longer, the team waits."

Code debt stops growing when the rule is formulated as "zero new violations": legacy is untouched, new code must pass clean. The debt metric doesn't fall instantly, but stops expanding — it can already be planned as a separate task, not as an uncontrolled background.

From the failure classes, those caught formally go away: null reference dereference, unclosed streams and connections, query assembled from strings, credentials in source. This is not "all errors" but a specific slice that is cheaper to prevent altogether.

The output includes a release forecast: the Quality Gate works as a formal criterion — the version either passes it or not. The department head gets not "we tried" but a reproducible risk assessment before rollout.

Deployment options: own environment, containers, cloud

The analyzer can be placed in several ways, and the choice here is dictated not by admin convenience but by two constraints: where the source code is physically stored and who is responsible for updates.

Deploying the analyzer in a closed perimeter excludes code transfer outside, container launch gives the same configuration on all stands, and cloud analysis mode removes infrastructure care but changes the trust model for code.

Comparison of placement modes

The choice reduces to one question: is it acceptable for source code to leave your perimeter. If not — own environment or containers inside the perimeter remain, and cloud is considered only for open projects.

For a team of up to ten developers, container launch usually gives the same set of checks as a full installation, but raises noticeably faster.

Setting up SonarQube for your stack: order of work

SonarQube setup begins not with server installation but with analysis of how code currently reaches the main branch and what checks already exist there.

This shows where the analyzer gives an effect immediately, and where you first need to tidy up the build pipeline — otherwise some projects simply won't have anything to analyze. Below is the route we follow during implementation.

1. Build pipeline audit. Analyze build systems, branching model, release cycle and repository access. Output — list of projects connected first, and bottlenecks hindering analysis.
2. Deployment scheme. Determine placement of the analysis server, database and report storage, describe how the analysis task embeds in the build and what the developer sees in the interface.
3. Rule profile setup. Assemble a profile for your stack: languages, frameworks, business-critical checks. Disable noise that causes false positives and undermines trust in the report.
4. Pilot repository. Run analysis on one medium-complexity project and look at the real flow of findings and build time. Make profile adjustments based on fact, not documentation.
5. Quality gate verification. Fix conditions for branch and release pass, check behavior on dirty and clean code, test build blocking and clarity of output.
6. Handover to support. Give the team configurations, regulation for adding rules and instructions for handling false positives. Then — scheduled profile review as code grows.

This order gives a predictable result: by the rollout to all projects, thresholds are already calibrated, and the team understands what to do with each finding.

What remains with you: profiles, rules, integration schemes

The engineering result of implementation is not a running analysis server, but artifacts that remain in your repository and work without us. We list what exactly is handed to the team and by which documents SonarQube lives further in your pipeline.

• Rule profile — active set for your stack, exported to the repository as a file: deployed on a new perimeter with one command, not manual reconfiguration in the interface.
• Quality gate conditions — separate for new code and release branch: coverage of new lines, duplicate share, absence of blocking findings.
• Exception policies — masks for generated code, migrations, vendor directories and legacy modules, so analysis shows problems in code you actually change.
• Pipeline integration scheme — where the analysis step sits, what is cached between builds, how findings get into the merge request and what exactly blocks merge.
• Finding triage regulation — who handles the flow, within what time a blocking finding is closed, when suppression is allowed with a mandatory label and review period.
• Quality reporting — export of metrics by releases: defect density, coverage, technical debt dynamics, without manual number collection.
• Operational documentation — scheme of perimeters, roles and access, procedure for updating rules and disabling analysis if it delays the build.

Case: removed defect class and reduced code debt

Before implementation: report that was bypassed

SonarQube analysis launched manually, most often on the release branch, and the Quality Gate was set to standard thresholds.

Those thresholds were useless: a rule either silently passed everything or blocked the build on formatting and disputed style rules — within a couple of months the team got used to bypassing the check.

Defect density held at 1.2 per thousand lines of new code, finding triage took up to 40 minutes per change, and code debt added 5-7% per quarter: the list grew in the report, but nobody triaged it by priority.

What was rebuilt

Assembled a rule profile for our stack — removed noisy checks, kept blocking security and reliability ones, enabled analysis only of new lines of the change so the report doesn't drown in inherited code.

Quality Gate tied to new code: coverage of new logic by tests, zero blocking findings, duplication limit. The check became a mandatory pipeline step before merge, and findings automatically got into the tracker with priority and response time by criticality level.

Metrics after

• defect density per thousand lines: 1.2 → 0.4
• finding triage time per change: 40 → 12 minutes
• build blocking share: 32% → 4%, and almost all — due to critical findings, not style
• code debt: growth stopped, over two quarters volume reduced 2.5 times

The key effect is not in the report numbers, but that critical defects stopped reaching the release branch — there were no rollbacks for reasons caught by static analysis during the observation period.

How quality gate differs from build check

Build check answers only the question "did analysis run". The step task — analyze code, collect report and save it next to the build. If the analyzer itself didn't fail, the step is considered successful even with a hundred findings: pipeline green, change goes further.

Quality gate — acceptance decision. The server calculates metrics for a specific change and compares with set boundaries: new code coverage share, number of blocking findings, duplicate volume, critical vulnerabilities. Boundaries not met — status "failed", and the version control system doesn't allow merge.

Practical detail on which whether the gate takes root depends: calculate it by new code, not the entire base. On inherited code, a condition across all files will never become green, and the team gets used to ignoring it. For old code, keep separate soft boundaries and tighten them as debts are triaged.

In SonarQube this is configured as a condition on branch or merge request plus a blocking rule on the code repository side: while status is not green, the merge button is inactive. The pipeline step gets a non-zero return code — the build stops, not just marks the report.

Common mistake — leave the check "informational": findings exist, but nobody blocks the branch. Then code acceptance criteria remain on the reviewer's conscience, and metrics gradually degrade.

The difference is simple: check shows what was found, quality gate decides whether the change gets into the main branch.

Technical doubts teams come with

Before start teams raise the same questions — a normal sign of a mature process. Collected the most common ones during methodology approval, along with answers from our engineers.

Can we describe our own rules for internal conventions?

Yes. Own rules cover what standard sets don't: ban on custom wrappers over system libraries, mandatory license headers, restrictions on accessing legacy modules. Rules live in the profile and are versioned with code.

Several perimeters — how don't they interfere with each other?

Separate projects into isolated perimeters: separate addresses, own quality gate sets, independent access tokens. Pre-release builds don't overwrite main branch reports, and a failure in one perimeter doesn't block others.

Does test code need different thresholds?

Yes, separate thresholds are mandatory. For test code, coverage and duplication are calculated differently — low values are expected there and shouldn't stop the build. Set separate quality gates so fixtures don't create false blocks.

Let's discuss the task: we'll analyze your case and come back with a plan

To make the scope estimate substantive, not "industry average", we need inputs about your code and pipeline.

The more specific the inputs, the more accurate the implementation plan and the fewer reworks along the way: the static analysis tool embeds into an existing process, not replaces it.

• repository structure: how many projects, in which languages, monorepo or a set of separate ones;
• current pipeline: what builds, which stages already exist, where the build most often fails;
• what is checked now: linters, mandatory review, manual testing — and what of this can't be disabled;
• quality requirements: which rules to consider blocking and who has the right to stop the build;
• access and environment: where the analysis service is placed, how it connects to repositories and build systems;
• operating mode: how much time the build can add, what is critical for release deadlines;
• incident history: which defects already reached production and at which stage they could have been caught.

On our side, we clarify boundaries: where trusted and untrusted builds pass, how to differentiate rights to change rules, whether a separate perimeter is needed for legacy code so it doesn't block work on new. All this affects setup depth and how many pipelines will have to be rebuilt.

We come back with a scope estimate, stage-by-stage implementation plan and pipeline analysis: which checks go where, what becomes blocking immediately, and what is introduced gradually.

Separate item — documentation handover: configurations, rules, instructions for developers and on-call.

Describe the task in free form — based on these inputs we'll assemble an estimate and come back with a work plan.