SonarQube pour analyser et renforcer la sécurité du code 

SonarQube est un outil incontournable pour analyser la qualité et la sécurité du code source.

Points clés :

• SonarQube effectue une analyse statique du code pour détecter bugs, failles et mauvaises pratiques.
• L’outil s’intègre facilement dans les pipelines CI/CD pour un contrôle continu.
• Les règles de sécurité et les Quality Gates sont personnalisables selon les besoins du projet.

Qu’est-ce que SonarQube ?

Définition et rôle  

SonarQube est une plateforme d’analyse statique du code (SAST) qui aide les équipes de développement à détecter les vulnérabilités, les bugs et les problèmes de qualité avant la mise en production.

➡️ Ce qu’il fait : SonarQube examine directement le code source afin d’identifier des risques de sécurité tels que les injections SQL, les failles XSS ou d’autres erreurs de développement qui pourraient être exploitées par un attaquant.

Au-delà de la détection des vulnérabilités, la solution centralise les résultats d’analyse dans une interface unique. Les équipes peuvent : 

• suivre les anomalies, 
• les prioriser selon leur niveau de criticité, 
• les attribuer aux développeurs
• piloter leur correction dans le temps.

➡️ Ce qu’il apporte concrètement : intégré aux chaînes CI/CD et aux pratiques DevSecOps, SonarQube permet ainsi de traiter les problèmes de sécurité dès les premières phases du développement et de renforcer la qualité du code.

SonarQube prend-il en charge le SAST, le SCA et le DAST ?  

SonarQube est avant tout une plateforme SAST. Son rôle consiste à analyser le code source. D’autres approches répondent à des problématiques complémentaires :

