How To Build A Bulletproof SonarQube Code Security Platform On AWS: Zero To HTTPS In 8 Steps + Video

Introduction:

SonarQube is an open‑source platform for continuous code quality inspection that automatically detects bugs, security vulnerabilities, and code smells across 20+ programming languages. In modern DevSecOps pipelines, integrating SonarQube with HTTPS‑protected access, a reverse proxy, and a dedicated PostgreSQL database ensures that code analysis becomes a non‑negotiable security gate before deployment. This article walks through a production‑ready SonarQube deployment on Ubuntu 22.04 (AWS EC2) with a custom domain, SSL/TLS encryption, and actionable hardening techniques—transforming a simple code scanner into a hardened security control.

Learning Objectives:

Deploy SonarQube 9.x+ on Ubuntu with PostgreSQL, Nginx reverse proxy, and Let’s Encrypt SSL.
Apply Linux system hardening, user isolation, and firewall rules to protect the analysis platform.
Integrate SonarQube into CI/CD pipelines using Quality Gates and API tokens for automated vulnerability scanning.

You Should Know

Extended Deployment Blueprint: From Server Prep to Secure Domain

This section expands the original LinkedIn project with additional validation steps and security checks. The following commands assume a fresh Ubuntu 22.04 instance on AWS (t2.medium or larger recommended, with at least 4GB RAM).

Step‑by‑step guide:

 1. System update and install dependencies
sudo apt update && sudo apt upgrade -y
sudo apt install -y openjdk-17-jdk postgresql postgresql-contrib nginx certbot python3-certbot-nginx wget unzip

<ol>
<li>Configure PostgreSQL (create dedicated database and user)
sudo -u postgres psql <<EOF
CREATE USER sonar WITH PASSWORD 'StrongP@ssw0rd!';
CREATE DATABASE sonar OWNER sonar;
GRANT ALL PRIVILEGES ON DATABASE sonar TO sonar;
EOF</p></li>
<li><p>Download and extract SonarQube (community edition)
cd /opt
sudo wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-9.9.8.100196.zip
sudo unzip sonarqube-9.9.8.100196.zip
sudo mv sonarqube-9.9.8.100196 sonarqube</p></li>
<li><p>Create dedicated sonarqube user (security best practice)
sudo useradd -r -m -U -d /opt/sonarqube -s /bin/bash sonarqube
sudo chown -R sonarqube:sonarqube /opt/sonarqube</p></li>
<li><p>Edit SonarQube properties (/opt/sonarqube/conf/sonar.properties)
sudo nano /opt/sonarqube/conf/sonar.properties
Uncomment and set:
sonar.jdbc.username=sonar
sonar.jdbc.password=StrongP@ssw0rd!
sonar.jdbc.url=jdbc:postgresql://localhost:5432/sonar
sonar.web.port=9000
sonar.web.host=127.0.0.1 (bind to localhost only, Nginx will proxy)</p></li>
<li><p>Create systemd service
sudo tee /etc/systemd/system/sonarqube.service > /dev/null <<EOF
[bash]
Description=SonarQube service
After=network.target postgresql.service</p></li>
</ol>

<p>[bash]
Type=forking
User=sonarqube
Group=sonarqube
ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh start
ExecStop=/opt/sonarqube/bin/linux-x86-64/sonar.sh stop
LimitNOFILE=65536
LimitNPROC=4096
Restart=on-failure

[bash]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable sonarqube
sudo systemctl start sonarqube

After starting, verify with `sudo systemctl status sonarqube` and test locally: `curl http://localhost:9000` (should return SonarQube HTML).

Linux Hardening for SonarQube: System Limits, Permissions, and Firewall

Without proper system tuning, SonarQube will fail with “max virtual memory areas vm.max_map_count is too low”. Additionally, expose only necessary ports.

Step‑by‑step guide:

 Increase memory map count (persistent)
echo "vm.max_map_count = 262144" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Increase open file limits for sonarqube user
echo "sonarqube soft nofile 65536" | sudo tee -a /etc/security/limits.conf
echo "sonarqube hard nofile 65536" | sudo tee -a /etc/security/limits.conf

Configure UFW firewall (allow only SSH, HTTP, HTTPS)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Verify no direct 9000 access from outside (SonarQube listens on 127.0.0.1)
sudo ss -tlnp | grep 9000  should show 127.0.0.1:9000

