19/05/2026
Cybersecurity Insights
Cybersécurité logicielle : quel ROI pour les audits et évaluations de sécurité ?
Pour de nombreuses entités publiques ou privées, la cybersécurité est encore un centre de coût. En particulier, les audits de sécurité des logiciels peuvent représenter une charge de travail supplémentaire pour les équipes internes, de surcroît si celles-ci doivent gérer la correction des vulnérabilités découvertes.
Néanmoins ces audits de sécurité ont un réel intérêt, en particulier par leurs capacités à identifier des failles de sécurité et ainsi à renforcer la sécurité de ces logiciels. Alors quelle place ces audits doivent-ils prendre dans la stratégie d’un décideur IT ?
C’est notamment à cette question que nous proposons ici d’apporter un éclairage, sous la forme d’une interview croisée entre Frédéric Babin, en charge de la politique industrielle relative à l’open source de l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information), et Alexandre Deloup, directeur du CESTI (Centre d’Evaluation de la Sécurité des Technologies de l’Information) du Groupe Almond.
Avant de démarrer, pouvez-vous rappeler en quelques lignes en quoi consiste un audit de sécurité sur un logiciel ?
ANSSI : Auditer la sécurité d’un produit informatique, c’est évaluer de manière rigoureuse et formalisée son niveau de résistance face aux menaces (attaques, fuites de données, compromissions…) pour identifier des vulnérabilités et des risques. Cette démarche permet de prioriser des failles, d’en évaluer les impacts (confidentialité, intégrité, disponibilité) et de proposer des recommandations de correction concrètes.
En règle générale, un audit se concentre sur un ou plusieurs axes techniques, adaptés à son objectif initial (p. ex. analyse du code source, tests d’intrusion, analyse des dépendances logicielles, revue de l’architecture, analyse de la configuration…).
ALMOND : En complément de ces objectifs, certains éditeurs peuvent réaliser des évaluations de sécurité en vue d’obtenir une certification cyber délivrée par l’ANSSI. Ces évaluations consistent à réaliser des tests d’intrusions sur ces logiciels afin d’estimer leur niveau de sécurité via l’identification, ou non, de vulnérabilités au cours de l’analyse. L’absence de vulnérabilité découverte au cours de l’évaluation permet au produit de prétendre à une certification par l’ANSSI.
Quelle est la motivation première des éditeurs de logiciels qui souhaitent faire réaliser des audits par des laboratoires ?
ALMOND : L’intérêt des éditeurs pour ces audits de sécurité peut être multiple. Pour certains, l’intérêt est le renforcement de la sécurité du logiciel via l’identification de vulnérabilités par un laboratoire expert du domaine. Après un partage et un échange technique autour de ces résultats, les équipes de développement sont en mesure de les corriger et améliorer la sécurité globale du produit.
Pour d’autres, l’enjeu est concurrentiel. Disposer d’un « Visa de Sécurité ANSSI » ou d’un rapport d’audit à mettre en avant auprès des prospects et clients est un argument différentiant vis-à-vis de leurs concurrents.
Justement, en quoi consistent ces « Visas de Sécurité » ?
ANSSI : Une des missions de l’ANSSI est d’intervenir lorsque les enjeux dépassent le cadre de la simple sécurité applicative pour toucher à la sécurité nationale ou stratégique. Dans cet objectif, l’ANSSI a créé les « Visa de sécurité » qui apportent une reconnaissance à des produits de cybersécurité[1] après la réalisation d’un audit de sécurité. Cette notion de Visa est parfois mal comprise. De manière synthétique, il faut retenir que derrière cette marque se cachent deux concepts : la certification et la qualification.
La certification est la reconnaissance de la robustesse d’un produit, éprouvée à travers une évaluation par un tiers (généralement un CESTI[2]), dont la compétence est garantie par l’ANSSI. Elle est établie sur la base d’un contexte d’usage et d’objectifs de sécurité définis par un commanditaire (une entité privée ou publique). Le Centre de certification national (CCN), une entité de l’ANSSI, va vérifier en plus que la cible de sécurité (le périmètre de ce qui va être évalué et le modèle d’attaquants) n’est pas mensongère mais ne va pas « discuter » le périmètre choisi par le commanditaire.
Par opposition, la qualification est la recommandation par l’État d’un produit[3] pour un usage donné. Dans une qualification, le rôle de l’ANSSI va plus loin que dans le cas d’une certification : non seulement elle atteste de la qualité de la solution (robustesse d’un produit aux cyberattaques par la réalisation d’un audit de sécurité et la délivrance éventuelle d’une certification) mais elle témoigne aussi de la confiance qu’a l’État envers l’éditeur logiciel, notamment dans la capacité de ce dernier à respecter sur le long terme un ensemble d’engagements. C’est aussi un moyen de garantir la pertinence de la solution au regard d’un besoin identifié par l’État, qu’il s’agisse de son besoin propre ou du besoin d’entités régulées (Opérateur d’Importance Vitale, Opérateur de services essentiels…). Dans la qualification, l’ANSSI intervient de manière beaucoup plus active dans l’audit de sécurité : en amont, en étant directive dans la définition de la cible de sécurité ; en aval, pour porter un regard critique, à l’instar d’un « maître d’ouvrage », sur les découvertes faites par l’évaluateur et sur le suivi de leur correction effective avant la délivrance de la qualification.
Les Visa de sécurité portent principalement sur des logiciels commerciaux, et vous aurez compris que si l’ANSSI intervient dans le déroulé de ces audits de sécurité, pour autant elle ne les finance pas (c’est le commanditaire qui paie la certification ou la qualification de son produit). Néanmoins, dans le cadre de sa politique industrielle et de sa politique open source[4], l’ANSSI finance et commandite depuis 2017 l’évaluation de logiciels open source.
[1] L’ANSSI délivre aussi des Visa de sécurité pour des services mais ce point est hors sujet pour cet article.
[2] https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/evaluer-les-produits-et-services/centres-evaluation/
[3] Ou d’un service.
[4] https://cyber.gouv.fr/enjeux-technologiques/open-source/
Pourquoi l’ANSSI finance-t-elle des audits de produits open source ?
Quel est l’objectif stratégique derrière ce programme d’évaluation ?
ANSSI : Cet investissement est justifié par l’omniprésence du code open source dans les chaînes d’approvisionnement logicielles, amplifié par la place qu’il joue désormais dans l’intelligence artificielle (où l’open source est à la fois un socle technique et un vecteur d’innovation). L’ampleur du besoin de sécurisation est considérable car les logiciels open source sont essentiels au fonctionnement de la quasi-totalité des actifs numériques. La défaillance, involontaire ou volontaire, d’un composant open source peut avoir des effets désastreux et globaux. Or, une illusion fréquente est de penser que « open source » est synonyme de « sécurisé ». C’est faux. Ce biais de perception tient essentiellement au fait qu’il semble plus difficile de dissimuler une vulnérabilité dans du code accessible à tous. Or la sécurité dépend surtout de la gouvernance des projets et des processus d’audit. Tous les logiciels ont des bugs mais les incentives pour les trouver et les corriger diffèrent : certaines entités les cherchent activement (typiquement les entités commerciales car la révélation d’un bug peut porter atteinte à leur image) tandis que d’autres (en particulier les mainteneurs de projets open source) n’ont pas forcément les moyens de réaliser des audits de sécurité. En tant qu’autorité nationale en matière de cybersécurité, l’ANSSI entend donc apporter sa pierre à l’édifice de la sécurisation de ces composants essentiels au travers de son programme de sécurisation de l’open source[1].
La communauté se dit fréquemment “mieux protégée” par l’utilisation de logiciels open source, car le code est plus facilement auditable.
Dans la pratique, est-ce souvent le cas ?
ALMOND : Comme cela vient d’être évoqué, la publication du code source n’est pas un gage absolu de sécurité. Bien qu’il soit possible à n’importe qui de l’auditer, dans la pratique peu de relectures externes sont réalisées sur les projets open source.
Les développeurs open source travaillent, pour la majorité, seuls ou en équipes très réduites (moins de 2 ou 3 développeurs)[1]. Cette solitude peut contribuer à des problèmes plus larges de dépression ou de burnout affectant les développeurs[2], qui à leur tour peuvent induire des risques en matière de sécurité. Une perte de motivation ou d’intérêt peut amener des projets à dépérir ou leur développeur à laisser la sécurité de côté, conduisant à l’introduction de vulnérabilités dans les logiciels.
De même, une quête de soutien externe peut amener les développeurs à accepter des pull/merge requests sans réaliser des revues de code en profondeur, intégrant ainsi potentiellement des portions de code malveillantes.
Dès lors, ce serait une erreur d’avoir une confiance implicite dans l’écosystème open source. Il est au contraire important de profiter de cette ouverture du code pour réaliser des audits de sécurité réguliers des logiciels et composants open source, afin d’identifier d’éventuelles vulnérabilités et être en mesure de les corriger. On notera à cet égard que la durée de vie des vulnérabilités post-disclosure dans l’open source varie de quelques heures à quelques jours là où cette durée est plus fréquemment de l’ordre de quelques semaines (et, dans les cas les plus extrêmes, de quelques années) dans certains logiciels propriétaires.
Comment choisissez-vous les projets ou produits à auditer ?
Utilisez-vous des critères particuliers (impact, criticité, maturité, communauté) ?
ANSSI : Le nombre potentiel de logiciels open source à auditer est très important, et dépasse largement les capacités de l’ANSSI. Une sélection est donc nécessaire. L’ANSSI regarde en premier lieu la gouvernance du projet open source. Du benevolent dictator for life à une gouvernance pilotée par une entreprise ayant potentiellement de très gros moyens, en passant par le modèle communautaire, un projet aura plus ou moins de capacité à financer par lui-même une évaluation de sécurité et à corriger les problèmes identifiés. L’ANSSI aura tendance à privilégier les logiciels délaissés par les acteurs privés et pourtant très largement utilisés.
Ensuite, l’ANSSI va chercher à maximiser l’intérêt des audits en optant pour des logiciels open source déjà largement déployés par ses bénéficiaires (sphère publique et entités régulées) et/ou ayant une exposition aux menaces importante (p. ex. logiciels exposant des API sur Internet ou ayant une empreinte système importante). De même, l’historique d’évaluation est également analysé : les projets ayant été peu audités seront privilégiés.
Enfin, parce que l’ANSSI joue un rôle dans l’orientation de la politique industrielle en matière de cybersécurité, le critère d’innovation est également considéré. Ainsi, lorsqu’il n’existe pas de solution satisfaisante portée par le secteur privé pour répondre à un besoin donné, l’État peut intervenir. Dans ce contexte, soutenir une solution open source au travers d’une évaluation de sécurité peut constituer un levier pour pallier ce manque du marché.
Quels sont les principaux findings issus de ces audits ?
ALMOND : De nombreux types de résultats peuvent être identifiés au cours de ces audits.
L’un des premiers écueils est l’utilisation de dépendances obsolètes ou non maintenues (qu’il s’agisse de bibliothèques open source, de COTS[1], ou de code développé en interne). Des dépendances obsolètes peuvent être synonyme de vulnérabilités connues (éventuellement corrigées dans des versions ultérieures). Ces vulnérabilités peuvent potentiellement affecter tout logiciel qui les utilise, abaissant ainsi son niveau de sécurité. Des dépendances non maintenues vont, quant à elles, ne plus faire l’objet d’un suivi de vulnérabilité par leur éditeur, ce qui induira que les vulnérabilités identifiées à l’avenir ne seront pas corrigées, rendant par la même occasion vulnérable, de façon pérenne, tout logiciel qui continuera de les utiliser.
Certains logiciels, lorsqu’ils sont développés dans des langages qui demandent une gestion fine de la mémoire (C/C++ par exemple), peuvent faire l’objet de vulnérabilités mémoires, type buffer overflow, use-after-free, etc. Ces vulnérabilités peuvent être identifiées de manière semi-automatisée par des outils d’analyse de code source ou des campagnes de fuzzing (dont la qualité des résultats va néanmoins pouvoir fortement varier selon la qualité des outils et méthodes utilisés).
Enfin, par expérience, la majorité des vulnérabilités identifiées sont relatives à des erreurs dans la logique métier implémentée par les développeurs : manque de vérifications, biais dans les systèmes d’authentification, chargement de fichiers malveillants non filtrés, etc. Ces failles sont à la fois plus complexes à identifier (car elles nécessitent des analyses manuelles poussées) et également plus difficiles à corriger (car la correction porte souvent atteinte à la facilité d’utilisation et est donc moins acceptable sur le terrain). Or, chacune de ces vulnérabilités métier peut être potentiellement dévastatrice pour le logiciel ciblé, et donc pour les services qu’il porte.
[1] Commercial off-the-shelf, logiciel ou produit commercial prêt à l’emploi, développé pour un large public
Comment l’ANSSI mesure-t-elle le succès d’un audit financé : nombre de vulnérabilités trouvées, corrections effectivement déployées, adoption du produit dans des environnements sensibles… ?
ANSSI : La question est plus subtile qu’il n’y paraît en ce sens qu’avant de pouvoir mesurer le succès d’un audit, il est déjà compliqué d’en interpréter les résultats : l’absence de findings signifie-t-elle que le produit est robuste (ou que les évaluateurs ont « sous-performé », que le développeur n’a été suffisamment collaboratif, que le périmètre d’évaluation était trop restreint) ? Au contraire, la mise en lumière de nombreuses vulnérabilités implique-t-elle de facto que le produit soit « mauvais » (même si toutes les dépendances tierces sont pourtant exemptes de vulnérabilités et que le code est globalement bien écrit et bien documenté) ?
Comme cela a été évoqué plus haut, l’ANSSI sélectionne avec soin les produits audités : le simple fait d’avoir « regardé le produit » avec une méthodologie normalisée et d’en formaliser les résultats est en soi une information précieuse. L’ANSSI, conformément à ses principes de transparence, publie, à l’issue des évaluations de sécurité et dans le respect de règles de divulgation responsable, toutes les informations qu’elle juge d’intérêt pour l’écosystème numérique : CVE[1], rapports techniques, blog-posts du développeur ou du CESTI[2]. Tous ces éléments sont susceptibles d’aider les professionnels de cybersécurité impliqués dans la mise en œuvre des solutions auditées à nourrir leurs analyses de risques et leur dossier d’homologation.
Plus récemment, l’ANSSI a développé la notion d’audit ad hoc. Historiquement, l’ANSSI appuyait ses évaluations de logiciels open source sur des certifications CSPN[3] (analyse de sécurité en temps contraint, de l’ordre de 25j.h). Avec les audits ad hoc, elle s’appuie sur la méthodologie rigoureuse des CSPN mais rompt avec l’« effet tunnel » propre à ce type d’évaluation. En effet, lors d’une CSPN, le CESTI conduit son travail d’analyse sans interaction ni avec le commanditaire ni avec le développeur, notamment sans pouvoir partager les éventuels résultats et vulnérabilités avant la fin des travaux. Avec un audit ad hoc, l’un et l’autre peuvent prendre part à l’analyse. Cela change tout. Pour l’ANSSI (qui agit dans ce cas en commanditaire d’audit) cela permet d’orienter les travaux pour en maximiser l’efficacité ; pour le développeur, être impliqué, c’est être dans de meilleures dispositions pour corriger et améliorer son produit.
L’expérience montre que ces évaluations sont aussi utiles à l’ANSSI et, indirectement, à ses bénéficiaires, car elles contribuent à élaborer, ajuster et faire évoluer sa doctrine technique. Celle-ci est d’ailleurs largement accessible au public à travers ses différentes publications (Essentiels, Fondamentaux, guides techniques, etc.)[4].
[1] Common vulnerabilities and exposures
[2] Ces éléments sont disponibles à cette adresse : https://anssi-fr.github.io/evaluations.html
[3] Présentation de la Certification de Sécurité de Premier Niveau (CSPN) — ANSSI
Avez-vous observé, chez les éditeurs concernés, des changements dans la posture cyber et la prise en compte de cette sécurité au cours du développement ?
ALMOND : Certains éditeurs ont, effectivement, profondément changé leur posture de développement pour y intégrer une réelle dimension cyber. Nous avons pu l’observer chez certains de nos clients qui ont, au fil des années, intégré la sécurité informatique et la logique des audits au sein de leur culture d’entreprise, ce qui leur a permis de renforcer profondément la sécurité de leurs produits[1].
Accompagner l’ANSSI sur des audits nous a également permis de travailler et échanger avec des éditeurs de logiciels open source. Notamment, l’éditeur de HAProxy Technologies[2] s’est pleinement impliqué dans l’audit qui a été réalisé sur son produit en suivant les travaux, d’une part, et en intégrant au fil de l’eau des patchs lorsque nécessaire. En acceptant la publication du rapport d’analyse à l’issue de l’audit, HAProxy Technologies témoigne d’une volonté d’en assumer les résultats et de les intégrer à sa roadmap produit.
Nous observons également des éditeurs qui intègrent les méthodes de nos consultants au sein de leurs chaînes de développement, par exemple pour contrôler régulièrement que leurs bibliothèques externes sont toujours maintenues et exemptes de CVE, ou encore pour lancer des outils d’analyse de code à chaque nouveau merge dans leur chaîne de CI/CD[3].
Ces bonnes pratiques doivent être soutenues, d’autant plus à l’ère du vibe coding, qui par nature conduit à l’inclusion de code non maîtrisé, et donc potentiellement de vulnérabilités, au sein des logiciels. Une validation régulière et continue du code qui a été généré ou « conseillé » par des systèmes d’IA s’avère donc d’autant plus nécessaire.
ANSSI : Nous avons évoqué les audits ad hoc financés par l’ANSSI pour certains projets open source. Lorsque la gouvernance de ces projets considère cette démarche comme une première étape et choisit de s’engager par la suite dans une certification CSPN, cela reflète une réelle maturité en matière de cybersécurité, ainsi qu’une prise de conscience des risques et de la valeur ajoutée des Visas de sécurité de l’ANSSI.
Voyez-vous une amélioration notable de la robustesse des produits après plusieurs audits ?
De manière connexe, y a-t-il un intérêt à réaliser des audits réguliers sur ses produits ?
ALMOND : Les logiciels s’améliorent fortement après plusieurs audits, d’une part car des vulnérabilités y sont découvertes – puis sont corrigées – mais également car ces audits ont tendance à améliorer la prise en compte de la sécurité par les développeurs. On a donc tendance à observer moins de vulnérabilités au fil du temps, car les équipes de développement vont s’améliorer continuellement pour ne pas les reproduire.
Il est cependant nécessaire de ne pas se reposer sur ses acquis et de réaliser, régulièrement, de nouvelles campagnes d’audits. En premier lieu, car personne n’est infaillible et que même s’ils sont sensibilisés, les développeurs peuvent introduire des vulnérabilités dans les logiciels. De plus, car l’état de l’art évolue, et avec lui les techniques des attaquants. Soumettre son logiciel à des audits permet de se confronter à ce nouveau niveau d’attaquant qui augmente, et donc de s’en protéger. Enfin, cela permet également de tester de nouvelles méthodes d’analyse, qui peuvent apporter leur lot de bénéfices et d’améliorations (nouvelles techniques d’analyse de code, pentest complété par l’IA, etc.).
ANSSI : Nous avons évoqué le vibe coding. Loin de remettre en cause les audits ponctuels, les risques induits par cette tendance (augmentation des volumes de code, inclusion de packages potentiellement malveillants, reproduction par l’IA de code vulnérable…), cumulés à l’accélération déjà observée des cycles de développement logiciel, vont obliger les éditeurs à industrialiser leur chaine CI/CD (SAST[1], DAST[2], SCA[3] automatisés) pour aller vers un « audit en continu ». Lors de l’audit de HAProxy, cette idée a d’ailleurs été confirmée par le développeur principal de ce produit, Willy Tarreau. Selon lui, à mesure que l’IA progresse dans la détection de vulnérabilités, elle produit des résultats plus pertinents, en réduisant notamment le volume de faux positifs. Toutefois, les vulnérabilités identifiées par ces outils restent souvent insuffisamment contextualisées : elles ne tiennent pas compte des conditions réelles d’exploitation ni de l’impact concret dans un environnement d’utilisation donné.
C’est précisément là que l’intervention d’experts en sécurité conserve toute sa valeur. Un audit humain permet de prendre du recul, d’évaluer la faisabilité réelle d’une vulnérabilité et d’analyser les scénarios d’usage. Plutôt que de signaler des failles théoriques (car inatteignables), l’auditeur va s’interroger sur les comportements utilisateurs, les erreurs possibles, et les conséquences effectives sur le périmètre applicatif.
Dans ce contexte, il est probable que la détection automatisée de motifs vulnérables s’intègre de plus en plus aux chaînes CI/CD, devenant un standard industriel. En parallèle, les audits de sécurité « manuels » resteront indispensables pour valider la cohérence globale du système et s’assurer que ces outils automatisés, bien que performants, ne laissent pas de failles exploitables dans des situations réelles.
Cette évolution est positive : elle permet d’éviter de mobiliser inutilement des ressources humaines sur des vulnérabilités triviales et de recentrer les audits sur des problématiques plus complexes et structurantes, telles que la sécurisation des usages ou la prévention de configurations dangereuses par les utilisateurs.
Est-ce que ne pas faire d’audit est encore tenable pour un éditeur qui prétend viser des clients sensibles (administrations, opérateurs essentiels, secteurs régulés) ?
ANSSI : Sur le plan technique, un éditeur qui n’a jamais audité son produit ignore une partie de sa surface d’attaque réelle. Il laisse potentiellement persister des vulnérabilités critiques et ne dispose pas de validation indépendante de ses mécanismes de sécurité.
Ce constat va se renforcer sur le plan réglementaire. Comme évoqué précédemment, certaines attaques présentent désormais un caractère systémique, notamment lorsqu’elles exploitent la chaîne d’approvisionnement logicielle, étroitement imbriquée avec des composants open source. Face à cet enjeu majeur, le législateur européen a engagé une réponse structurante. Ainsi, le Cyber Resilience Act (CRA) impose aux éditeurs de logiciels une obligation de moyens, les contraignant à démontrer la mise en œuvre de pratiques de sécurité conformes à l’état de l’art. Dans ce cadre, l’audit de sécurité s’impose comme une pratique essentielle (voire obligatoire, pour certaines classes de produits) pour attester de la capacité à identifier et prévenir les vulnérabilités. Plus indirectement, la directive européenne NIS 2, en imposant aux entités concernées l’évaluation des risques liés à leurs fournisseurs et à leurs produits va inciter les responsables des systèmes d’information à obtenir des preuves de sécurité, au premier rang desquels : audits de sécurité et tests d’intrusion.
Dès lors, et a fortiori dans des environnements sensibles, le recours à l’audit ne relève plus d’un choix : il devient une exigence réglementaire et une attente explicite des clients.
Conclusion
Comme Alexandre et Frédéric l’ont expliqué, réaliser des audits ou évaluations de sécurité sur des logiciels apporte une réelle plus-value à plusieurs niveaux : amélioration intrinsèque de la sécurité, renforcement de la posture cyber des éditeurs. Ces audits ne sont définitivement pas qu’un centre de coût. L’ANSSI a démontré sa volonté d’accompagner les éditeurs dans cette démarche en structurant la certification des produits de cybersécurité en France et également en commanditant certains audits. Cette collaboration avec des laboratoires, comme celui d’Almond, permet de mettre en œuvre cette stratégie et d’accompagner les éditeurs dans cette démarche.
