Qu’est-ce que l’analyse de code sécurisée ?
L’analyse de code sécurisée (également appelée revue de code sécurisée) consiste à évaluer le code pour y déceler des failles potentielles de sécurité et des problèmes de qualité. Elle s’appuie sur des outils et des techniques spécialisés pour identifier et corriger :
des signaux de mauvaise qualité (code smells) ;
des erreurs, des bogues ;
des vulnérabilités ;
des secrets en dur ;
des risques pour la confidentialité des données.
L’analyse concerne le code interne, les bibliothèques tierces, les images de conteneurs et les dépôts publics.
De la même manière que les correcteurs grammaticaux éliminent les fautes d’orthographe et de grammaire de vos documents, les analyseurs de code détectent des vulnérabilités et des inefficacités potentielles dans votre code, afin que seul un code de qualité et sécurisé parte en production.
Dans cet article, vous découvrirez étape par étape le processus d’analyse de code, ses bénéfices, les approches possibles et les bonnes pratiques à adopter.
Watch 5-min Wiz Code demo
See how Wiz Code surfaces SAST, SCA, IaC, and secrets findings alongside real runtime exposure.
Quelles vulnérabilités l’analyse de code peut-elle détecter ?
Les outils d’analyse de code détectent un large éventail de vulnérabilités, y compris celles répertoriées dans l’OWASP Top 10. Les techniques utilisées comprennent l’analyse de flux, l’analyse sémantique, la recherche de motifs, le fuzzing et l’analyse heuristique. Voici quelques exemples de vulnérabilités détectées et la manière dont elles sont identifiées :
| Vulnérabilité | Mécanisme de détection |
|---|---|
| Injection SQL | En recherchant des défaillances de validation ou de sanitisation des entrées et d’autres problèmes de conception logicielle, permettant à des utilisateurs d’injecter des requêtes SQL dans des champs de saisie sans filtrage approprié |
| Falsification de requête intersite (CSRF) | En identifiant une validation des entrées insuffisante ou des jetons système non sécurisés, permettant à des attaquants d’exploiter la confiance accordée par le système à un utilisateur authentifié |
| Exécution de code à distance (RCE) | En recherchant des erreurs de configuration ou des mécanismes de validation inadéquats, permettant à des attaquants d’exécuter du code arbitraire à distance |
| Débordements de tampon | En détectant des erreurs de configuration autorisant l’envoi de données d’entrée au-delà de ce qu’un tampon peut normalement contenir |
| Secrets en dur | En scannant des motifs à forte entropie ou des signatures connues indiquant la présence de secrets dans le code, notamment des jetons d’API ou des mots de passe administrateur |
Exemples concrets
1. L L’attaque MOVEit Transfer : une attaque par injection SQL ciblant MOVEit Transfer a été identifiée en mai 2023. Elle exploitait trois vulnérabilités critiques d’injection SQL dans le code du service de transfert de fichiers géré (MFT). Cela permettait d’exfiltrer des données, impactant de nombreux clients de MOVEit Transfer, dont GreyNoise et Kroll.
Tout indique que la vulnérabilité est restée présente longtemps, possiblement plus de deux ans. Elle aurait pu être détectée et corrigée plus rapidement si une analyse de code avait été mise en place. Cela aurait ainsi évité l’attaque et les dommages réputationnels qui s’ensuivent pour MOVEit Transfer.
2. La vulnérabilité RCE d’Ollama : en juin 2024, l’équipe Wiz Research a découvert une vulnérabilité exploitable d’exécution de code à distance (CVE-2024-37032) dans Ollama, un projet open source populaire pour exécuter des modèles d’IA. Cette vulnérabilité permettait à des attaquants d’envoyer des requêtes HTTP spécialement conçues vers le serveur d’API exposé d’Ollama.
Bien que le problème de sécurité ait depuis été corrigé, les développeurs de projets d’IA (et de tout logiciel exposé sur Internet) peuvent en tirer une leçon essentielle : l’analyse de code est cruciale pour corriger les erreurs de configuration et les risques de sécurité comme les vulnérabilités RCE.
Pourquoi l’analyse de code est-elle importante ?
L’analyse de code sécurisée est devenue indispensable dans le processus de développement logiciel, car les problèmes de sécurité du code sont inévitables. Ils peuvent rapidement devenir des vulnérabilités exploitables ayant un impact sur les équipes de développement, les utilisateurs et l’infrastructure. Voici pourquoi vous devriez analyser votre code à la recherche de vulnérabilités avant la mise en production :
Des cycles de livraison accélérés laissent passer des bogues et des failles
De plus en plus, les entreprises raccourcissent les cycles de publication pour devancer la concurrence. Cependant, comme cela réduit le temps dont disposent les équipes de développement et de sécurité pour construire des applications et traiter les risques potentiels, ces cycles rapides conduisent souvent au déploiement de logiciels vulnérables.
Avec l’analyse de code, les équipes de développement peuvent planifier des exécutions périodiques ou déclencher une analyse à chaque ajout de code dans leurs IDE. Plus l’analyse de code est introduite tôt dans le processus de développement, plus le coût et la complexité de la remédiation diminuent. Cela permet d’accélérer les cycles de livraison tout en garantissant la sécurité.
Les fuites de données sont plus fréquentes
Selon Forrester, rien qu’en 2023, on a recensé 3 205 fuites de données, soit environ 9 par jour. En signalant des vulnérabilités potentielles avant le déploiement, l’analyse de code intègre des pratiques de codage sécurisé dans le cycle de vie du développement logiciel (SDLC). Ainsi, elle améliore la sécurité et la qualité des logiciels tout en réduisant la fréquence et la gravité des fuites de données.
Les fuites de données coûtent cher
Les conséquences d’une fuite de données sont considérables :
sanctions pour non-conformité ;
actions en justice ;
coûts financiers et réputationnels ;
perte de confiance des clients.
À titre d’exemple, l’opérateur télécom T-Mobile a dépensé 350 millions de dollars pour régler un recours collectif après une fuite de données en juillet 2022. Et ce n’est pas tout ! T-Mobile a aussi supporté des frais juridiques importants et s’est engagé à 150 millions de dollars de dépenses de sécurité des données. Cela a sérieusement entamé sa réputation et la confiance de ses clients.
Pour éviter de telles conséquences, l’analyse de code suit les flux de données au sein des applications logicielles. Il signale de manière proactive les données sensibles dans des appels de fichiers et des appels de fonctions pour permettre une remédiation en amont.
State of Code Security in 2025
Code scanning is a must-have security practice, yet 80% of GitHub repositories have insecure workflow permissions, according to the State of Code Security Report 2025. Even the best scanning tools can't compensate for weak CI/CD security.
Download report
Comment fonctionne la Software Composition Analysis (SCA) ?
La Software Composition Analysis (SCA) fonctionne en scannant systématiquement la base de code de votre application. Elle détecte les dépendances open source et identifie des risques de sécurité, de licence et d’exploitation. Le workflow type d’une SCA comprend plusieurs étapes clés :
1. Découverte des dépendances
Les outils de SCA analysent le code source de votre application, les fichiers de build (comme package.json, requirements.txt, pom.xml), les images de conteneurs et parfois même les binaires pour inventorier tous les composants open source. Cela inclut :
les dépendances directes que vous déclarez explicitement ;
les dépendances transitives (indirectes) tirées automatiquement par d’autres packages.
2. Identification des composants
Les dépendances identifiées sont associées à une empreinte logicielle unique (noms de packages, versions, signatures de code) et rapprochées de bases de données logicielles de référence, telles que :
des bases publiques de vulnérabilités (par ex. NVD, GitHub Advisories) ;
des registres de packages (par ex. npm, PyPI, Maven Central) ;
des sources propriétaires de threat intelligence, selon l’outil.
Cette étape garantit une correspondance exacte avec les métadonnées et vulnérabilités connues.
3. Corrélation des vulnérabilités
Une fois les composants identifiés, les outils de SCA les recoupent avec des bases de vulnérabilités pour faire ressortir :
les CVE connus (Common Vulnerabilities and Exposures) ;
des informations d’exploitabilité (par ex. vulnérabilité activement exploitée) ;
des niveaux de sévérité (scores CVSS).
4. Vérifications des licences et des politiques
Au-delà des problèmes de sécurité, la SCA évalue les licences associées à chaque composant (par ex. GPL, MIT, Apache 2.0) et signale :
les licences incompatibles avec les politiques de votre organisation ;
les licences copyleft susceptibles d’introduire des obligations juridiques.
5. Scoring et priorisation du risque
Les outils de SCA modernes vont au-delà de la simple détection et appliquent un score de risque fondé sur :
la criticité de la dépendance (par ex. est-elle chargée au runtime ?) ;
la sévérité des vulnérabilités ;
une analyse de portée (reachability) pour déterminer si les chemins vulnérables sont effectivement invoqués.
6. Recommandations de remédiation exploitables
La SCA propose des options de remédiation concrètes :
des recommandations de mise à niveau (versions de packages plus sûres) ;
des pull requests correctives ou des correctifs (dans des outils orientés développeurs).
7. Surveillance continues
De nombreuses solutions de SCA offrent une surveillance continue et vous alertent si des vulnérabilités nouvellement découvertes affectent des composants déjà déployés, même après la mise en production du code.
Approches de l’analyse de code
Il existe un large éventail de techniques et d’outils pour l’analyse de code, chacun avec ses propres cas d’usage. Regardons cela de plus près :
| Techniques/outils | Description |
|---|---|
| Tests de sécurité applicative statiques (SAST) | Les outils d’analyse statique scannent le code source au repos pour trouver des risques de sécurité courants : packages obsolètes, problèmes de contrôle d’accès, entrées externes non assainies et débordements de tampon. |
| Tests de sécurité applicative dynamiques (DAST) | L’analyse dynamique simule des attaques pour détecter des vulnérabilités en temps réel telles que l’exécution de code à distance (RCE), les conditions de concurrence et la falsification de requête intersite (CSRF). |
| Analyse de la composition logicielle (SCA) | Les outils de SCA évaluent le code source, les fichiers binaires, les images de conteneurs, les gestionnaires de packages, etc. Ils inventorient les dépendances et les vulnérabilités associées en comparant ces dépendances à des bases de vulnérabilités telles que la National Vulnerability Database (NVD). |
| Tests de sécurité applicative interactifs (IAST) | L’IAST combine des éléments de SAST et de DAST. |
| Détection de secrets | Les outils de détection de secrets analysent des dépôts publics, des images de conteneurs, des pipelines DevOps, etc., à la recherche d’identifiants codés en dur afin de prévenir les accès non autorisés à des infrastructures cloud sensibles. |
Les défis de l’analyse de code
Comme le montre le tableau ci-dessus, chaque technique d’analyse de code a ses avantages et ses inconvénients. Au-delà de ces inconvénients, deux défis sont récurrents : les faux positifs et les faux négatifs. Ils surviennent lorsque les outils identifient des vulnérabilités inexistantes (faux positifs) ou manquent des vulnérabilités présentes (faux négatifs).
Pour réduire au minimum les faux positifs et les faux négatifs, la bonne pratique consiste à appliquer plusieurs techniques et outils tout au long du SDLC. Vous bénéficierez ainsi des avantages de chaque approche sans subir ses inconvénients.
CI/CD Pipeline Security Best Practices [Cheat Sheet]
In this 13 page cheat sheet we'll cover best practices in the following areas of the CI/CD pipeline: Infrastructure security, code security, secrets management, access and authentication, monitoring and response
Avantages de la Software Composition Analysis
La SCA offre plusieurs bénéfices clés qui aident les organisations à sécuriser leur chaîne d’approvisionnement logicielle et à réduire les risques applicatifs :
Détection précoce des risques : identifier tôt les vulnérabilités connues dans les dépendances pour réduire les incidents de sécurité en aval.
Conformité des licences : respecter vos obligations légales en détectant des licences open source à risque de non-conformité.
Visibilité sur la chaîne d’approvisionnement : obtenir une visibilité complète sur les dépendances directes et transitives, afin de réduire le risque d’angles morts.
Remédiation plus rapide : en localisant précisément où un composant vulnérable est utilisé, la SCA aide les développeurs à corriger plus vite, souvent avant le déploiement.
Activation du shift-left (approche préventive en amont du cycle de développement) : la SCA s’intègre aux pipelines CI/CD et aux workflows des développeurs. Cela facilite l’application des politiques de sécurité sans ralentir la vélocité de développement.
7 bonnes pratiques essentielles pour l’analyse de code
1. Élaborez une politique de protection du code source précisant :
comment et quand vous souhaitez analyser votre code source ?
comment vous voulez le protéger (par ex. via le chiffrement) ?
quels rôles administratifs doivent avoir accès à votre code et aux pipelines DevOps ?
Ainsi, vous protégerez votre code contre toute altération non autorisée ou tout vol.
2. Choisissez la bonne combinaison d’outils en tenant compte de leur capacité à :
automatiser vos workflows afin de ne pas ralentir les cycles de publication ;
prendre en charge tous les langages de votre stack pour éviter des angles morts ;
détecter des vulnérabilités potentielles à la volée pour aider les équipes de développement à adopter des pratiques de codage sécurisé, comme celles de la liste de pratiques de codage sécurisé de l’OWASP ;
fournir une veille à jour sur les vulnérabilités afin de minimiser les faux négatifs ;
permettre une gestion de la conformité dans le code pour éviter des fuites et des amendes réglementaires ;
offrir des rapports robustes avec des insights actionnables pour une remédiation rapide ;
favoriser la collaboration inter-équipes afin d’améliorer la sécurité logicielle sans ralentir les cycles de livraison.
3. Testez tôt les failles de sécurité du code : Cette bonne pratique consiste à adopter une approche shift-left, security by design, qui unit les équipes DevSecOps. À terme, elle vous fait économiser l’argent, le temps et les efforts que vous auriez consacrés à des revues de code sécurisées plus complexes si la sécurité n’était intégrée qu’à un stade ultérieur.
4. Exécutez des analyses automatisées et planifiées : Comme indiqué, ces deux types d’analyses sont utiles selon les scénarios. Les analyses automatisées fournissent un retour immédiat sur les problèmes tout au long du SDLC, tandis que les analyses planifiées offrent une photographie approfondie à un instant T. Cela est utile pour suivre l’évolution de votre programme de sécurité du code dans le temps.
5. Traitez les risques sans délai : Une étude de Forbes montre qu’au moins 23 % des alertes cloud restent non investiguées et non résolues par les équipes de sécurité. Or, des risques non traités offrent des opportunités aux attaquants. Pour ne pas être une cible facile, appliquez rapidement les correctifs et mettez à jour vos logiciels. Choisissez aussi des outils qui priorisent les risques et réduisent la surcharge d’alertes, afin d’éviter la nécessité de validations manuelles.
6. Réglez finement la configuration des outils pour qu’elle corresponde à vos besoins. Cela inclut l’intégration du contexte métier, l’ajustement des seuils de sensibilité, l’ajout d’exceptions, de listes blanches et de listes noires si nécessaire, ainsi que la définition de règles et de signatures. Combinées à l’emploi de plusieurs outils et techniques d’analyse, ces stratégies produisent des résultats complets et précis, avec peu ou pas de faux positifs.
7. Renforcez la sensibilisation au codage sécurisé via la formation, la responsabilisation et une veille sur l’évolution des tendances des vulnérabilités. Aidez les développeurs à comprendre que partir d’un code propre est dans leur intérêt. Il y aura moins de vulnérabilités à traiter après la mise en production avec une approche shift-left de la sécurité.
Wiz pour le code security
L’approche de Wiz en matière d’analyse de code sécurisée s’articule autour de sa plateforme CNAPP complète, qui intègre la sécurité du code à la sécurité du cloud. Wiz Code, une nouveauté de notre plateforme, va plus loin en proposant des analyses agentless des vulnérabilités, des erreurs de configuration et des secrets directement dans le code, avant son déploiement en production.
En analysant à la fois le code de l’application et l’infrastructure en tant que code (IaC), Wiz assure une couverture de sécurité complète et détecte les vulnérabilités dès les premières phases du développement. Cela réduit les risques en permettant aux équipes de développement de détecter et de corriger plus rapidement, tout en favorisant des pratiques de codage sécurisé qui s’alignent avec les workflows modernes de DevSecOps.
L’intégration de Wiz Code dans les pipelines CI/CD assure également une analyse et une surveillance continues, permettant aux développeurs de maintenir la sécurité sans interrompre leurs workflows. Ainsi, les organisations conservent une posture de sécurité robuste tout en accélérant l’innovation dans les environnements cloud.
Secure your cloud from code to production
Learn why CISOs at the fastest growing companies trust Wiz to accelerate secure cloud development.
