First let me explain our use case:
- Our security department defines security-relevant rules that must be part of every scan
- For every language we have a related quality profile named
XXX <Language> Security
- All rules in a security profile are activated with severity CRITICAL to better distinguish them from other rules (the old severities will return with Sonarqube 10.8 )
- If new rules are activated in a security profile, we start with severity INFO for a grace period of 2 weeks, to see if any problems with the new rule - afterwards switch to CRITICAL
- every
XXX <Language>
quality profile created by the Sonarqube admins contains the
related security profile as subset
We encourage our developers to create and use their own quality profiles and quality gates.
This is very well received, as teams have different requirements and demands.
They are also more motivated if they can decide for themselves how extensively they want to use Sonarqube.
We have a pragmatic agreement with our security department:
- A self created quality profile must at least contain the rules of the
XXX <Language> Security
profile or use the security profile as is - A self-created quality gate must contain the condition violation if CRITICAL issues > 0
on overall code (for legacy projects on new code, but existing critical issues are reviewed)
Current workflow
- A team requests a new quality profile from us Sonarqube admins
It maybe a copy of aXXX <Language>
profile, but some want to start with a copy of
the builtin Sonar way profile containing much more rules or a profile from another team.
To ensure that all rules from the associated profileXXX <language> Security
are included, we need to compare the new profile against it and add missing rules. - Some members or the whole team gets permissions for managing the quality profile
- A team requests a new quality gate from us Sonarqube admins
- Some members or the whole team gets permissions for managing the quality gate
- To ensure that all requirements are met, we have to regularly review the quality profiles and quality gates
A prioritized rules feature was introduced some time ago, see
but in my opinion that falls short.
An administrative framework for mandatory rules and conditions would considerably simplify our workflow and make it more secure.
It should work like that
Quality profiles
- A configurable quality profile is always injected as subset when a new quality profile is created, regardless of whether it is a new / copied or extended profile
- The injected rules are immutable (but they may change when the configured profile is edited by the admins)
- A change in the configured profile is automatically applied to all profiles
- Every quality profile inherits from the configured
To create a new quality profile, we use the “Copy existing profile” option so that teams can also deactivate rules (there are also non mandatory rules with serverity != CRITICAL). 1. could be achieved via always extending the XXX <Language> Security
profile. But many teams want to start with a copy from ‘Sonar way’ and that means we need to compare the new profile against the security profile and add missing rules / adjust the severities if already contained with a severity != CRITICAL
Quality Gate
- A configurable condition is always injected in a new quality gate
This is similar to current behaviour, when creating a new quality gate several conditions are already set - but this should be configurable. - The injected condition is immutable
- A change in the configured condition is automatically applied to all quality gates
This ensures that all specifications are always adhered to.
As the configured rules and conditions are unchangeable, random checks are no longer required.
I hope I have explained the use case clearly enough.