Guides

How to Use SonarQube for Code Analysis (Community Build, Step by Step)

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 16 October 2026 · Last updated: 17 October 2026

To use SonarQube for code analysis, start the server (the quickest way is docker run -d -p 9000:9000 sonarqube:community), create a project and an analysis token, and run the scanner for your language from your project folder. SonarQube then shows bugs, vulnerabilities, security hotspots and code smells. Add a quality gate to CI so new code with serious issues cannot be merged.

docker run -d --name sonarqube -p 9000:9000 sonarqube:community
# open http://<server>:9000, log in admin/admin, change the password,
# create a project "orders-api" and a token, then from the project folder:
mvn clean verify sonar:sonar -Dsonar.projectKey=orders-api \
  -Dsonar.host.url=http://<server>:9000 -Dsonar.token=<token>

A live example first

We run SonarQube on a t3.medium EC2 instance (it needs about 2 GB of RAM; a t2.micro is too small), in a private subnet reached over a VPN.

1. Set the kernel value that Elasticsearch inside SonarQube needs, then start it:

sudo sysctl -w vm.max_map_count=524288
docker run -d --name sonarqube -p 9000:9000 sonarqube:community
docker logs -f sonarqube | grep -m1 "SonarQube is operational"

2. Open http://<private-ip>:9000, log in with admin / admin, and set a new password when asked.
3. Click Create project → Local project, name it orders-api, and pick "Use the global setting" for new code.
4. Choose Locally, generate a token, and choose your build tool.

Now we scan a small Spring Boot app that has this method:

String sql = "SELECT * FROM orders WHERE customer = '" + name + "'";
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery(sql);

mvn clean verify sonar:sonar -Dsonar.projectKey=orders-api \
  -Dsonar.host.url=http://10.0.2.15:9000 -Dsonar.token=sqp_xxx

The project page shows 1 Vulnerability (or a Security Hotspot, depending on the rules) on that line, with a message along the lines of "Change this code to not construct SQL queries directly from user-controlled data." We change it to a PreparedStatement with ? and scan again. The finding disappears and the quality gate shows Passed. Friends, the tool explained the risk in plain words and pointed to the exact line.

How does SonarQube work?

There are two parts. The server stores rules, history and results and shows the web UI. The scanner runs where your code is (your laptop or a CI runner), reads the code, and sends a report to the server. The server then applies the quality gate. The default gate, "Sonar way", focuses on new code, so an old project can start today without fixing ten years of issues first.

What the results mean

Scan each language

Java (Maven or Gradle)

mvn clean verify sonar:sonar -Dsonar.projectKey=orders-api -Dsonar.token=$SONAR_TOKEN

For Gradle, add the org.sonarqube plugin and run ./gradlew sonar. Add JaCoCo to get coverage.

.NET

dotnet tool install --global dotnet-sonarscanner
dotnet sonarscanner begin /k:"billing-api" /d:sonar.host.url="http://10.0.2.15:9000" /d:sonar.token="$SONAR_TOKEN"
dotnet build
dotnet sonarscanner end /d:sonar.token="$SONAR_TOKEN"

Node.js / TypeScript, Python, PHP, Go and Ruby (sonar-scanner CLI)

Create sonar-project.properties in the project root:

sonar.projectKey=web-frontend
sonar.sources=src
sonar.exclusions=**/node_modules/**,**/vendor/**
sonar.javascript.lcov.reportPaths=coverage/lcov.info

Then run the scanner in Docker so you do not install anything:

docker run --rm -e SONAR_HOST_URL=http://10.0.2.15:9000 -e SONAR_TOKEN=$SONAR_TOKEN \
  -v "$PWD:/usr/src" sonarsource/sonar-scanner-cli

Add the quality gate to CI

GitHub Actions

- uses: SonarSource/sonarqube-scan-action@v4
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
- uses: SonarSource/sonarqube-quality-gate-action@v1
  timeout-minutes: 5
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Jenkins

Install the SonarQube Scanner plugin, then use withSonarQubeEnv('sonar') { sh 'mvn sonar:sonar' } followed by waitForQualityGate abortPipeline: true.

Keep SonarQube itself secure

1. Change the default admin password on first login.
2. In Administration → Security, turn on Force user authentication.
3. Keep it in a private subnet, reached through a VPN or bastion.
4. Use project tokens in CI, stored as CI secrets, never in the repo.
5. Use PostgreSQL for anything beyond a lab (the built-in H2 database is for evaluation only).

Real example

In October 2020 the FBI published a flash alert saying that attackers had been stealing source code from US government agencies and companies through SonarQube servers exposed to the internet with default settings, such as the default admin password. A tool meant to make code safer leaked it instead. That is why step 1 above is "change the password" and step 3 is "keep it private".

Mistakes to avoid

1. Gating on overall code on day one. The project fails forever. Gate on new code.
2. Marking every hotspot "Safe" without reading. Each one needs a short reason.
3. Thinking SonarQube replaces other tests. Pair it with dependency scanning (Trivy) and DAST in staging.

Summary table