• Le SCA (Software Composition Analysis s’intéresse aux dépendances et aux composants open source utilisés par l’application afin d’identifier les vulnérabilités connues (CVE).
• Le DAST (Dynamic Application Security Testing) teste une application en cours d’exécution pour détecter des failles exploitables dans son comportement réel.

Ces approches sont complémentaires : le SAST analyse le code développé par les équipes, le SCA examine les bibliothèques tierces et le DAST évalue l’application une fois déployée.

Pour répondre à ce besoin, SonarSource a introduit SonarQube Advanced Security, qui étend les capacités de la plateforme avec des fonctionnalités de Software Composition Analysis (SCA) et d’analyse de sécurité avancée.

Qu’est-ce que SonarQube Advanced Security ?

SonarQube Advanced Security est une extension de niveau entreprise de la plateforme intégrée SonarQube.

Dans une application, une part importante du risque provient également des dépendances open source et des interactions avec des bibliothèques tierces. C’est précisément le problème que cherche à résoudre SonarQube Advanced Security avec deux fonctionnalités majeures :

• le Software Composition Analysis (SCA) pour identifier les vulnérabilités connues (CVE), les packages malveillants et certains risques liés aux licences open source ;
• l’Advanced SAST pour pousser l’analyse de sécurité plus loin en suivant les flux de données au-delà du seul code métier.

Concrètement, SonarQube est également capable d’évaluer les risques introduits par les bibliothèques et les composants tiers utilisés par l’application.

💡 L’un des apports les plus intéressants réside dans la détection des vulnérabilités dites cross-boundary. Certaines failles n’apparaissent ni dans votre code, ni dans une bibliothèque prise isolément, mais dans l’interaction entre les deux. Grâce à une analyse de flux avancée, SonarQube Advanced Security peut mettre en évidence ce type de scénario complexe, souvent difficile à détecter avec les approches traditionnelles.

Comment SonarQube analyse-t-il la sécurité du code ? 

Comment fonctionne l’analyse statique de sécurité ?

Étape 1 : analyse du code source. Lorsqu’une analyse est lancée, SonarQube parcourt le code source du projet et applique un ensemble de règles de sécurité adaptées au langage utilisé (Java, C#, JavaScript, Python, etc.).

Étape 2 : détection de patterns à risque. Le moteur d’analyse recherche des schémas de code connus pour être associés à des vulnérabilités ou à des pratiques dangereuses.

Étape 3. attribution d’un niveau de sévérité. Chaque problème détecté est qualifié selon sa nature et sa criticité afin d’aider les équipes à prioriser les corrections.

Étape 4 : restitution des résultats. Les résultats sont ensuite centralisés dans l’interface SonarQube, où les développeurs peuvent analyser les alertes, comprendre leur origine et suivre leur correction.

💡N’hésitez pas à consulter notre article sur le clean code.

Exemples de vulnérabilités détectées par SonarQube 

Parmi les principaux problèmes de sécurité que SonarQube peut mettre en évidence :

• Les injections (SQL, OS, LDAP, etc.) : des données contrôlées par un utilisateur sont utilisées sans validation ou protection suffisante, ouvrant la voie à des injections de commandes ou de requêtes.
• Les failles Cross-Site Scripting (XSS) : des situations dans lesquelles des données non maîtrisées sont renvoyées vers un navigateur sans mécanisme de protection approprié, augmentant le risque d’attaques XSS.
• L’exposition de données sensibles : mots de passe codés en dur, clés d’API, identifiants embarqués dans le code ou usages cryptographiques obsolètes.
• Les pratiques d’authentification à risque, comme l’utilisation de mots de passe stockés directement dans le code.
• Les usages dangereux de certaines API ou mécanismes de développement, notamment autour de la désérialisation ou de la manipulation de données non fiables.

💡 SonarQube distingue deux types de remontées de sécurité : 

1. Les Vulnerabilities sont des failles de sécurité identifiées dans le code, qui doivent être corrigées car elles représentent un risque avéré. 
2. Les Security Hotspots signalent des portions de code sensibles qui nécessitent une revue humaine afin de déterminer si un risque réel existe.

Les Security Rules de SonarQube

Les Security Rules constituent le socle de détection de SonarQube. Elles permettent à l’outil d’identifier automatiquement des vulnérabilités, des comportements à risque et des pratiques de développement non conformes aux standards de sécurité.

 Ces règles sont généralement reliées à des référentiels reconnus tels que : 

• OWASP Top 10,
• CWE Top 25,
• OWASP ASVS,
• PCI DSS,
• CERT Secure Coding…

Cette correspondance permet de relier les vulnérabilités détectées à des catégories de risques largement utilisées dans l’industrie. Voici les principaux référentiels pris en compte : 

• OWASP Top 10 (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.  

SonarQube intègre de nombreuses règles de sécurité associées aux risques décrits dans l’OWASP Top 10, notamment autour des injections, de la gestion des données sensibles ou des mécanismes d’authentification.

• CWE Top 25 (Common Weakness Enumeration), 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.  

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. 

SonarQube for IDE

Cette extension gratuite agit comme un filet de sécurité en temps réel.

Son véritable intérêt apparaît en Connected Mode :  l’IDE est relié à SonarQube Server ou SonarQube Cloud et applique les mêmes règles que le projet : Quality Profile, exclusions, paramètres d’analyse, statuts des issues déjà acceptées ou marquées comme faux positifs. Le développeur travaille avec les mêmes exigences que celles utilisées dans l’analyse centralisée.

💡 Toutes les vulnérabilités ne peuvent pas être détectées uniquement par l’analyse locale de l’IDE. Les failles plus complexes nécessitent une analyse complète côté SonarQube Server ou SonarQube Cloud.

En clair, SonarQube for IDE ne remplace pas l’analyse centralisée : il la rapproche du développeur.

Les bonnes pratiques de sécurité avec Sonarqube

Shift Left Security

Le Shift Left Security, c’est l’idée de déplacer les contrôles de sécurité le plus tôt possible dans le cycle de développement. Au lieu de découvrir les vulnérabilités à la fin (en audit, en pentest ou juste avant la mise en production), on cherche à les identifier dès l’écriture du code, puis à chaque étape du delivery.

Dans cette logique, SonarQube agit à plusieurs niveaux :

• Dans l’IDE, avec SonarQube for IDE : le développeur reçoit des alertes pendant qu’il écrit son code. C’est le niveau le plus “left” possible : le problème est détecté avant même le commit.
• Dans la pull request ou merge request : SonarQube peut analyser le code modifié avant son intégration. L’équipe peut alors bloquer ou corriger une vulnérabilité avant qu’elle n’entre dans la branche principale.
• Dans la pipeline CI/CD : l’analyse devient un contrôle automatisé. Les Quality Gates peuvent empêcher la livraison d’un code qui ne respecte pas les critères définis, par exemple en présence de nouvelles vulnérabilités critiques.
• Dans le suivi projet : SonarQube centralise les issues, les Security Hotspots, les niveaux de sévérité, les faux positifs acceptés et l’évolution de la dette technique ou sécurité dans le temps.

Personnaliser les Quality Gates et les Quality Profile

Il faut définir quelles règles appliquer et à partir de quel seuil un code devient inacceptable. C’est exactement le rôle des Quality Profiles et des Quality Gates.

Le Quality Profile détermine les règles utilisées pendant l’analyse. Chaque langage dispose d’un profil par défaut, comme Sonar way, mais ce profil peut être adapté au contexte du projet. Côté sécurité, un bon profil doit refléter le niveau de risque réel du projet. Les règles liées aux injections, à l’exposition de secrets, aux usages cryptographiques faibles ou aux Security Hotspots doivent être sélectionnées avec soin, puis documentées lorsqu’une exception est décidée.

La Quality Gate, elle, joue un rôle différent : elle transforme ces analyses en décision. Le code passe ou échoue selon des conditions définies à l’avance. 

Exemple : une organisation peut décider qu’aucune nouvelle vulnérabilité critique ne doit être introduite, que tous les nouveaux Security Hotspots doivent être revus, ou que le niveau de duplication et de couverture de tests doit rester dans les seuils acceptés.

La bonne pratique consiste à commencer par le nouveau code. Plutôt que d’essayer de corriger toute la dette historique d’un coup, on empêche d’abord l’introduction de nouvelles vulnérabilités. Ensuite, les équipes peuvent traiter progressivement les problèmes existants, sans bloquer brutalement l’ensemble du projet.

Enfin, les faux positifs et les risques acceptés doivent rester encadrés. Une alerte peut être écartée après revue, mais cette décision doit être tracée. C’est ce qui permet de garder un équilibre sain : assez strict pour éviter les dérives, assez pragmatique pour rester compatible avec la réalité 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 et 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.  

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 : 

• 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. 
• 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 : pour en savoir plus sur les outils DevSecOps, nous avons un article dédié.

Limites de SonarQube en matière de sécurité des applications

SonarQube ne couvre pas à lui seul toute la sécurité applicative.

Sa première limite vient de son approche statique. Il peut donc identifier des vulnérabilités visibles dans le code, mais il ne teste pas le comportement réel de l’application en fonctionnement. 

Deuxième limite : l’analyse dépend des règles disponibles, activées et adaptées au langage utilisé. Il ne peut pas garantir l’absence de vulnérabilité. Comme tout outil SAST, il peut générer des faux positifs, mais aussi laisser passer certains cas plus complexes ou trop dépendants du contexte applicatif.

Troisième limite : SonarQube n’analyse pas toute la surface de sécurité d’un système. Il ne remplace pas un outil DAST pour tester une application déployée, ni un outil SCA dédié à l’analyse des dépendances, ni des solutions de sécurité infrastructure, cloud, container ou serveur. Il ne remplace pas non plus une revue d’architecture ou un test d’intrusion lorsque le niveau de risque l’exige.

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

Checkmarx 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 la sécurité avec 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 DevOps 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. 

FAQ

Peut-on intégrer SonarQube avec un outil DAST ou IAST ? 

Faire coexister SonarQube avec un DAST ou IAST est 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 : 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. 

Comment installer et configurer Sonarqube ?

• Étape 1 : vérifier les prérequis serveur : Java, RAM, espace disque, base de données et paramètres système, en particulier sous Linux ; télécharger ici la version qui convient à vos besoins. 
• Étape 2 : SonarQube peut être auto-hébergé via SonarQube Server. Les équipes qui souhaitent limiter l’exploitation de l’infrastructure peuvent aussi se tourner vers SonarQube Cloud, l’offre SaaS de SonarSource.
• Étape 3 : créer un projet correspondant au code à analyser, puis générer un token d’analyse.
• Étape 4 : lancer l’analyse avec SonarScanner, qui transmet les résultats au serveur SonarQube, où ils sont consultables sous forme d’issues, de Security Hotspots, d’indicateurs de qualité et de tableaux de bord.

Qu’est-ce qu’une vulnérabilité dans SonarQube ?

C’est une faille de sécurité identifiée dans le code source par une règle d’analyse. Elle indique qu’un comportement du code peut exposer l’application à un risque.

Chaque vulnérabilité est remontée sous forme d’issue, avec 

• un emplacement dans le code, 
• une explication du problème, 
• un niveau de sévérité
• des recommandations destinées à guider la correction.

Il faut toutefois distinguer les Vulnerabilities des Security Hotspots. Une Vulnerability correspond à un problème que SonarQube considère comme une faille à corriger. Un Security Hotspot, lui, signale une portion de code sensible qui doit être revue manuellement avant de conclure qu’il existe réellement un risque.