Broken pipelines for everyone!

TL;DR overview

• Sonar's research exposes how insecure CI/CD pipeline configurations—particularly in GitHub Actions—can be exploited to compromise builds, steal secrets, and gain unauthorized access to production environments.
• Common vulnerabilities include workflow script injection via unsanitized pull request titles or branch names, improperly scoped secrets, and use of third-party actions without pinning to a specific commit SHA.
• These "broken pipeline" issues are often overlooked because CI/CD configuration is treated as infrastructure rather than application code—even though it runs in a privileged context with access to production secrets.
• Teams should treat CI/CD configuration files as security-sensitive code, apply the principle of least privilege to workflow permissions, pin all external actions, and scan workflows with static analysis tools.

With SonarQube Server 8.9 LTS, SonarSource has made failing the pipeline available for everyone, using any CI you want. For people watching for a long time, this might seem like a contradiction. Let me explain.

Yes, we have gone back and forth for a while on this feature, but the user community has remained constant: you want to be able to break the build to fail your CI/CD pipelines for a failing Quality Gate.

Finally, we heard you. 

To understand what happened behind the scenes, let’s go back in history:

• We initially introduced the Build Breaker as a plugin (in 2013!), then deprecated it in 2016 for various reasons that have been detailed in a blog post by our CEO Olivier Gaudin.
• Community users picked up the plugin and started to maintain it faithfully
• Meanwhile, we introduced a proper support in for Jenkins pipelines: instead of polling your SonarQube Server instance for the Quality Gate status, we used the power of webhooks to make this operation totally asynchronous, separating the build pipeline (where the analysis takes place) from the release pipeline (where you decide if your code should make it to production, or not).
  The same kind of implementation can be found today in Azure DevOps with SonarQube Cloud: we rely on the Release Gate feature to be able to detect the Quality Gate status during the release pipeline, leaving the build pipeline doing the analysis job (and failing only if the analysis fails).
• As reality is sometimes tougher than we expect, we kept receiving dozens of requests regarding scenarios we couldn’t even imagine - scenarios that required users to stop the build pipeline when the SonarQube Server quality gate fails - while our progress toward a good implementation for CIs other than Jenkins crumbled.
• Eventually we quietly released a custom solution for GitLabCI based on the “polling” approach, as a workaround.
• As time went by and the demand for this feature remained constant, we finally recognized the validity of the use case, especially in light of increasing use of  automation and continuous delivery in the industry as a whole. 

So yes, this is not the perfect solution we imagined for you. But at least it’s a solution. And, we'll keep trying to implement what we think is the best approach: a total decorrelation between the analysis status and the Quality Gate status. This type of full decorrelation will allow you to build your code properly and decide later, during the release stage, whether to deploy your code or not.

So from 8.9, it is available for everyone with the sonar.qualitygate.wait parameter.

There are a few things to note, however:

• In consultation with its maintainers, the BuildBreaker plugin compatibility officially ended.
• Using sonar.qualitygate.wait  has significant drawbacks: 
  The use of this parameter will make the analysis step of your pipeline poll your SonarQube Server instance (your worker will keep sending requests) to retrieve the Quality Gate status.
  This may increase the load of your instance, and increase your pipeline duration (which could be important if your infrastructure price is based on the total pipeline duration).
  This will cause the analysis step to fail any time the Quality Gate fails, even if the actual analysis is successful.

As you all know, with great power comes great responsibility, so please use this parameter wisely. And in the meantime, rest assured that we will keep trying to offer what we believe to be the best solution possible for you, our users.

--

Something to add? Join us in the community!