Rules, Rule Types, Severities, Quality Profiles, and Customization: Diagnostics, Failure Modes, and Production Practices

1. Evidence-first sequence

1. Preserve scanner logs, report-task.txt, CE task, issue/gate state, profile exports/screens and change records.
2. Confirm exact product edition/version, scanner, Java runtime, analyzer/plugin versions and instance mode.
3. Confirm source revision, base directory, indexed files and SCM state.
4. Confirm default versus explicit profile assignment for each language.
5. Inspect exact rule key/repository/status, activation, inheritance/override and parameters.
6. Confirm CE terminal status before interpreting results.
7. Inspect gate/new-code policy only after analysis policy is proven.
8. Inspect auth/network/database/search/JVM/container layers only when evidence points there.
9. Apply the least-destructive correction and rerun the same representative revision.

2. Symptom → evidence, not guess

3. Intentionally broken example: “green by removing the check”

The lab function raises S3776 under threshold 3. An operator deactivates S3776 in the child profile and points to the lower issue count as an improvement.

Same revision + S3776 active(threshold=3)   → issue present
Same revision + S3776 deactivated           → issue absent

The second line proves policy removal, not cleaner source.

Preserve both profile states and task IDs. Repair by restoring the rule/parent definition, then decide separately whether threshold 3 is justified. Never delete issue history to hide the experiment.

4. Failure: severity used as exploitability or developer grading

Sonar severity does not prove that a particular vulnerability is exploitable in your deployment and is not a developer score. Issue counts and severity can move because source scope, rule policy, analyzer versions and SCM attribution change. Keep security/business triage separate from rule-profile semantics.

5. Failure: uncontrolled profile sprawl

Red flags include nearly identical copies, unknown owners, stale rules, unexplained thresholds and projects pinned to obsolete profiles. Diagnose by inventorying/exporting profiles, parent relationships, overrides and project associations. Consolidate only after mapping blast radius.

6. Failure: changing a language default without ownership

A default-profile edit or replacement can affect every project without an explicit association. Production practice requires an affected-project inventory, owner, change window, representative before/after analyses, communication and rollback profile before making the change.

7. Failure: ignoring new/deprecated rules after analyzer upgrades

Analyzer upgrades can add rules, deprecate existing rules, change defaults or improve implementations. Sonar-way children can inherit parent evolution; copied/blank profiles do not automatically gain the same policy updates. Review new/deprecated rules and child overrides after every upgrade before interpreting trend changes as source-quality changes.

8. Keep failure layers separate

Do not respond to a profile problem with direct DB/search edits, cache/log deletion, TLS disablement, admin tokens everywhere, unsupported downgrade or a new project key.

9. Production runbook

1. Freeze the representative source revision.
2. Preserve scanner/report-task/CE/issues/gate evidence.
3. Export/record old and new profile states.
4. Compare server + analyzer/plugin + mode changes.
5. Diff active rule keys, deprecated/new rules and overrides.
6. Restore only the incorrect profile/default/association change.
7. Rerun the same revision and preserve new task evidence.
8. Revisit issue/gate workflow only after analysis policy is correct.

10. Challenge: upgrade-driven issue spike

Forty projects gain maintainability issues after an analyzer upgrade. Revisions/scanners are unchanged. Half use Sonar-way children; half use old copied profiles. First compare analyzer versions and current Sonar way, then child inheritance versus copied-profile active rules/overrides. Do not mass-suppress findings before identifying the policy delta.

Knowledge check

Official references and version notes

• Community Build — SonarQube rules — repositories, statuses, rule categories, custom/template rules and mode-dependent severity semantics.
• Community Build — Instance mode overview, including MQR Mode and Standard Experience.
• Community Build — Understanding quality profiles — built-in/default profiles, inheritance, overrides and project association.
• Community Build — Creating a quality profile — Extend, Copy, blank creation and import/export.
• Community Build — Editing a custom quality profile — activate/deactivate rules, customize parameters and Revert to Parent Definition.
• Community Build — Associating a quality profile with projects.
• Sonar Rules — Python S3776 — Cognitive Complexity rule used in the controlled parameter experiment.
• SonarQube releases — current Community Build and Server release identities.