Using SonarQube Leak Period to Isolate New Code Issues in CI

The problem: legacy debt drowns out new issues

When a SonarQube project has years of existing violations, the Overall issue count can mask regressions introduced by recent changes. Teams end up chasing old debt or ignoring fresh problems because dashboards show a noisy mix of both.

Thesis: Leak Period creates a "new code" view

SonarQube’s Leak Period feature defines a reference point (e.g., the previous analysis) and separates issues into Overall (all time) and New Code (since the reference). Quality gates can then be applied to the New Code block, giving teams a clear signal about the quality of recent work.

How Leak Period works

Leak Period relies on the project’s SCM binding to determine what changed since the last analysis. If SonarQube can query the repository, it marks lines added or modified after the reference as "new". Issues on those lines appear in the New Code section; everything else stays in Overall.

To enable it you must:

1. Ensure SCM integration is active (sonar.scm.provider set to git, svn, etc.).
2. Grant the SonarQube server read access to the repository (SSH key, token, or credentials).
3. Pick a leak period mode, most commonly since_last_analysis or a fixed date.

Worked example: Maven project with since_last_analysis

Assume a Maven project hosted on GitHub, already analyzed with SonarQube. We want the next CI run to treat only changes since the last build as new code.

# In your CI pipeline (e.g., GitHub Actions)
mvn clean verify sonar:sonar \
  -Dsonar.projectKey=myorg:myapp \
  -Dsonar.host.url=https://sonarqube.example.com \
  -Dsonar.login=$SONAR_TOKEN \
  -Dsonar.leak.period=since_last_analysis

Where:

• $SONAR_TOKEN is a user token with Analysis permission.
• The Maven sonar:sonar goal invokes sonar-scanner under the hood.

After the analysis finishes, open the project in SonarQube and navigate to Measures. You should see two rows:

• Overall – total issues across the entire codebase.
• New Code – issues only on lines added or changed since the previous analysis.

If you introduced a new blocker (e.g., a hard‑coded secret) in a pull request, the New Code count will increase by one while Overall may stay unchanged.

Verification steps

1. UI check: Project → Measures → Leak Period. The label should read "since_last_analysis" and the New Code block should be visible.
2. Console log: Look for a line like Leak period set to: since_last_analysis in the scanner output.
3. Issue comparison: Make a known change (add a TODO comment), rerun the analysis, and confirm that the New Code count rises by exactly the number of issues tied to that change while Overall remains stable.

Trade‑off and limitation

Leak Period is only as reliable as the SCM binding. If the server cannot reach the repository (network issue, missing credentials, or disabled SCM), SonarQube falls back to "no SCM" mode. In that state the leak period cannot distinguish new vs. old lines, and all issues appear in Overall, potentially hiding regressions.

Additionally, setting an extremely short leak period (e.g., since_last_commit on a very busy branch) can cause metric churn: the reference moves so fast that trends in New Code become hard to interpret. Teams should pick a period that matches their feedback loop—usually the previous analysis or the start of a feature branch.

Actionable closing

To start using Leak Period today:

1. Verify SCM connectivity in SonarQube under Administration → Configuration → SCM.
2. Add -Dsonar.leak.period=since_last_analysis to your analysis command.
3. Update your quality gate to fail on New Code blocker or critical issues.
4. Monitor the New Code trend over several builds to ensure it reflects real improvement.

With this setup, your team can focus on fixing what they actually introduced, keeping technical debt visible but not overwhelming.