IntermediateLesson 4

Code Smells, Bugs & Vulnerabilities

ELI5 Explanation

SonarQube sorts problems into three bins: things that will break (bugs), things that could be attacked (vulnerabilities), and things that are messy and slow the team down (code smells). Each needs a different response.

Technical Explanation

SonarQube classifies every finding into one of three issue types:

Bug: logic or runtime issues likely to cause incorrect behavior. Example: null pointer dereference, incorrect operator, unreachable code.
Vulnerability: security weakness attackers can exploit. Example: SQL injection path, hardcoded credential, weak cipher use.
Code Smell: maintainability problems that increase technical debt. Example: overly long methods, duplicate logic, excessive cyclomatic complexity.

Each issue also carries a severity: Blocker, Critical, Major, Minor, Info — and a remediation effort estimate in minutes or hours.

Warning: Code smells feel low priority but are the leading cause of delivery slowdowns. Ignored long enough, they become bugs.

Visual

Bugs
(Reliability)

Vulnerabilities
(Security)

Code Smells
(Maintainability)

→

Quality Rating A–E

Hands-on Commands

Query SonarQube API for issue types

# List open bugs for a project
curl -u $SONAR_TOKEN: \
  "http://localhost:9000/api/issues/search?projectKeys=my-app&types=BUG&statuses=OPEN"

# List critical vulnerabilities
curl -u $SONAR_TOKEN: \
  "http://localhost:9000/api/issues/search?projectKeys=my-app&types=VULNERABILITY&severities=CRITICAL,BLOCKER"

# List code smells by effort
curl -u $SONAR_TOKEN: \
  "http://localhost:9000/api/issues/search?projectKeys=my-app&types=CODE_SMELL&s=FILE_LINE"

Debugging Scenario

A Critical bug reported by SonarQube — unreachable exception handler — is dismissed by the developer as "never triggers in production." Six months later, an edge case input hits that path and causes a service crash. Treat Blocker and Critical bugs as must-fix before merge. Most SonarQube bug rules are based on patterns proven to cause production issues.

Interview Questions

Beginner

What is the difference between a bug, vulnerability, and code smell?
What does severity Blocker mean?
Why does SonarQube rate maintainability separately from reliability?
What is remediation effort?
Can SonarQube miss real bugs?

Intermediate

How would you configure a quality gate to block only on bugs and vulnerabilities?
How do you handle massive code smell backlogs without losing momentum?
What is cyclomatic complexity and how does it relate to code smells?
How do you use SonarQube ratings (A–E) in SLA conversations?
How do you distinguish a SonarQube vulnerability from a Veracode finding?

Scenario-based

Team has 1200 code smells. How do you prioritize cleanup across sprints?
A critical vulnerability is disputed by developer as false positive. What process do you follow?
Project jumps from Rating B to E overnight. What might have happened?
Product wants zero smells policy. Why might this backfire?
New joiner introduces 40 new issues in one PR. How do you handle it constructively?

Real-world Use Case

An enterprise API team reduced severity-Blocker issues from 90 to 0 in one sprint by focusing only on new issues in each PR, letting background debt cleanup happen in parallel through quarterly tech debt sprints.

Summary

Bugs, vulnerabilities, and code smells all need different handling speeds and strategies. Next lesson teaches you how Quality Gates enforce minimum standards before code reaches any environment.

PreviousStatic Code Analysis NextQuality Gates & Profiles