Trying to write Targeted Custom Rules in SonarQube to Build Early-Stage DevSecOps Adoption

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • which versions are you using :Community Build
  • how is SonarQube deployed: Docker

I am trying to create our internal DevSecOps adoption, and I want to share the thought process behind a new idea I am experimenting with.

From my perspective as an SOC engineer and a you-know-nothing-john-snow DevSecOps engineer, SonarQube Community Edition is powerful enough for creating meaningful custom rules.

However, I have been struggling with two major issues: the default rule set generates too many false positives, and developers are not yet culturally comfortable with the idea of DevSecOps. Because of this, pushing security into the SDLC has been kinda difficult. Developers often feel that security is blocking delivery, and the feedback they get from scanning tools looks noisy, unrelated, or too theoretical.

To improve trust and reduce friction, I am trying to start with something highly aligned with our real-world pain: building custom rules that detect only the vulnerabilities that have caused urgent incidents in the past. These are issues that both developers and operations already know well, such as misconfigurations, historical framework vulnerabilities, dangerous dependencies, or hardcoded credentials. Examples include hardcoded Access Keys, Log4j2 RCE, Struts2 RCE, fastjson unsafe versions, wrong version middleware that allow default passwd etc.

These incidents actually hurt, the risk is obvious to everyone, and the remediation path is already known. If we can automatically detect these specific patterns in code, it will be much easier to get developers to accept scanning as a useful quality gate instead of an abstract security requirement. This step could help us build credibility and demonstrate that DevSecOps can directly prevent the exact problems that kept.

Problem I already notice:

As a SOC team member, I really care about SCA, application‑level vulnerabilities, and what SonarQube focuses on as a SAST tool seem quite different

But the idea of using SonarQube as a CI/CD gate to block code releases actually makes a lot of sense to me.

Anyway, I m wondering if anyone could share some experience building DevSecOps at early phases

2

Hi,

I’d like to challenge a couple of your assertions.

SonarQube Community Build is a great product and provides tremendous value. And as a security professional, you should be targeting SonarQube Server Developer Edition($) at minimum to get taint analysis. Bump that up to Enterprise Edition($$), and you add on things like reporting and defining custom secret patterns (i.e. the custom rules you’re talking about writing without actually having to write and maintain a custom plugin.) There’s another tier beyond that that adds SCA, “advanced SAST”, and license management.

But don’t use Community Build and think you’re ticking the security box. :woman_shrugging:

Really? Are they false positives or just issues your developers don’t like / care about? If the former, we’d love you to report them here (one thread per FP, please) so we can get them fixed. If the latter, then it sounds like you need a custom quality profile so the rules your organization doesn’t agree with aren’t applied.

 
Ann

3

Well I’m fully aware of the advantages of Developer and Enterprise editions. But it’s not that simple. We need to demonstrate ROI before securing budget for security team. The key is whether this cost has helped avoid future incidents and how much risk can be avoided, which is difficult to quantify, and the incidents occurred in the past have been primarily misconfigurations. Leaderboard requires evidence of value before approving paid tooling spend, that’s why we’re using Community edition to build DevSecOps CICD pipeline and reject unsafe merge, and prove the business case for upgraded editions. So it’s not about checking boxes, it’s trying to be pragmatic within current constraints, step by step.

You’re absolutely right that resistance from developers not prioritizing security issues, especially under aggressive agile delivery pressure. I think consensus is the core of DevSecOps in my current situation, and I’m addressing this through gradual rule enablement with training and consensus-building. Our custom frameworks handle certain security patterns automatically, which current rules don’t recognize(not your problem, it’s our problem). When scanning large legacy codebases, even valid issues create overwhelming volume that paralyzes action rather than enabling it.

I am creating custom quality profiles as you suggested, conducting rule-by-rule reviews to distinguish genuine false positives from legitimate issues, and implementing progressive enforcement starting with critical security rules. Where we identify true false positives, we’ll document and report them properly.

I’d welcome your recommendations on which critical security rules to prioritize in Community Edition for maximum impact. We hope to become paid customers once we’ve built the foundation to use those capabilities effectively.

In terms of SCA, I found a Dependency-Check Plugin for SonarQube that can parse Dependency-Check json reports and display them in the SonarQube. I’m exploring whether this provides a viable free solution to address the SCA vulnerability gap while we work toward justifying paid editions.

1 Like
4

Hi,

I would just focus on the security-related rules, sorted by severity. Note that given your situation I would omit any Security Hotspot rules. Security Hotspots are what I think of as Schroedinger’s Vulnerabilities: there might be a problem, there might not; you won’t know until you look. That’s because they all involve situations where human judgement is require to assess the circumstances.

I understand that when a Blocker Bug is raised, you can’t ignore it, but once anything scary in the backlog is caught up, a focus on new code can really help you manage the volume, particularly in legacy code bases.

Thanks! This will be very helpful.

 
Ann