SonarQubeSécuritéDevSecOpsCI/CD

Détecter les vulnérabilités dans votre code avec SonarQube

26 mai 2026 · Sphinx-Digital

L’approche classique de la sécurité — un audit en fin de projet — est incompatible avec des cycles de livraison courts. SonarQube fait partie des outils qui permettent de décaler la détection des vulnérabilités vers la gauche : au moment de l’écriture du code, pas après le déploiement.

SonarQube comme outil SAST

SonarQube est un outil SAST (Static Application Security Testing). Il analyse le code source sans l’exécuter et détecte des patterns de vulnérabilités connus : injections, mauvaise gestion des secrets, mauvaise configuration des composants cryptographiques…

Ce n’est pas un outil de pentest. Il ne remplace pas un audit de sécurité, mais il élimine les vulnérabilités les plus communes avant qu’elles atteignent la production.

Les vulnérabilités qu’il détecte réellement

Injections SQL — le classique des classiques :

# ❌ SonarQube détecte ce pattern
def get_user(user_id):
    query = "SELECT * FROM users WHERE id = " + user_id
    cursor.execute(query)

# ✅ Corrigé
def get_user(user_id):
    cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

Secrets dans le code — mots de passe, API keys, tokens :

# ❌ Détecté comme "Hard-coded credentials"
AWS_SECRET_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# ✅ Depuis les variables d'environnement
AWS_SECRET_KEY = os.environ.get("AWS_SECRET_KEY")

Mauvaise gestion de la cryptographie :

// ❌ Algorithme obsolète
MessageDigest md = MessageDigest.getInstance("MD5");

// ✅ Algorithme moderne
MessageDigest md = MessageDigest.getInstance("SHA-256");

OWASP Top 10 et mapping SonarQube

SonarQube mappe ses règles sur le référentiel OWASP Top 10 et CWE. Dans l’interface, vous pouvez filtrer les issues par catégorie OWASP pour prioriser vos corrections selon les risques les plus répandus.

OWASPDescriptionExemple SonarQube
A01 — Contrôle d’accèsAccès non autoriséPath traversal, IDOR
A02 — CryptographieAlgorithmes faiblesMD5, DES, RC4
A03 — InjectionSQL, LDAP, OSSQL injection patterns
A06 — ComposantsDépendances vulnérables(via SCA, pas SAST)

Security Hotspots : la revue humaine

Les Hotspots ne sont pas des bugs avérés — ce sont des portions de code qui méritent une attention humaine. Exemple : l’utilisation d’expressions régulières pour valider des données sensibles n’est pas toujours une vulnérabilité, mais mérite une vérification.

Le workflow Sonar prévu : un développeur marque le hotspot comme Acknowledged (j’ai vérifié, c’est intentionnel) ou Fixed (corrigé). Cette validation manuelle fait partie de la revue de code.

Intégrer dans une culture DevSecOps

SonarQube est plus efficace quand il est positionné comme un outil d’apprentissage plutôt que comme un outil de contrôle. Les explications des règles (disponibles en cliquant sur chaque issue) expliquent pourquoi le code est problématique et comment le corriger.

# Dans votre pipeline, rendre la Quality Gate bloquante
sonar-scanner -Dsonar.qualitygate.wait=true
# Exit code 1 si la gate échoue → le pipeline s'arrête

Combinez SonarQube avec un outil SCA (Software Composition Analysis) comme Dependency-Check ou Trivy pour couvrir aussi les dépendances vulnérables — un vecteur d’attaque que SonarQube seul ne couvre pas.

Notre formation SonarQube inclut un atelier pratique sur l’analyse et la correction de vrais patterns de vulnérabilités.