SonarQube is the most widely used static analysis platform for Python in enterprise environments, and for good reason. Its Python analyzer ships with 500+ rules covering bugs, security vulnerabilities, and code smells - all tracked over time with a persistent dashboard, quality gates that can block broken code from merging, and deep integration with every major CI/CD platform.

Setting up SonarQube for a Python project takes about 20 minutes the first time. After that, every commit and pull request gets automatic analysis, coverage tracking, and security scanning without any developer action. This guide covers the complete setup from scanner configuration to quality profiles, pytest-cov integration, Django and Flask specific patterns, and GitHub Actions CI integration.

If you are evaluating whether SonarQube is the right tool for your Python team, see our full SonarQube alternatives comparison and the best code review tools for Python roundup.

How SonarQube analyzes Python code

SonarQube's Python analyzer works differently from local linters like Ruff or Pylint. Rather than running a quick pass over individual files, SonarQube builds a semantic model of your entire codebase - tracking data flow across functions, detecting duplicated code blocks across files, and calculating complexity metrics at the module and project level.

This cross-file analysis is what enables SonarQube to catch things local linters miss. A hardcoded credential in one file that gets passed to a database connection in another file, a None value that originates in one function and causes a dereference three call layers deep, duplicated logic copied between modules - these are the categories of issues that only become visible when the analyzer understands the entire codebase rather than individual files in isolation.

The tradeoff is that SonarQube requires a running server and a scanner client. It is not a drop-in replacement for a pre-commit hook. It works best when integrated into your CI/CD pipeline, where it runs on every push and maintains a persistent database of historical results.

For teams that want a more lightweight managed alternative, DeepSource provides Python analysis as a fully managed SaaS without any infrastructure to maintain. We cover the comparison in detail in our DeepSource Python guide.

Setting up SonarQube for a Python project

Before running analysis, you need three things: a SonarQube server (self-hosted or SonarQube Cloud), sonar-scanner installed on your machine or CI runner, and a sonar-project.properties configuration file in your repository root.

If you do not have a SonarQube server yet, the fastest way to get one running is Docker. See our SonarQube Docker guide for a complete setup with PostgreSQL and persistent volumes.

The sonar-project.properties file

The sonar-project.properties file tells the scanner where your code lives, which Python version you are targeting, and where to find coverage reports. Here is a minimal configuration for a Python project:

sonar.projectKey=my-python-app
sonar.projectName=My Python App
sonar.projectVersion=1.0

# Source and test directories
sonar.sources=src
sonar.tests=tests

# Python version
sonar.python.version=3

# Coverage report (generated by pytest-cov)
sonar.python.coverage.reportPaths=coverage.xml

# Exclusions
sonar.exclusions=**/migrations/**,**/__pycache__/**,**/*.pyc
sonar.test.inclusions=tests/**/*.py

The sonar.sources and sonar.tests properties are the most important settings to get right. SonarQube applies different rule sets to source code and test code - production-appropriate rules for source files and test-specific analysis for test files. Misconfiguring these paths means your test files get analyzed as production code, which triggers rules that do not apply (like missing docstring warnings on test functions).

Installing sonar-scanner

The scanner is a standalone CLI tool that reads your project configuration and sends analysis data to the SonarQube server. Install it with a package manager or download the binary directly:

# macOS with Homebrew
brew install sonar-scanner

# Linux - download and extract
wget https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-6.x.x-linux.zip
unzip sonar-scanner-cli-6.x.x-linux.zip
export PATH="$PATH:$(pwd)/sonar-scanner-6.x.x-linux/bin"

# Or use the official Docker image (no installation required)
docker run --rm \
  -e SONAR_HOST_URL=http://your-sonarqube:9000 \
  -e SONAR_TOKEN=your-token \
  -v $(pwd):/usr/src \
  sonarsource/sonar-scanner-cli

Running the analysis

With the configuration file in place and the scanner installed, run the analysis from your project root:

sonar-scanner \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=your-project-token

The scanner sends your source files to the SonarQube server, which performs the analysis and stores results in its database. Analysis of a medium-sized Python project (10,000-50,000 lines) typically completes in 3-8 minutes. Results appear in the SonarQube dashboard immediately after the scanner finishes.

For production use, store the token in an environment variable or CI secret rather than passing it on the command line:

export SONAR_TOKEN=your-project-token
sonar-scanner -Dsonar.host.url=http://your-sonarqube:9000

Python quality profiles

Quality profiles are collections of rules that SonarQube applies during analysis. Every project uses one quality profile per language, and SonarQube ships with a built-in profile called "Sonar way" that enables the most important subset of Python rules with sensible defaults.

The Sonar way Python profile

The Sonar way profile for Python enables roughly 200 of the 500+ available rules, filtered to those with the best signal-to-noise ratio. These include all critical bug and vulnerability rules, the most impactful code smell rules, and a set of security hotspot rules that require human review.

For most Python teams, Sonar way is a good starting point. It catches real issues without generating the volume of warnings that would cause developers to start ignoring the dashboard.

Creating a custom quality profile

When the default profile is too strict or too lenient for your team, create a custom profile. In the SonarQube dashboard, navigate to Quality Profiles, find the Python section, and click Create.

You can extend Sonar way (inheriting all its rules and adding or removing specific ones) or start from scratch. Key customizations for Python teams include:

Increasing cognitive complexity thresholds - The default limit of 15 per function is strict for Python code that uses decorators, context managers, and generator expressions heavily. Raising it to 20 or 25 reduces noise without missing genuinely complex functions.

Adjusting line length rules - Sonar way uses 120 characters as the maximum line length. If your team uses Black with 88-character lines or a different formatter setting, update the rule parameter to match.

Disabling duplication rules for test files - Test code often has intentional repetition (each test should be self-contained). If your test files are excluded from sonar.exclusions but still trigger duplication warnings, disable duplication detection rules in your custom profile or scope them to source files only.

Enabling security-focused rules - Some high-noise security rules are disabled in Sonar way but valuable for web applications. Rules covering SSRF, XML injection, and insecure cookie handling can be enabled selectively.

After creating your custom profile, assign it to your project under Project Settings > Quality Profiles. The assignment is project-specific - other projects on the same SonarQube instance continue using their own profiles.

Python rule categories

SonarQube organizes Python rules into four categories. Understanding what each category covers helps you prioritize fixes and configure quality gates effectively.

Bug rules

Bug rules detect code that is likely to produce incorrect results or raise unexpected exceptions at runtime. For Python, these are among the most valuable rules because the language's dynamic nature means many bugs only surface at runtime under specific conditions.

# SonarQube: Bug - Assertion on a non-boolean expression
# The assertion always passes because a non-empty string is truthy
def test_user_creation():
    user = create_user("test@example.com")
    assert user.email  # Should be: assert user.email == "test@example.com"

# SonarQube: Bug - Result of 'isinstance' may be incorrect
# Using a non-class argument to isinstance
def process(data):
    if isinstance(data, "str"):  # Should be: isinstance(data, str)
        return data.upper()

# SonarQube: Bug - Using == to compare with None
# Should use 'is None' for identity comparison
def get_user(user_id):
    user = db.query(user_id)
    if user == None:  # Should be: if user is None:
        raise ValueError("User not found")
    return user

# SonarQube: Bug - Modifying a collection while iterating
def remove_expired(sessions):
    for session_id in sessions:
        if sessions[session_id].is_expired():
            del sessions[session_id]  # RuntimeError at runtime

The bug rules also cover resource management issues - file handles opened without context managers, database connections not closed in finally blocks, and generator expressions consumed multiple times after being exhausted.

Vulnerability rules

Vulnerability rules identify code patterns that create security weaknesses attackable by external users. SonarQube's Python vulnerability rules map to CWE identifiers and OWASP categories, making them directly usable for compliance reporting.


from cryptography.hazmat.primitives.ciphers import Cipher, algorithms

# SonarQube: Vulnerability - OS command injection (CWE-78)
def convert_file(filename):
    subprocess.run(f"convert {filename} output.png", shell=True)
    # Fix: use list form without shell=True
    # subprocess.run(["convert", filename, "output.png"])

# SonarQube: Vulnerability - Use of MD5 for security-sensitive data (CWE-327)
def hash_password(password: str) -> str:
    return hashlib.md5(password.encode()).hexdigest()
    # Fix: use bcrypt, argon2, or at minimum pbkdf2_hmac

# SonarQube: Vulnerability - Deserialization of untrusted data (CWE-502)
def load_session(session_bytes: bytes):
    return pickle.loads(session_bytes)  # Never unpickle untrusted data

# SonarQube: Vulnerability - Use of weak encryption (DES)
def encrypt_data(key, data):
    cipher = Cipher(algorithms.TripleDES(key), mode=None)
    # Fix: use AES-256 or ChaCha20

SQL injection rules cover both raw SQL string formatting and ORM methods that accept raw SQL:

from django.db import connection

# SonarQube: Vulnerability - SQL injection (CWE-89)
def get_user_by_email(email: str):
    with connection.cursor() as cursor:
        # String formatting in SQL - flagged as vulnerability
        cursor.execute(f"SELECT * FROM auth_user WHERE email = '{email}'")
        return cursor.fetchone()

# Fix: parameterized queries
def get_user_by_email_safe(email: str):
    with connection.cursor() as cursor:
        cursor.execute("SELECT * FROM auth_user WHERE email = %s", [email])
        return cursor.fetchone()

Security hotspot rules

Security hotspots are code patterns that require human review to determine if a vulnerability exists. Unlike vulnerability rules (which flag definite security issues), hotspots flag patterns that are sometimes fine and sometimes dangerous depending on context.


# SonarQube: Security Hotspot - Pseudo-random number generation
# random.random() is not cryptographically secure
# Review: is this used for security-sensitive purposes?
token = random.randint(100000, 999999)

# SonarQube: Security Hotspot - Sensitive data exposure via logging
# Review: does the log message contain passwords, tokens, or PII?
logging.info(f"User {user.email} authenticated with token {user.session_token}")

# SonarQube: Security Hotspot - HTTP request without certificate verification

response = requests.get(url, verify=False)  # SSL verification disabled

Hotspots appear in a separate section of the SonarQube dashboard from vulnerabilities. They are marked as "to review" rather than given a severity score, because the severity depends on the specific usage context. Your team reviews each hotspot and marks it as either "Safe" (intentional, acceptable) or "Vulnerable" (needs fixing).

Code smell rules

Code smell rules cover maintainability issues - complexity, duplication, naming, and structural problems that make code harder to understand and modify. For Python, the most impactful code smell rules are:

Cognitive complexity - SonarQube calculates a cognitive complexity score for each function based on nesting depth, number of control flow branches, and use of logical operators. Functions with scores above the threshold (default: 15) are flagged. This metric is more practical than cyclomatic complexity because it reflects how hard the function is to understand rather than just how many paths it has.

# SonarQube: Code Smell - Cognitive Complexity too high (score: 22, threshold: 15)
def process_order(order, user, inventory, payment_method):
    if order.is_valid():
        if user.has_permission("checkout"):
            for item in order.items:
                if item.id in inventory:
                    if inventory[item.id] >= item.quantity:
                        if payment_method.can_charge(order.total):
                            inventory[item.id] -= item.quantity
                            payment_method.charge(order.total)
                            return "success"
                        else:
                            return "payment_failed"
                    else:
                        return "insufficient_stock"
                else:
                    return "item_not_found"
        else:
            return "unauthorized"
    else:
        return "invalid_order"

Code duplication - SonarQube tracks duplicated code blocks across your entire codebase, not just within individual files. It identifies token sequences longer than a configurable threshold that appear in multiple locations. This catches copy-paste programming patterns that create maintenance problems when the duplicated logic needs to change.

Function and class length - Functions longer than 100 lines and classes with more than 30 methods are flagged as maintenance risks.

Naming conventions - Variables, functions, and classes that do not follow Python naming conventions (snake_case for variables and functions, PascalCase for classes) are flagged.

Coverage with pytest-cov

SonarQube displays test coverage metrics when you provide a coverage report in Cobertura XML format. pytest-cov generates this format directly.

Generating coverage for SonarQube

Install pytest-cov if you have not already:

pip install pytest-cov

Run pytest with the XML coverage report:

pytest \
  --cov=src \
  --cov-report=xml:coverage.xml \
  --cov-report=term-missing \
  tests/

The --cov=src argument tells coverage.py which directory to measure. The --cov-report=xml:coverage.xml argument generates the Cobertura XML file that SonarQube reads. The --cov-report=term-missing argument additionally prints a summary in the terminal so developers can see coverage feedback without opening the dashboard.

Point SonarQube to the report in your sonar-project.properties:

sonar.python.coverage.reportPaths=coverage.xml

If your tests and source code are in different locations or you have multiple coverage reports from parallel test runs, you can provide multiple paths:

sonar.python.coverage.reportPaths=coverage-unit.xml,coverage-integration.xml

SonarQube merges the reports and deduplicates coverage data, so running separate unit and integration test suites and combining their reports gives you accurate overall coverage numbers.

Setting coverage quality gates

Once coverage data flows into SonarQube, you can enforce minimum thresholds through quality gates. The built-in Sonar way quality gate requires:

Coverage on new code above 80%
Duplication on new code below 3%
No new blocker or critical issues

"New code" means code changed since a baseline date or version, which you configure in SonarQube settings. This approach is practical for legacy projects - rather than requiring the entire codebase to have 80% coverage immediately, you enforce coverage on every new change. Over time, coverage improves as new code accumulates without requiring a big-bang effort to retrofit tests on existing code.

Pylint vs. SonarQube rules for Python

A common question when adopting SonarQube is how its Python rules relate to Pylint, which many Python developers already use.

Pylint runs locally in seconds, has 400+ rules, and performs deep type inference that catches issues like incorrect method signatures and type mismatches in annotated code. It is excellent for pre-commit hooks and IDE integration where fast feedback matters.

SonarQube runs on a server, has 500+ Python rules, and adds capabilities that Pylint does not have: cross-file data flow analysis, codebase-wide duplication detection, security hotspot tracking, quality gates, and historical trend analysis. SonarQube is better suited for CI/CD integration where richer reporting and enforcement matter more than speed.

The practical difference in rule coverage centers on a few areas:

# Pylint catches this (type inference): incorrect argument type
def multiply(a: int, b: int) -> int:
    return a * b

result = multiply("3", 4)  # Pylint E1120: No value for argument

# SonarQube catches this (cross-file duplication):
# Identical 15-line block appears in api/views.py and admin/views.py
# Pylint does not analyze duplication across files

# Both catch this (bare except):
try:
    process()
except:  # Too broad - catches SystemExit, KeyboardInterrupt
    pass

The recommended approach for Python teams is to use both. Run Ruff or Pylint in pre-commit hooks for fast, local feedback. Run SonarQube in CI for security analysis, duplication detection, trend tracking, and quality gate enforcement. The tools complement each other rather than overlap.

For teams exploring alternatives to this combination, Sourcery offers an interesting middle ground - it runs as an IDE plugin and CI integration, providing AI-powered refactoring suggestions and complexity analysis without requiring a separate server. We cover Sourcery's Python capabilities in detail on its tool page.

Django and Flask patterns

SonarQube's Python rules are not framework-specific, but they cover the security and code quality patterns that matter most in Django and Flask applications.

Django-specific analysis

ORM bypass detection - SonarQube flags every instance of string formatting in SQL queries, including Django's raw(), extra(), and connection.cursor() methods:

from django.db import models, connection
from django.contrib.auth.models import User

# SonarQube: SQL injection - string formatting in raw query
class UserManager(models.Manager):
    def search(self, term):
        return self.raw(
            f"SELECT * FROM auth_user WHERE username LIKE '%{term}%'"
        )

# Fix: parameterized raw query
class UserManager(models.Manager):
    def search(self, term):
        return self.raw(
            "SELECT * FROM auth_user WHERE username LIKE %s",
            [f"%{term}%"]
        )

Settings security - SonarQube detects insecure patterns in Django settings files:

# sonar-project.properties - configure settings file path:
# sonar.sources=myproject,myapp

# settings.py patterns SonarQube flags:

# Vulnerability: hardcoded secret key
SECRET_KEY = "django-insecure-abc123xyz"

# Code smell: debug mode (may be intentional in dev, but flagged for review)
DEBUG = True

# Vulnerability: overly permissive ALLOWED_HOSTS
ALLOWED_HOSTS = ["*"]

# Security hotspot: missing security middleware
MIDDLEWARE = [
    "django.middleware.common.CommonMiddleware",
    # Missing: django.middleware.security.SecurityMiddleware
    # Missing: django.middleware.clickjacking.XFrameOptionsMiddleware
]

XSS via mark_safe - When mark_safe() is called with user-controlled input, SonarQube flags it as a vulnerability:

from django.utils.safestring import mark_safe
from django.http import HttpRequest

# SonarQube: Vulnerability - Cross-site scripting (XSS)
def render_user_comment(request: HttpRequest):
    comment = request.POST.get("comment", "")
    # mark_safe on user input bypasses Django's auto-escaping
    return mark_safe(f"<div class='comment'>{comment}</div>")

Flask-specific analysis

Flask's minimal philosophy means security features that Django includes by default must be added explicitly. SonarQube catches the gaps:

from flask import Flask, request

app = Flask(__name__)

# SonarQube: Vulnerability - Hardcoded secret key
app.secret_key = "development-key-12345"

# SonarQube: Security hotspot - Debug mode
app.run(debug=True)

# SonarQube: Vulnerability - Path traversal
@app.route("/files/<filename>")
def serve_file(filename):
    # User-controlled filename without sanitization
    filepath = os.path.join("/uploads", filename)
    return open(filepath).read()  # Path traversal: ../../etc/passwd

# Fix: use werkzeug's safe_join
from werkzeug.utils import safe_join

@app.route("/files/<filename>")
def serve_file_safe(filename):
    filepath = safe_join("/uploads", filename)
    if filepath is None:
        return "Invalid path", 400
    return open(filepath).read()

CORS misconfiguration - SonarQube flags wildcard CORS origins in Flask-CORS configurations:

from flask_cors import CORS

app = Flask(__name__)

# SonarQube: Security hotspot - Permissive CORS policy
CORS(app, origins="*")  # Allows any origin to make cross-origin requests

# More restrictive configuration
CORS(app, origins=["https://yourdomain.com", "https://api.yourdomain.com"])

CI integration for Python projects

The practical value of SonarQube comes from running it automatically on every pull request. Here is how to set up CI integration for the most common Python CI environments.

GitHub Actions

# .github/workflows/sonarqube.yml
name: SonarQube Analysis

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  sonarqube:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Full history required for new code detection

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest pytest-cov

      - name: Run tests with coverage
        run: |
          pytest \
            --cov=src \
            --cov-report=xml:coverage.xml \
            tests/

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

The fetch-depth: 0 setting is important. SonarQube uses git history to determine which code is "new" for quality gate calculations. Without full history, it cannot accurately identify new code and may apply the wrong thresholds.

GitLab CI

# .gitlab-ci.yml
sonarqube-check:
  image: python:3.12-slim
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
    GIT_DEPTH: "0"
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    - pip install -r requirements.txt pytest pytest-cov
    - pytest --cov=src --cov-report=xml:coverage.xml tests/
    - apt-get update && apt-get install -y wget unzip default-jdk
    - wget -q https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-6.0.0-linux.zip
    - unzip -q sonar-scanner-cli-6.0.0-linux.zip
    - ./sonar-scanner-6.0.0-linux/bin/sonar-scanner
      -Dsonar.host.url=$SONAR_HOST_URL
      -Dsonar.token=$SONAR_TOKEN
  only:
    - merge_requests
    - main

Configuring PR decoration

PR decoration shows SonarQube analysis results directly in GitHub pull request comments, eliminating the need to open the SonarQube dashboard for routine checks. Enable it in SonarQube under Administration > DevOps Platform Integrations, configure your GitHub connection with a personal access token, and set sonar.pullrequest.github.repository in your project settings.

Once configured, every pull request receives a status check from SonarQube showing whether the quality gate passed or failed, plus inline comments on specific lines of code that introduce new issues.

Modern alternatives worth evaluating

SonarQube is the established choice for Python static analysis at enterprise scale, but it comes with operational overhead - a server to maintain, a database to manage, and updates to apply. Several modern alternatives eliminate that overhead.

CodeAnt AI ($24-40/user/month) provides AI-powered code quality analysis for Python with no infrastructure to manage. It integrates with GitHub, GitLab, and Bitbucket and provides automated issue detection and remediation suggestions. For teams that want depth without the operational burden of self-hosting SonarQube, CodeAnt AI is worth a close look.

DeepSource ($24/user/month) offers 150+ Python rules with Autofix - something SonarQube does not have. Its fully managed model means zero infrastructure overhead, and it includes mypy and pytype integration for type checking. See our DeepSource Python guide for a complete setup walkthrough.

Sourcery takes a different approach focused on AI-driven refactoring suggestions. It works as an IDE plugin, GitHub bot, and CLI tool, and it is particularly good at identifying overly complex functions and suggesting simpler alternatives. It is not a security scanner, but for code quality and maintainability it is one of the best tools available for Python.

For a complete comparison of all these tools and more, see our SonarQube alternatives guide.

Best practices for Python teams

After setting up SonarQube for Python, a few practices make the analysis more actionable and less noisy:

Fix quality gate failures before merging - The quality gate exists to prevent issues from accumulating in your codebase. Treating gate failures as merge blockers - the same way you treat failing tests - establishes a culture where code quality is a first-class concern rather than a background metric.

Start with new code thresholds - For existing codebases with accumulated technical debt, enforce quality standards on new code first. This prevents debt from growing while you gradually address existing issues, rather than requiring a massive cleanup effort before SonarQube provides value.

Suppress intentional false positives - SonarQube provides # noqa-style suppression comments (# NOSONAR) for cases where a flagged pattern is intentional. Use these sparingly and always include a comment explaining why the suppression is appropriate. Reviewing suppressions in code review prevents them from becoming a way to avoid addressing real issues.

Exclude generated code - Django migrations, Protocol Buffer generated files, and other auto-generated Python code should be excluded from analysis. These files contain patterns that trigger rules but are not developer-maintained, so findings in them are not actionable.

Review security hotspots on a schedule - Unlike vulnerabilities (which should be fixed immediately), hotspots require human review to determine if they represent real risks. Assign hotspot review as a recurring task during sprint planning so they do not accumulate indefinitely.

Align SonarQube rules with your formatter - If your team uses Black at 88 characters, update the line length rule parameter in your quality profile to 88. Mismatches between formatter settings and SonarQube rules create noise where correctly formatted code still triggers warnings.

SonarQube's Python analysis is a powerful tool for maintaining code quality at scale, but it works best when treated as part of a broader quality culture rather than an external enforcement mechanism. The goal is to make every Python developer on your team aware of security, maintainability, and correctness issues before those issues reach production - not to generate compliance reports.

Further Reading

Frequently Asked Questions

How do I set up SonarQube for a Python project?

Create a sonar-project.properties file in your project root with sonar.projectKey, sonar.sources, and sonar.python.version set. Install sonar-scanner on your machine or CI runner, then run sonar-scanner with your SonarQube server URL and authentication token. SonarQube will analyze all Python files under the configured sources directory and display results in the dashboard within a few minutes.

Does SonarQube support Python 3?

Yes. SonarQube's Python analyzer supports Python 3.x fully. Set sonar.python.version=3 in your sonar-project.properties file to enable Python 3 specific analysis. SonarQube understands Python 3 syntax including f-strings, walrus operators, type annotations, match statements, and other modern Python features. Python 2 analysis is still available but no longer actively developed.

How do I add pytest coverage to SonarQube?

Run pytest with coverage XML output using 'pytest --cov=src --cov-report=xml:coverage.xml', then set sonar.python.coverage.reportPaths=coverage.xml in your sonar-project.properties. SonarQube reads the Cobertura XML format produced by pytest-cov and displays per-file and overall coverage metrics in the dashboard. You can enforce minimum coverage thresholds through quality gates.

What Python rules does SonarQube include?

SonarQube's Python analyzer includes 500+ rules covering bugs, vulnerabilities, security hotspots, and code smells. Bug rules catch issues like None dereferences, incorrect assertions, and resource leaks. Vulnerability rules cover injection attacks, insecure cryptography, and hardcoded credentials. Code smell rules enforce complexity limits, duplication thresholds, naming conventions, and cognitive complexity scores. The Sonar way quality profile enables the most important subset of these rules by default.

How do I create a custom quality profile for Python in SonarQube?

Go to Quality Profiles in the SonarQube dashboard, find the Python section, and click Create. You can start from scratch or extend the built-in Sonar way profile. Add and remove individual rules, set severity levels, and configure rule parameters. Assign the custom profile to your project under Project Settings > Quality Profiles. Custom profiles are useful for enforcing team-specific standards or relaxing rules that produce too many false positives for your codebase.

Can SonarQube analyze Django and Flask applications?

Yes. SonarQube's Python rules apply to any Python code including Django and Flask applications. It detects SQL injection via ORM bypasses, hardcoded secret keys, debug mode misconfigurations, insecure cookie settings, and command injection patterns common in web applications. SonarQube does not have separate Django or Flask rule sets - its general Python security rules cover the patterns that matter most in web framework code.

How do I run SonarQube analysis in GitHub Actions for Python?

Add a workflow step that installs sonar-scanner and runs it with your SonarQube URL and token stored as GitHub Secrets. Before the scanner step, run pytest with coverage XML output and set sonar.python.coverage.reportPaths in your sonar-project.properties. Alternatively, use the SonarSource/sonarqube-scan-action GitHub Action, which handles scanner installation and execution automatically.

What is the difference between pylint and SonarQube rules for Python?

Pylint has 400+ rules focused on code correctness, style, and complexity with deep type inference. SonarQube's Python analyzer has 500+ rules that additionally cover security vulnerabilities, security hotspots, and duplication analysis across the entire codebase. SonarQube tracks metrics over time with trend analysis and enforces quality gates. Pylint runs locally in seconds; SonarQube runs on a server with a persistent database. Many teams use both - pylint in pre-commit hooks for fast feedback and SonarQube in CI for security scanning and trend tracking.

How do I exclude files from SonarQube Python analysis?

Set sonar.exclusions in your sonar-project.properties using glob patterns. Common exclusions for Python projects include /migrations/, /_generated.py, */tests/, /vendor/, and */.pb2.py. You can also configure test-specific paths with sonar.test.inclusions so SonarQube applies test-appropriate rules to your test files rather than production code rules.

What is a SonarQube quality gate for Python?

A quality gate is a set of conditions that a project must meet for a build to pass. For Python, typical quality gate conditions include coverage on new code above 80%, no new critical bugs, no new blocker vulnerabilities, and duplication on new code below 3%. If any condition fails, SonarQube marks the quality gate as failed and can block PR merges when integrated with GitHub or GitLab. The built-in Sonar way quality gate enforces these thresholds by default.

How does SonarQube Python analysis compare to DeepSource?

SonarQube has more Python rules (500+) compared to DeepSource (150+) and includes a more sophisticated quality gate system with trend analysis. DeepSource offers Autofix that generates ready-to-apply code changes, which SonarQube does not. SonarQube requires self-hosting or SonarQube Cloud with usage-based pricing, while DeepSource is a fully managed SaaS at $24/user/month. For teams that want depth and compliance reporting, SonarQube wins. For teams that want automated remediation with minimal infrastructure, DeepSource is the simpler choice.

Are there alternatives to SonarQube for Python code quality?

Key alternatives include DeepSource ($24/user/month) with Python Autofix, CodeAnt AI ($24-40/user/month) with AI-powered analysis, Sourcery for AI-driven refactoring suggestions, Codacy ($15/user/month) which aggregates multiple Python tools, and Semgrep with customizable security rules. Free open-source options include Ruff for fast linting, Bandit for security scanning, and mypy for type checking. For a full comparison, see our guide to SonarQube alternatives.

Originally published at aicodereview.cc

☁️ Cloud & DevOps

The Curator's Role: Managing a Codebase With an Agent

I Gave My Codebase an AI Intern. Here's What Actually Happened.

SonarQube for Python: Setup, Rules, and Best Practices

How to Connect Any AI Coding Assistant to Kafka, MQTT, and Live Data Streams

Project Glasswing: Securing critical software for the AI era

How to Prepare Your TLS Stack for Post-Quantum Cryptography Today

Stop Using Templates: I Built an AI CLI That Generates Projects From Instructions

How to install n8n self-hosted on AWS

Building the Agent Harness: Subdirectory CLAUDE.md Files

Hiring a Remote Technical Lead? The 5 Questions That Separate a Great Engagement from a Disaster

Release Guard Lite — 一个 10 秒搞定发版风险检查的 CLI 工具

How We Made Waiting Fun: Whimsical Loading States and Stepped Progress in Next.js

From ticket to PR with agents: how to use Claude to automate platform changes without breaking SLOs

I Read the Claude Code Docs. All of Them. Here's What I Built.

EmDash vs WordPress: Which CMS Delivers the Best Speed for African Websites?

Beyond Basic Caching: Introducing `layercache` – The Production-Ready Multi-Layer Caching Toolkit for Node.js

What Happens When AI Agents Hallucinate? The boring part is the checkpoint.

Programming as a tool: A mindset shift for software engineers

The Ultimate Guide to Securing Ansible Supply Chain

Early performance testing: benefits, best practices, and implementation strategies

Is a visual builder that exports clean code for BOTH full animated websites and single components a pipe dream? Validating my architecture project.

Launching S3 Files, making S3 buckets accessible as file systems

Give Your AI Agent iMessage in 5 Minutes — Claude Code, Codex, Cursor

Self-Improving Python Scripts with LLMs: My Journey