SonarQube Issues Bugs Smells Vulnerabilities
An issue is a specific problem that SonarQube finds in your code. Every scan produces a list of issues. This topic explains the four types of issues, severity levels, how to work with issues, and how to manage their lifecycle.
The Four Issue Types
ISSUE TYPES IN SONARQUBE +---------------------+------------------------------------------+ | TYPE | MEANING | +---------------------+------------------------------------------+ | Bug | Code that produces wrong behavior | | Vulnerability | Code that creates a security risk | | Code Smell | Code that works but is hard to maintain | | Security Hotspot | Code to review manually for safety | +---------------------+------------------------------------------+
Bugs
A bug is code that will cause incorrect or unexpected behavior when the program runs. SonarQube finds bugs through pattern analysis — it recognizes common programming mistakes without executing the code.
Bug Example: Null Pointer
// PROBLEMATIC CODE
String name = user.getName();
if (name.length() > 0) { // BUG: name could be null
display(name);
}
// FIXED CODE
String name = user.getName();
if (name != null && name.length() > 0) {
display(name);
}
If getName() returns null, the original code crashes. SonarQube detects this pattern and flags it as a bug.
Vulnerabilities
A vulnerability is a flaw that an attacker can exploit to gain unauthorized access, steal data, or disrupt service. SonarQube checks for common vulnerability patterns from security standards like OWASP Top 10 and CWE.
Vulnerability Example: SQL Injection
// VULNERABLE CODE
String query = "SELECT * FROM users WHERE id = " + userId;
ResultSet rs = stmt.executeQuery(query); // VULNERABILITY
// SAFE CODE
PreparedStatement ps = conn.prepareStatement(
"SELECT * FROM users WHERE id = ?");
ps.setInt(1, userId);
ResultSet rs = ps.executeQuery();
The vulnerable code lets an attacker pass 1 OR 1=1 as the userId to retrieve all records in the table.
Code Smells
A code smell does not break the program today, but it makes the code harder to understand, modify, or test. Left untreated, code smells accumulate and eventually make the codebase painful to work with.
Code Smell Example: Giant Method
// CODE SMELL: This method has 300 lines
public void processOrder(Order order) {
// 50 lines of validation
// 80 lines of inventory check
// 60 lines of payment processing
// 70 lines of shipping calculation
// 40 lines of email notification
}
// BETTER: Split into focused methods
public void processOrder(Order order) {
validateOrder(order);
checkInventory(order);
processPayment(order);
calculateShipping(order);
sendConfirmation(order);
}
The split version is much easier to test and modify because each method has one job.
Security Hotspots
A security hotspot is a code pattern that is potentially risky but not necessarily a vulnerability. SonarQube cannot determine on its own whether the code is safe or not — a human developer must review it and make that judgment.
Security Hotspot Example: Random Number
// HOTSPOT: Is this random number used for security? Random r = new Random(); int token = r.nextInt(1000000);
If this token is used for a session ID, it is insecure because java.util.Random is predictable. If it is used to generate a random quiz question number, it is perfectly fine. SonarQube flags it as a hotspot and asks a developer to check the intent.
Issue Severity Levels
SEVERITY MEANING ACTION -------- ------- ------ Blocker Will definitely cause a problem Fix before merge Critical Very likely to cause a problem Fix before merge Major Could cause a problem in some cases Fix this sprint Minor Low risk, coding standard issue Fix when possible Info Informational only Review if time allows
The Issue Lifecycle
[OPEN] | |-- Developer reviews it | +--[CONFIRMED] -- Developer agrees it is a real issue | +--[RESOLVED (Fixed)] -- Developer fixed the code | | | v | [CLOSED] -- Next scan verifies the fix | +--[RESOLVED (Won't Fix)] -- Team decides to accept the risk | +--[RESOLVED (False Positive)] -- SonarQube was wrong; not a real issue
Assigning Issues
Team leads can assign issues to specific developers directly in the SonarQube interface. The assigned developer receives an email notification and can see their assigned issues in a filtered view. This turns SonarQube from a reporting tool into a lightweight task management system for code quality work.
Adding Comments to Issues
Any team member can add a comment to an issue to explain a decision, ask a question, or provide context. This is useful when marking an issue as Won't Fix — the comment explains why the team accepted the risk.
False Positives
SonarQube sometimes flags code that is actually correct. This happens because static analysis applies general rules and cannot always understand the specific context of your project. When you find a false positive:
- Open the issue in SonarQube
- Click Won't Fix or False Positive
- Add a comment explaining why this is not a real issue
Future scans will not reopen issues you have marked as false positive unless you resolve and reopen them manually.
Bulk Issue Management
On the Issues page, select multiple issues using the checkboxes, then use the Bulk Change button to assign, resolve, or comment on all selected issues at once. This saves significant time when a single rule change produces hundreds of similar issues across the project.
ISSUES PAGE: BULK CHANGE +-------------------------------------------------+ | [x] Issue 1: Hardcoded password in Config.java | | [x] Issue 2: Hardcoded password in Setup.java | | [x] Issue 3: Hardcoded password in Test.java | | | | [Bulk Change ▼] | | Assign to: [Dev Name] | | Status: Won't Fix | | Comment: Legacy test credentials, not in prod | | [Apply] | +-------------------------------------------------+
Effort and Technical Debt
Every rule in SonarQube has an associated remediation time — the estimated time to fix one instance of that issue. SonarQube adds up all remediation times across all code smells and calls the total your project's technical debt.
Technical debt is displayed in hours or days. It gives management a concrete number to understand how much work is needed to clean up the codebase.
TECHNICAL DEBT EXAMPLE +--------------------------------------+ | Code Smells: 47 | | Total Debt: 4 days 3 hours | | | | Breakdown: | | - Cognitive complexity issues: 2d | | - Method length issues: 1d | | - Naming issues: 6h | +--------------------------------------+