Why this matters: Binding SonarQube to localhost prevents external attackers from bypassing Nginx authentication or SSL. The firewall ensures only HTTP/HTTPS front‑end access.

Securing SonarQube Itself: Default Credentials, API Security, and RBAC

Out‑of‑the‑box, SonarQube uses admin/admin. Attackers frequently scan for default credentials. Also, API tokens can be leaked in CI logs.

Step‑by‑step guide:

First login – Access your domain (e.g., https://codequality.yourdomain.com`), log in withadmin/admin`, and immediately change the password to a strong, unique value.
Disable default admin user (optional but recommended) – Create a new administrator account, then deactivate the built‑in admin.
Generate CI/CD tokens with minimal scope – Go to My Account → Security → Generate Token. Use tokens only for analysis, never for admin operations.

Example token usage in pipeline:

sonar-scanner -Dsonar.host.url=https://codequality.yourdomain.com \
-Dsonar.login=$SONAR_TOKEN

Enforce RBAC – Create groups (developers, lead-developers, qa) and assign permissions:

– Developers: Browse, `See Source Code`
– CI/CD bots: Execute Analysis, `View Quality Gates`
– No one except admins can administer the system.

API security – Restrict API access to trusted IPs via Nginx (add this inside your server block):

location /api {
allow 10.0.0.0/8;  Your internal VPC CIDR
allow 192.168.1.0/24;  Office VPN
deny all;
proxy_pass http://localhost:9000;
}

Cloud Hardening on AWS: Security Groups, IAM, and VPC Configuration

Your Ubuntu server likely runs on EC2. Even with a domain and SSL, the underlying cloud network must be locked down.

Step‑by‑step guide:

Security Group (attached to the EC2 instance):
Inbound: Only allow TCP/22 (your office IP), TCP/80, TCP/443 (0.0.0.0/0 only if you need public web access).
Outbound: Allow all (or restrict to PostgreSQL, GitHub, etc.).
IAM Role for EC2 – Create a role with least privilege for any automation (e.g., pulling secrets from AWS Secrets Manager). Never store database passwords in `sonar.properties` as plain text. Instead, use:
```
Install AWS CLI, then retrieve secret at boot
export DB_PASS=$(aws secretsmanager get-secret-value --secret-id sonar-db-pass --query SecretString --output text)
```
VPC Configuration – Place the EC2 instance in a private subnet if possible, and use a load balancer or NAT gateway. For this project, a public subnet is acceptable if the security group is restrictive.

Backup strategy – Automate EBS snapshots or use `pg_dump` to S3 daily:

sudo -u postgres pg_dump sonar > /tmp/sonar_backup.sql
aws s3 cp /tmp/sonar_backup.sql s3://your-backup-bucket/sonar/$(date +%F).sql

Integrating with CI/CD Pipelines: Jenkins, GitLab, GitHub Actions

The real value of SonarQube appears when every pull request triggers a scan and Quality Gate evaluation. Below is a GitHub Actions workflow that fails the build if new bugs or vulnerabilities exceed the threshold.

Step‑by‑step guide (GitHub Actions example):

name: SonarQube Scan
on:
pull_request:
branches: [ main ]

jobs:
sonar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0  Shallow clones break SonarQube's blame information
- name: Set up JDK 17
uses: actions/setup-java@v3
with:
java-version: 17
- name: Cache SonarQube packages
uses: actions/cache@v3
with:
path: ~/.sonar/cache
key: ${{ runner.os }}-sonar
- name: Run SonarQube Scanner
env:
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
run: |
sonar-scanner \
-Dsonar.projectKey=my-app \
-Dsonar.sources=. \
-Dsonar.host.url=$SONAR_HOST_URL \
-Dsonar.login=$SONAR_TOKEN \
-Dsonar.qualitygate.wait=true

Quality Gate setup – In SonarQube UI, go to Quality Gates and create a gate that fails on:
– New Security Rating > A
– New Bugs > 0
– New Vulnerability > 0
– New Code Smells > 5%

Integrate with PR comments using the SonarQube GitHub plugin.

Vulnerability Exploitation and Mitigation: What Attackers Look For

Misconfigured SonarQube instances are a goldmine for attackers. Common exploitation paths include:

Default credentials → Admin access → Read all source code (including secrets hardcoded in repos) → Lateral movement.
Unauthenticated API endpoints (older versions) → Leak of project metadata, user emails, or even analysis tokens.
Path traversal (CVE‑2021‑44216) → Arbitrary file read via crafted API request.
Weak SSL ciphers → Man‑in‑the‑middle attacks on analysis traffic.

Mitigations applied in this guide:

Changed default credentials immediately (Section 3).
Nginx restricts `/api` to internal IPs.
Certbot ensures modern TLS 1.2/1.3 only (check with sslscan yourdomain.com).
Regular updates: `sudo apt update && sudo apt upgrade` and monitor SonarQube release notes.

Testing your own instance for misconfigurations:

Use `nmap` with SSL scripts:

nmap --script ssl-enum-ciphers -p 443 yourdomain.com
nmap --script http-default-accounts -p 443 yourdomain.com

Monitoring and Logging for SonarQube: Fail2ban, Auditd, and Alerts

Even a secured platform needs active monitoring. Set up the following to detect brute‑force attempts or anomalous API usage.

Step‑by‑step guide:

Fail2ban for Nginx – Protect the login endpoint:

sudo apt install fail2ban
sudo tee /etc/fail2ban/jail.local > /dev/null <<EOF
[nginx-sonar-login]
enabled = true
port = http,https
filter = nginx-sonar-login
logpath = /var/log/nginx/access.log
maxretry = 5
bantime = 3600
EOF
sudo systemctl restart fail2ban

2. Auditd to track sonar.properties access:

sudo auditctl -w /opt/sonarqube/conf/sonar.properties -p wa -k sonar_config
sudo ausearch -k sonar_config  review changes

Send SonarQube logs to central SIEM (e.g., AWS CloudWatch):

sudo apt install amazon-cloudwatch-agent
Configure agent to monitor /opt/sonarqube/logs/sonar.log and /var/log/nginx/access.log

Set up alerts – Use AWS SNS or similar to notify on:

– New user creation (parse `/opt/sonarqube/logs/access.log` for POST /api/users/create).
– Quality Gate failures in production branch.

What Undercode Say

Key Takeaway 1: SonarQube is not “install and forget” – it requires system‑level tuning (vm.max_map_count), user isolation, and HTTPS to be production‑ready.
Key Takeaway 2: API token management and IP whitelisting are as critical as the code analysis itself; a leaked token with admin scope compromises every scanned repository.
Key Takeaway 3: Integrating Quality Gates into CI/CD shifts security left, but only if the gate is enforced (fail the pipeline) and exceptions are audited.

Analysis: The LinkedIn project by Adil DALAOUI provides a solid foundation, but many engineers skip the hardening steps (firewall, dedicated user, API restrictions). Attackers actively scan for SonarQube instances with default credentials or exposed ports. By adding cloud IAM roles, fail2ban, and audit logging, this article turns a basic tutorial into a defensible DevSecOps control. Remember: SonarQube reveals security flaws in your code – make sure its own configuration doesn’t become a flaw itself.

Prediction

In the next 18 months, AI‑augmented static analysis (e.g., SonarQube’s AI CodeFix) will automatically generate patches for detected vulnerabilities, turning SonarQube from a reporter into a remediator. However, this will increase the platform’s attack surface – malicious actors could poison AI models via crafted code commits, leading to backdoored “fixes”. Consequently, we will see mandatory code signing for analysis plugins and runtime AI output verification. Organisations that adopt hardened SonarQube deployments today, with strict API access and pipeline integration, will be best positioned to safely leverage AI‑driven code repair without introducing supply‑chain risks.

▶️ Related Video (74% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Adil Dalaoui – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post

Introduction:

Learning Objectives:

You Should Know

Step‑by‑step guide:

Step‑by‑step guide:

Step‑by‑step guide:

Example token usage in pipeline:

Step‑by‑step guide:

Step‑by‑step guide (GitHub Actions example):

Mitigations applied in this guide:

Testing your own instance for misconfigurations:

Use `nmap` with SSL scripts:

Step‑by‑step guide:

2. Auditd to track sonar.properties access:

What Undercode Say

Prediction

▶️ Related Video (74% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

📢 Follow UndercodeTesting & Stay Tuned:

Share this:

Related Posts: