Qu’est-ce que SonarQube ?
Définition et rôle
SonarQube se présente comme une solution d’analyse statique du code source, axée sur la qualité du développement. Il est capable de détecter bugs, mauvaises pratiques, vulnérabilités ainsi que des problématiques de maintenabilité (“code smell”).
SonarQube regroupe les fonctionnalités dédiées à traquer les failles de sécurité dans le code source.
Classé parmi les outils SAST (Static Application Security Testing), il analyse le code source sans l’exécuter, identifiant des risques comme les injections SQL ou les attaques XSS (Cross-Site Scripting).
Ainsi, il accompagne les développeurs pour sécuriser leurs applications dès la phase de développement, en leur fournissant des rapports détaillés et des pistes pour résoudre les problèmes / failles identifiés.
SonarQube met à disposition une plateforme centralisée pour suivre à la fois qualité et sécurité.
Les anomalies détectées sont triées par niveau de sévérité, et son interface web permet de les attribuer aux développeurs, d’échanger des commentaires ou de signaler des faux positifs.
Cette gestion favorise la collaboration autour des problématiques de sécurité au sein des équipes, tout en offrant un suivi clair de la résolution des problèmes au fil du temps.
SonarQube permet de renforcer la prévention : En l’intégrant lors du développement, SonarQube aide à bâtir des applications plus sûres dès le départ, en résolvant les vulnérabilités au fil de leur apparition.
Comparaison entre différents types d’outils de sécurité applicative
Les outils de test de sécurité applicative se déclinent en plusieurs catégories, chacune adoptant une méthode distincte pour repérer les failles.
- SAST (Static Application Security Testing) : Ces solutions, dont fait partie SonarQube, inspectent le code sans l’exécuter.
Elles le comparent à des règles établies pour identifier des vulnérabilités connues. Par exemple, elles peuvent signaler un risque de dépassement de mémoire tampon (buffer overflow) ou la présence de secrets dans le code.
Leur grand avantage ? Elles s’intègrent dès les premières étapes du développement, permettant de corriger les problèmes au moment où le code prend forme.
Mais elles ont leurs limites : focalisées sur le code brut, elles passent à côté des problèmes liés à la configuration de l’environnement ou aux usages réels.
Autre bémol, elles pointent parfois des alertes inutiles – des faux positifs – qui n’impactent pas vraiment la sécurité.
SonarQube permet de repérer des risques dans le code, mais requiert un œil humain pour trier les alertes et ne détecte pas les failles liées à l’exécution ou aux configurations.
- DAST (Dynamic Application Security Testing) : À l’inverse du SAST, un DAST analyse une application en cours d’exécution, sans accès au code source.
Ici, l’outil joue un rôle similaire à celui d’un attaquant ou un hacker : il envoie à l’application des requêtes malveillantes pour déceler des failles.
Des scanners comme OWASP ZAP ou Burp Suite, par exemple, traquent injections SQL, XSS, erreurs de configuration ou faiblesses d’authentification.
Cette méthode permet de détecter des vulnérabilités qui ne se révèlent qu’en cours d’exécution.
En contrepartie, elle ne peut intervenir que plus tard dans le cycle de vie d’une application, une fois celle-ci en phase de test, et demande souvent plus de temps et d’expérience pour interpréter les résultats.
- IAST (Interactive Application Security Testing) : L’IAST est un mélange entre SAST et DAST.
Ces outils, souvent des agents logiciels, s’intègrent dans une partie de l’application pendant son exécution – typiquement en phase de test – et scrutent son comportement de l’intérieur tout en analysant le code ciblé.
Concrètement, un agent IAST suit une partie de l’application en temps réel (par exemple lors de tests automatisés) et peut permettre de relier un problème à son origine exacte dans le code analysé.
Résultat : une capacité à détecter aussi bien des erreurs de programmation que des soucis d’environnement ou de configuration, dans une partie ciblée de l’application.
C’est une approche qui est cependant moins répandue.
En résumé, là où SonarQube se concentre sur le code, un DAST analyse le comportement d’une application en fonctionnement, et un IAST s’immisce à l’intérieur d’une partie de l’application pendant son exécution.
Comment SonarQube analyse-t-il la sécurité du code ?
Principaux types de vulnérabilités détectées
SonarQube repère un grand nombre de vulnérabilités dans le code source en s’appuyant sur des règles de sécurité ciblant les failles les plus fréquentes.
SonarQube distingue deux catégories : les vulnérabilités, failles graves à corriger d’urgence et les Security Hotspots, zones sensibles à revoir manuellement.
Voici les principaux types de risques qu’il détecte :
- Injections (SQL, OS, LDAP, etc.) : Sonar peut détecter des entrées non-validées ou non-assainies dans l’application qui permettent à un attaquant d’exécuter des commandes arbitraires.
- Cross-Site Scripting (XSS) : Il signale les cas où une application web renvoie un contenu injecté non maîtrisé à l’utilisateur, ouvrant la porte à des XSS stockés ou réflectifs.
- Problèmes d’authentification/autorisation : L’outil repère les mots de passe codés en dur, les mécanismes d’authentification obsolètes ou les contrôles d’accès trop faibles – même si certains cas nécessitent une vérification à l’exécution.
- Exposition de données sensibles : Le stockage de mots de passe en clair ou l’utilisation d’un algorithme de chiffrement fragile (type MD5) est identifié.
- Désérialisation risquée : Il détecte les désérialisations d’objets provenant de sources douteuses, potentiellement exploitables pour exécuter du code malveillant.
- Composants vulnérables : bien que ce domaine (appelé Software Composition Analysis) ne soit pas nativement supporté, SonarQube peut, via plugins par exemple, signaler l’usage de bibliothèques ou framework à risque.
En somme, SonarQube permet la détection de la plupart des failles majeures, émettant des issues avec une description, une sévérité (Bloquant, Critique, etc.) et des conseils pratiques pour guider le développeur vers un correctif approprié.
Explication des règles de sécurité intégrées
Les règles de sécurité de SonarQube s’alignent sur les grands standards de la sécurité applicative, offrant ainsi un cadre pour évaluer et améliorer le code. Voici les principaux référentiels pris en compte :
- OWASP Top 10 : L’Open Web Application Security Project est une communauté open-source internationale dédiée à l’amélioration de la sécurité des applications web.
Elle propose un classement qui recense les dix risques majeurs en sécurité web, comme les injections ou les failles d’identification et d’authentification.
SonarQube y répond avec des règles adaptées à chaque catégorie.
Des rapports spécifiques OWASP Top 10 permettent de voir les failles par catégorie (A1, A2, etc.), avec une note (A, B, C…) reflétant le niveau de conformité.
Un moyen de s’assurer que le projet respecte ce standard.
- CWE Top 25 : Le Common Weakness Enumeration est un catalogue standardisé des faiblesses logicielles (bugs, erreurs de conception) qui peuvent mener à des vulnérabilités exploitables.
Il liste les faiblesses de sécurité courantes et son Top 25 annuel met en avant les plus critiques. SonarQube associe ses règles à ces CWE.
Un rapport dédié évalue la conformité à ce Top 25, facilitant les discussions techniques et la priorisation des corrections majeures.
SonarQube intègre également des recommandations du CERT Secure Coding et d’autres standards.
Chaque règle précise souvent son lien avec un référentiel, aidant ainsi les développeurs à saisir l’importance de la faille tout en les sensibilisant aux bonnes pratiques.
Analyse statique vs analyse dynamique
L’analyse statique (menée par SonarQube) et l’analyse dynamique (via des outils DAST ou IAST) forment deux piliers complémentaires de la sécurité applicative.
Comprendre leurs différences permet de tirer le meilleur de SonarQube tout en le replaçant dans une stratégie de sécurité globale.
- Analyse statique : Elle consiste à examiner le code source sans l’exécuter.
SonarQube procède de cette manière en parcourant le code fichier par fichier puis applique des règles pour repérer des failles présentent dans le code.
Par exemple, une entrée utilisateur injectée sans contrôle dans une requête SQL sera signalée comme risquée. L’avantage est de pouvoir agir tôt, dès la phase de développement, grâce à une intégration dans un IDE (via SonarLint) ou une pipeline CI pour vérifier chaque commit.
Cependant, l’analyse statique a ses limites. Elle ne voit pas les erreurs liées à une configuration serveur ou à des scénarios complexes qui n’émergent qu’à l’exécution.
Certaines vulnérabilités nécessitent un contexte d’exécution pour être identifiables.
- Analyse dynamique : Contrairement à l’analyse statique, l’analyse dynamique permet de tester l’application en cours d’exécution.
Un test dynamique consistera à effectuer une suite d’actions sur une application (remplir des formulaires, simuler des attaques, etc.) et à vérifier si l’application réagit d’une manière qui révèle une faille de sécurité ou vulnérabilité (fuite d’information, comportement anormal, etc.).
Cette approche permet de détecter des vulnérabilités invisibles dans le code brut et qui ne sont visibles qu’à l’exécution (failles d’authentification, de session, de configuration, etc.).
L’inconvénient, c’est que cela arrive plus tard dans le cycle de développement, souvent en phase d’intégration, complexifiant les corrections.
L’autre inconvénient est que c’est au développeur de diagnostiquer dans le code la source de la vulnérabilité.
SonarQube n’effectue que de l’analyse statique. Pour une sécurité complète, il faut compléter son analyse par des tests dynamiques (DAST automatisés, pentests manuels).
La philosophie DevSecOps encorage l’adoption de l’approche “Shift Left”, en anticipant les contrôles tout en gardant des vérifications en fin de cycle (monitoring, tests en production).
En clair, SonarQube et les analyses dynamiques se complètent : l’un sécurise le code, l’autre traque les failles à l’exécution, couvrant ainsi tout le cycle de vie d’une application.
Configurer SonarQube
Installation et configuration
Installer SonarQube implique de déployer un serveur (ou utiliser SonarCloud), de créer un projet, de générer un token et d’utiliser SonarScanner pour analyser le code.
Il peut également s’intégrer à des bases de données externes et être personnalisé selon les besoins.
Les étapes à prendre en compte sont :
- L’installation du serveur SonarQube : On commence par récupérer la version qui convient aux besoins. SonarQube s’installe via un zip (Windows/Linux) ou une image Docker.
Par défaut, SonarQube inclut une base de données utilisable pour des tests. Pour la production, il est recommandé de le connecter à une base de données (PostgreSQL, Oracle, SQL Server).
Une fois lancé, on accède à une interface web avec des tableaux de bord sur la qualité et la sécurité des projets.
- La création d’un projet et la génération d’un token : Sur l’interface SonarQube, on crée un projet correspondant au code à analyser.
Le token sera utilisé par exemple pour lancer des scans depuis une pipeline CI ou un poste local.
- L’analyse du code avec SonarScanner : SonarScanner, analyse le code et transmet les résultats au serveur.
Il existe plusieurs types de scanners par exemple Maven/Gradle pour Java, ou pour .NET.
Il faut lui indiquer l’URL du serveur, le token, la clé du projet. D’autres options sont disponibles pour des besoins plus spécifiques (ex. exclusions de fichier ou dossiers).
Une fois le scan terminé, le rapport apparaît dans l’interface SonarQube.
En clair, l’installation de SonarQube est simple et bien documentée. On peut l’héberger en interne ou opter pour SonarCloud, la version SaaS qui simplifie la maintenance de l’outil.
Personnalisation des règles de sécurité et des Quality Gates
Une fois SonarQube installé et mis en place, l’adapter à ses besoins est essentiel pour en faire un vrai atout sécurité. Les deux leviers principaux sont : personnaliser les profiles (Quality Profiles) et configurer des Quality Gates.
- Personnaliser les règles de sécurité (Quality Profile) : SonarQube s’appuie sur des profils de qualité (Quality Profiles) pour définir quelles règles sont appliquées lors de l’analyse.
Par défaut, chaque langage a un profil standard (“Sonar way”), avec un sous-ensemble de règles génériques.
Cependant, en matière de sécurité, on souhaite sélectionner les règles pertinentes selon le contexte et le niveau de risque.
On peut donc spécifier des profils en y ajoutant des règles spécifiques ou en désactivant certaines par exemple si elles génèrent des faux positifs.
L’interface permet de trier les règles par thème ou tag et de cocher celles à activer. Si besoin, on peut même créer ses propres règles, via des plugins ou des outils tiers comme “Find Security Bugs” pour Java.
- Configurer des Quality Gates orientées sécurité : Les Quality Gates fixent des seuils de qualité pour valider ou rejeter un projet.
La Quality Gate par défaut exige, entre autres, aucune nouvelle issue et de respecter certains seuils de duplication de code et de couverture des tests.
Pour mettre l’accent sur la sécurité, on peut personnaliser une Quality Gate afin d’exiger zéro vulnérabilité bloquante ou critique sur le nouveau code, et tous les Hotspots examinés.
L’objectif ? Faire de la sécurité un critère bloquant : une faille critique fait échouer la validation de la Quality Gate, empêchant une mise en production dans cet état.
Une bonne pratique est la mise en place progressive. Par exemple en contrôlant et limitant d’abord les nouvelles failles de sécurité puis en élargissant le périmètre au reste de l’application. Cela permet pour les équipes d’effectuer les changements de manière progressive et de remédier petit à petit aux vulnérabilités historiques.
- Gérer les faux positifs et les exceptions : Certaines alertes peuvent être marquées en tant que “False Positive” ou “Won’t Fix” si, après vérification, elles ne posent pas de vrai risque ou que les risques sont acceptés.
À utiliser avec modération, mais cela fluidifie le process d’intégration dans son ensemble.
On peut aussi utiliser des tags et des assignations de responsables pour un suivi clair et structuré.
En personnalisant les règles et les Gates, SonarQube s’adapte au mieux au contexte des projets.
Automatiser l’analyse dans une pipeline CI/CD
Pour une meilleure intégration dans les processus, SonarQube peut être intégré dans les pipelines CI/CD.
L’objectif est que l’analyse du code soit automatisée dans les pipelines. Voici quelques exemples d’intégration :
- Intégration avec GitLab CI : GitLab CI permet d’orchestrer des jobs d’analyse.
Il suffit d’ajouter un job dans le fichier “.gitlab-ci.yml” pour lancer l’analyse avec le SonarScanner.
Ce job utilisera les variables du projet GitLab pour accéder au serveur Sonar (URL, token).
Un exemple de configuration :
"sonar_scan:
stage: analysis
image: sonarsource/sonar-scanner-cli:latest
script:
- sonar-scanner -Dsonar.projectKey=myproj -Dsonar.host.url=https://sonar.exemple.com -Dsonar.login=$SONAR_TOKEN
only:
- merge_requests
- main
"Résultat : chaque merge request ou commit sur la branche principale déclenche un scan.
GitLab peut également stopper la pipeline si la Quality Gate n’est pas validée.
- Intégration avec Jenkins : Jenkins possède un plugin SonarQube qui facilite l’exécution du scanner.
On configure dans Jenkins, les informations du serveur Sonar (dans la config globale) puis dans le pipeline (Pipeline Jenkinsfile ou job freestyle), on ajoute une étape Sonar.
Un exemple de script déclaratif :
"stage('SonarQube Analysis') {
steps {
withSonarQubeEnv('My Sonar') {
sh 'sonar-scanner -Dsonar.projectKey=myproj -Dsonar.sources=src/ -Dsonar.host.url=https://sonar.exemple.com -Dsonar.login=${SONAR_TOKEN}'
}
}
}"Le plugin Jenkins Sonar fournit également une étape pour attendre la comparaison à la Qualité Gate (waitForQualityGate) afin de stopper la pipeline si les critères ne sont pas respectés.
- Intégration avec GitHub Actions : Sur GitHub, on peut utiliser soit l’action officielle “SonarSource/sonarcloud-github-action” (pour SonarCloud surtout), soit directement appeler le scanner dans un job.
Un exemple de workflow :
"- name: SonarQube Scan
uses: sonarsource/sonarqube-scan-action@v1.2
with:
host_url: ${{ secrets.SONAR_HOST_URL }}
login: ${{ secrets.SONAR_TOKEN }}
projectBaseDir: "./"
" - Autres outils CI/CD : SonarQube s’adapte à d’autres systèmes comme Azure DevOps (avec extension), Bitbucket Pipelines, CircleCI, etc.
Dans une logique DevSecOps, le pipeline devient un garde-fou : les passages en production sont bloqués si les critères de sécurité ne sont pas respectés.
- Intégration IDE (SonarLint) : Pour une intégration encore plus tôt dans le cycle de développement, il est possible d’utiliser SonarLint dans son IDE.
SonarLint est un plugin (disponible pour IntelliJ, VS Code, Eclipse, etc.) qui analyse le code pendant son écriture.
Il informe les développeurs de failles pendant qu’ils développent, leur permettant de corriger les vulnérabilités avant les commits.
En automatisant SonarQube dans le CI/CD, on ancre la sécurité au cœur du développement.
Les équipes reçoivent un retour rapide, corrigent et adoptent la sécurité comme critère incontournable de chaque livraison.
Les meilleures pratiques avec SonarQube
Bien interpréter les rapports
Recevoir des alertes de sécurité via SonarQube est utile, les interpréter et y répondre l’est davantage.
L’outil propose une vue globale et des détails précis pour faciliter cette tâche.
Le tableau de bord présente un Score de sécurité (A à E), le nombre de Vulnérabilités ouvertes et des “Security Hotspots” à vérifier.
Un E révèle des problèmes sérieux. Cette vue rapide donne un premier aperçu de l’état général du projet.
Dans la liste des Issues, on peut trouver les détails nécessaires à l’analyse et à la résolution : titre, gravité, règle enfreinte ainsi que sa localisation dans le code source.
Il y a également une explication sur le risque et la solution. Ces conseils sont souvent accompagnés de bonnes pratiques ou de documentations.
Il faut ensuite déterminer le plan d’action : corriger rapidement les failles critiques, planifier la correction des mineures, sans les laisser s’accumuler dans le temps.
En ce qui concerne les “Security Hotspots”, une étape de revue s’impose : attribuer leur vérification à l’équipe puis, décider s’ils sont à corriger ou non (faux positif, ou risque accepté).
En somme, bien utiliser SonarQube Security revient à intégrer ces rapports dans le quotidien et la gestion globale des projets.
Intégrer l’outil dans une approche DevSecOps
Pour maximiser l’efficacité de SonarQube, il faut l’envisager non pas comme un outil isolé mais comme une brique de la culture “DevSecOps”. Quelques conseils :
- Privilégier l’approche “Shift Left” : Intégrer SonarQube dans les processus, dès les premières phases du développement. En faire un critère d’acceptation ancre la sécurité comme un critère de qualité.
- Sensibiliser l’équipe : Un développeur qui comprend pourquoi une vulnérabilité est un problème codera naturellement de manière plus sûre. Les rapports de SonarQube peuvent aider les développeurs à comprendre ces risques et leurs solutions. L’organisation de sessions de formation internes en complément permet de renforcer cette prise de conscience. Avec le temps, les bonnes pratiques s’installent, SonarQube jouant alors un rôle de garde-fou.
- Intégrer SonarQube aux workflows : En automatisant les analyses dans les pipelines CI/CD, en intégrant les résultats des rapports dans la gestion de projet et en gérant les vulnérabilités via des tickets.
- Compléter avec d’autres outils : SonarQube se focalise sur l’analyse statique du code.
Néanmoins, une sécurité globale nécessite en plus l’analyse des dépendances (ex. Snyk), des scans de conteneurs (Trivy), des analyses dynamiques ou des tests manuels.
Pour en savoir plus sur les outils DevSecOps, nous avons un article dédié.
Peut-on intégrer SonarQube avec un outil DAST ou IAST ?
De nombreuses équipes cherchent à combiner différents types d’analyses dans leurs pipelines CI/CD.
Avec SonarQube pour le SAST, l’ajout d’un outil DAST (comme Checkmarx) ou IAST permet d’élargir le périmètre d’analyse.
SonarQube ne permet cependant pas de regroupes les résultats dans son interface.
Pourtant, faire coexister SonarQube avec un DAST ou IAST reste tout à fait possible :
- Exécution parallèle dans la CI : Une analyse dynamique peut également être lancée dans la pipeline. Si l’une des deux méthodes détecte une faille critique, la pipeline peut être bloquée.
- Consolidation et centralisation des rapports : Pour une vue d’ensemble, des outils tiers comme “DefectDojo” permettent d’importer les résultats de SonarQube et d’un outil DAST, offrant une synthèse claire. Les forges comme GitLab ou GitHub proposent également des tableaux de bord de sécurité.
- Synergie : SonarQube et DAST/IAST ne s’opposent pas, ils se complètent. Les deux sont essentiels. Leur combinaison renforce la détection des vulnérabilités.
En clair, associer SonarQube à des outils d’analyse dynamique élargit la couverture en matière de sécurité. La coordination passe par les processus – pipeline, rapports unifiés – plutôt que par SonarQube seul.
Limitations et alternatives à SonarQube
Limites de SonarQube en matière de sécurité des applications
SonarQube se limite au code statique, manquant les vulnérabilités n’apparaissant qu’à l’exécution.
L’analyse est faite sur la base des règles définies par Sonar. De nouvelles vulnérabilités peuvent passer inaperçues et des faux positifs peuvent être générés.
SonarQube n’analyse que le code. Il ne détecte pas les problèmes d’infrastructure ou de configuration serveur. Il peut produire des faux positifs et n’est pas un substitut à un outil de sécurité d’infrastructure.
Comparaison avec d’autres outils de sécurité
Divers outils répondent à des besoins proches de ceux couverts par SonarQube, chacun avec sa spécificité :
- Checkmarx : Cette solution propose plus de fonctionnalités que SonarQube. La plateforme intègre SAST, DAST, SCA, sécurité des conteneurs et de l’IaC.
- Veracode : Veracode propose SAST, DAST et analyse des dépendances. On lui envoie le code et il nous retourne un rapport des failles détaillé, idéal pour la conformité et les audits.
- Snyk : Snyk est un outil polyvalent, SAST, SCA, sécurité des conteneurs et de l’IaC.
Comment Qim info vous aide à mettre en œuvre SonarQube ?
Chez Qim info, nous vous accompagnons à chaque étape de l’intégration de SonarQube Security pour faire de la sécurité applicative un levier de performance. Grâce à notre approche personnalisée, nous vous formons aux enjeux de la sécurité, à la prise en main de l’outil et à son intégration fluide dans vos pipelines CI/CD. Nous assurons également un suivi régulier pour vous aider à décrypter les rapports, ajuster les règles et connecter SonarQube à d’autres solutions de sécurité.
Notre accompagnement se décline en trois volets :
- Conseil et formation : analyse de vos besoins et apprentissage pratique de l’outil.
- Mise en œuvre technique : déploiement du serveur ou de SonarCloud, configuration des profils et Quality Gates, intégration dans vos pipelines CI/CD.
- Suivi et progrès : assistance à l’analyse des rapports, ajustements continus, et synergies avec d’autres outils de sécurité, y compris des scanners d’images de conteneurs.
Forts de notre savoir-faire en DevSecOps et en sécurité, nous vous aidons à ancrer durablement SonarQube dans vos pratiques. Résultat : des équipes plus autonomes, un code plus robuste, et des projets mieux protégés.
Nos équipes du Centre d’expertises disposent d’un socle de connaissances partagées. Ils bénéficient de montées en compétence croisées, assurant la capacité à suivre toutes les évolutions. Faites le choix de l’excellence collective pour sécuriser, optimiser et faire évoluer votre environnement IT avec confiance.
