Posons le décor.  Le marché mondial DevSecOps[1] a été évaluée à 2,79 milliards de dollars en 2020 et devrait croitre de 24% par an de 2021 à 2028. C’est une inéluctable réalité : les applications doivent être hautement sécurisées, et la demande d’automatisation dans ce domaine a explosé.

De plus, la pression sur les équipes informatiques est croissante. Elles subissent les changements structurels des systèmes d’information qui découlent des régulations et des enjeux d’innovation.

Aussi, pour pouvoir tenir les engagements en termes de résilience, disponibilité et sécurité des applications, ces équipes doivent hiérarchiser leurs activités et optimiser leurs ressources limitées.

Il ne faut pas être expert pour comprendre qu’il ne sera jamais possible de corriger toutes les vulnérabilités des applications. Dès lors, il convient surtout de mettre l’accent sur les failles les plus critiques pour l’entreprise. Pour y parvenir, l’approche « secure by design », consistant à intégrer la sécurité dès la conception des systèmes logiciels, est tout indiquée.

Nous le verrons, il existe bien des outils dédiés aux tests de sécurité comme SAST, DAST, et SCA. Cependant, aucun de ces derniers ne peut répondre à tous les besoins de sécurité. Dans ce contexte, la gestion des vulnérabilités fondée sur le risque (Risk Based Vulnerability Management) peut aider les équipes IT à cibler efficacement leurs efforts pour améliorer la sécurité des applications.

Security by Design : 5 principes pour anticiper les enjeux de sécurisation

La sécurité des logiciels est un enjeu majeur pour protéger les données des utilisateurs et minimiser les risques cyber. C’est pourquoi l’industrie du développement logiciel préconise d’intégrer la sécurité dès le début des projets et tout au long de leur cycle de vie. Cette approche de la cybersécurité appelé Security by Design (ou « sécurité par la conception « ) est désormais obligatoire depuis l’adoption du Cyber Resilience Act par Bruxelles en 2022[2].

En pratique, la Security by Design consiste à adopter des pratiques de sécurité rigoureuses à chaque étape du processus de développement et de déploiement des logiciels. Voici ces 5 principes clés pour garantir la sécurité des logiciels dès leur conception :

Modélisation des menaces

L’une de ces pratiques clés est la « modélisation des menaces » (ou Threat Modeling). Cette action permet d’anticiper les risques et les vulnérabilités latentes dès l’amorce même de la phase de conception.

Minimiser la surface d’attaque

Réduire la surface d’attaque constitue la seconde mesure importante de sécurité pour assurer la sécurité des systèmes informatiques. L’objectif, ici, est de limiter les opportunités pour les attaquants de trouver des failles et d’exploiter des vulnérabilités. On vise ainsi à limiter l’accès aux données et fonctionnalités sensibles[3].

Principe de moindre privilège (PoLP)

La troisième mesure de sécurité est la mise en place du « principe de moindre privilège » (ou Principle of least privilege). Ce dernier limite les droits d’accès des utilisateurs aux seules ressources nécessaires à l’exécution de leurs tâches[4].

Tests de validation dédiés à la sécurité

Afin d’améliorer la résilience face aux attaques potentielles, la quatrième mesure, la mise en place de tests de validation dédiés à la sécurité, permet, entre autres, de s’assurer du bon cloisonnement des fonctionnalités, et de l’assainissement des entrées de l’application.

Code sécurisé

Enfin, pour minimiser le risque d’erreurs pouvant introduire des vulnérabilités, il est recommandé d’écrire et de déployer un code sécurisé. Pour cela, il convient d’adopter de bonnes pratiques de développement. Ces reflexes s’acquièrent par des formations aux vulnérabilités les plus communes, référencées par la communauté OWASP[5].

Pour ce dernier point, les développeurs peuvent également utiliser des outils dédiés tels que les tests de sécurité d’application (AST : Application Security Testing). Ces outils leur permettent d’effectuer des vérifications approfondies du code. Mais ces AST sont loin d’être parfaits. L’expérience montre que ces scans remontent beaucoup (trop ?) de vulnérabilités. Dès lors, même en ne traitant que les plus critiques, il apparait impossible de toutes les corriger.

Alors que faire si on a trop de vulnérabilités à traiter avec un budget ou un délai limité ? La réponse est le « Risk-based vulnerability management », une méthode qui permet d’évaluer et de réduire les risques liés aux vulnérabilités en tenant compte du contexte et de l’impact potentiel sur l’activité.

Evaluer les vulnérabilités pour mieux les prioriser

Vous avez accepté le postulat selon lequel vous vous avez trop de vulnérabilités – réelles ou pas – et pas assez de temps/budget pour tout corriger. Dès lors, il est nécessaire de les prioriser, mais selon quels critères ? Plusieurs métriques sont à votre disposition :

Le Common Vulnerability Scoring System (CVSS)

Le “Common Vulnerability Scoring System” est un système d’évaluation standardisé de la criticité des vulnérabilités, selon des critères objectifs et mesurables. Le score final est compris entre 0 et 10 [6].

Au-delà de 9, la vulnérabilité est « critique » et il est communément admis qu’une vulnérabilité au-delà de 7 (« majeure / high ») devrait être corrigée dès que possible, voire ne pas aller en production[7].

Notons par ailleurs, qu’une version 4.0 du CVSS est en cours d’adoption depuis juin 2023 [8].

Le score interne des outils

Les outils de détection des vulnérabilités identifient généralement des vulnérabilités bien référencées par leur identifiant CVE (Common Vulnerabilities and Exposures)[9]. Ainsi, la sévérité affichée est communément acceptée et fondée sur le CVSS que nous avons abordé précédemment.

Mais il arrive que certains outils identifient des vulnérabilités non référencées. Ainsi, les équipes de recherche et développement d’un outil SCA peuvent identifier une vulnérabilité « Zero-day » ; c’est-à-dire qui vient d’être découverte, et pour laquelle aucune mitigation n’est encore disponible.

Par exemple, l’outil BlackDuck (Synopsys) attribue des identifiants internes du type « BDSA-YYYY-XXX » ainsi qu’une sévérité interne en attendant une identification standard et reconnue[10].

La vulnérabilité Log4j identifiée par le SCA BlackDuck, avec son identifiant interne (BDSA) et standard (CVE)

De même, les outils SAST repèrent des vulnérabilités spécifiques au code, propre à l’environnement du projet. Par conséquent, ils ne peuvent hériter d’un identifiant ni même d’un score standard. Les outils utilisent donc leurs propres critères internes.

Par exemple, l’outil Fortify (Micro Focus) propose une notation sur 100, fondée sur la facilité de reproduction, les dommages possibles en cas d’exploitation, la facilité de localisation/découverte, etc.

Ces critères sont empiriques et peuvent parfois manquer de contexte. Il convient de les revoir avec les équipes de développement qui possèdent la connaissance de l’architecture logicielle.

Ces évaluations de vulnérabilités sont reconnues et éprouvées. Cependant, elles ne résoudront probablement pas vos enjeux de priorisation. En effet, trier les vulnérabilités ne diminuera pas leur volume. Il convient alors d’envisager une approche plus pragmatique : le « Risk Based Vulnerability Management ».

Risk Based Management : quel risque concret représente cette vulnérabilité ?

Outre la sévérité affichée d’une vulnérabilité, on peut s’interroger sur son exploitabilité. Dans les faits, est-elle actuellement et activement exploitée par des attaquants ou bien tombée dans l’oubli ?

La note EPSS

Le « EPSS », ou Exploit Prediction Scoring System[11], représente la probabilité qu’une vulnérabilité soit exploitée en ce moment. Cette note s’appuie entre autres sur l’existence d’un exploit dans la nature, et son éventuelle qualification de « zero day ».

Le rapport de PenTest

Un audit de sécurité externe peut être un outil d’aide à la priorisation. Pour cela, il nécessite une analyse affinée et pondérée par un auditeur externe. Ce dernier permettra de contextualiser la criticité de la vulnérabilité en fonction de la facilité d’exploitation, mais aussi de l’expertise requise à sa remédiation.

Mais la complexité et l’unicité des systèmes d’informations font qu’une même vulnérabilité n’aura pas forcément la même exploitabilité ni le même impact d’un environnement à l’autre. Ainsi, le risque intrinsèque à la vulnérabilité doit donc être pondéré par des critères spécifiques :

La criticité de l’actif cible

Les enjeux ne seront pas les mêmes selon que l’application vulnérable est critique pour des utilisateurs internes ou externes. De même, la criticité dépendra du volume de données traitées et du nombre d’utilisateurs. Dès lors, il conviendra de définir des engagements suffisants en termes de disponibilité et de reprise d’activité, mais aussi le délai maximum acceptable d’indisponibilité en cas d’attaque.

L’exposition de l’actif cible

Les dispositions à mettre en œuvre vont varier considérablement selon que l’application est exposée sur internet ou uniquement dans un réseau local d’entreprise. De même, son hébergement sur site nécessitera plus de moyens de redondance et de reprise que si elle est hébergée dans le cloud.

L’impact en cas d’attaque

Si la vulnérabilité est exploitée, les conséquences peuvent varier selon le risque propre au business de l’entreprise. Concrètement, il s’agit d’évaluer l’impact financier d’une exploitation de la vulnérabilité : perte de clientèle, amendes. Mais aussi l’impact non-financier : réputation, vol de données business et propriété intellectuelle.

Pour ne plus être submergé par les vulnérabilités : anticiper, évaluer, prioriser

Vous l’aurez compris, il est nécessaire de suivre des principes fondamentaux si l’on veut éviter de crouler sous les vulnérabilités.

Les bonnes pratiques de Security by Design représentent une base fondamentale qu’il faut structurer en amont et au plus tôt des projets.

De plus, il faut s’équiper d’outils d’analyse de code SAST et SCA. Toutefois, nous avons vu que ces outils, bien que nécessaires, ne sont probablement pas suffisants pour évaluer les vulnérabilités des applications. Car en réalité, le nombre de vulnérabilités reste souvent trop important pour pouvoir tout adresser et encore moins tout corriger.

Ainsi, Il est recommandé d’inclure une évaluation du risque relatif à chaque vulnérabilité afin de mesurer sa diffusion et son exploitabilité. En pratique, chaque risque doit être pondéré au regard des actifs de l’organisation, et des impacts éventuels sur le business.

Finalement, vous pourrez ainsi prioriser les efforts des équipes en fonction du risque réel. Vous permettrez alors aux équipes IT de se concentrer sur la véritable valeur ajoutée des fonctionnalités de leurs applications, tout en livrant des produits plus sécurisés.

Annexe : DAST, SAST et SCA : les outils dédiés aux tests de sécurité d’applications

Pour tester et identifier les vulnérabilités de sécurité dans les applications, on distingue trois grandes familles de solutions dédiées : les outils de tests dynamiques de la sécurité des applications (DAST : Dynamic Application Security Testing), les outils de tests statiques de sécurité des applications (SAST : Static Application Security Testing) et enfin les outils d’analyse de la composition des logiciels (SCA : Software Composition Analysis)

Les DAST pour détecter les vulnérabilités des applications en temps réel

Les DAST sont des outils qui permettent d’analyser une application en cours d’exécution en simulant des attaques via ses URLs, ses APIs et ses points de terminaison dans une architecture de système distribué (les endpoints[1]).

En recherchant les faiblesses dans les protocoles de communication, l’architecture et les configurations d’exécution, les DAST peuvent déterminer si l’application est vulnérable.

Cependant, les vulnérabilités détectées par les DAST peuvent être coûteuses à corriger car elles nécessitent souvent une rétro-ingénierie approfondie.

Bien que les DAST revêtent toutes une importance cruciale dans les tests de sécurité, elles ne peuvent garantir individuellement une protection intégrale des applications. Par conséquent, pour une sécurité maximale, elles peuvent être associé avec un outil de test statique de sécurité des applications (SAST).

SAST : la sécurité du code en temps réel

Les scanners SAST sont des outils qui permettent de détecter en temps réel les pratiques de codage à risque dans le code source d’une application. Ces scanners utilisent une analyse statique pour identifier les vulnérabilités et les faiblesses en matière de sécurité du code source.

Contrairement aux scanners dynamiques qui analysent l’application en cours d’exécution, les SAST inspectent le code source de l’application pour signaler les lignes de code suspectes aux développeurs, leur permettant ainsi de prendre des décisions éclairées avant le déploiement des applications.

Cependant, il est important de noter que les scanners peuvent parfois signaler des vulnérabilités qui ne sont pas pertinentes. C’est ce qu’on appelle un « faux positif ». Cette situation peut être frustrante pour les développeurs. Elle peut en effet entraîner une perte de temps et d’efforts considérable pour évaluer ces alertes non pertinentes. C’est compréhensible, car cela peut être comparé à être accusé à tort d’une erreur que l’on n’a pas commise.

SCA : la solution de détection des vulnérabilités des librairies externes

Les solutions d’analyse de composition de logiciels (SCA) identifient les librairies, les composants tiers et open-source couramment utilisés dans le code d’une application et les comparer à des listes de vulnérabilités connues.

Même si ces librairies ont été testées, elles peuvent toujours présenter des failles exploitables par des attaquants. Pour corriger une vulnérabilité détectée, l’équipe de développement doit généralement mettre à jour la bibliothèque défectueuse.

Si le support d’une bibliothèque a été abandonné, des modifications plus importantes peuvent s’avérer nécessaires. Au pire, ils peuvent désactiver temporairement certaines fonctionnalités.

AST : Les critères d’évaluation à connaître pour sauter le pas

Les logiciels SAST et SCA ne se valent pas tous et chacun possède ses forces et faiblesses. Il est important de faire une évaluation approfondie de chaque option disponible sur le marché : ceux du coût, de la compatibilité des langages, de la facilité d’intégration, du rapport de sécurité et de la facilité d’utilisation, de la personnalisation et la précision.

Coût

Outre le prix de la solution, il est important de prendre en compte le modèle de tarification, la taille de votre base de code, le nombre d’utilisateurs et le niveau d’assistance fourni.

Compatibilité des langages

Ensuite, vous devez prendre en compte la capacité de l’outil à prendre en charge différents langages et frameworks pour détecter les vulnérabilités.

Facilité d’intégration

L’outil doit s’intégrer facilement dans les outils de développement et les pipelines CI/CD pour faciliter l’analyse de sécurité et optimiser les flux de travail.

Rapport de sécurité

Les rapports de sécurité sont également essentiels pour communiquer les résultats des analyses de sécurité. Certains outils fournissent des rapports détaillés avec des conseils de remédiation exploitables, tandis que d’autres ne fournissent que des résumés de haut niveau.

Expérience utilisateur

Bien entendu, la facilité d’utilisation, l’ergonomie de l’interface utilisateur et la rapidité de scan et d’exécution sont des facteurs clés qui influence le choix des utilisateurs.

La personnalisation

Lorsqu’il s’agit de choisir un outil de sécurité pour votre code, la personnalisation des règles de sécurité est un critère de poids à prendre en compte. Les outils qui proposent des options pour modifier ou ajouter des règles personnalisées, ainsi que définir des seuils personnalisés pour les niveaux de criticité, sont essentiels pour garantir que votre application est correctement sécurisée selon vos besoins spécifiques.

La précision

Sa précision pour identifier les vraies vulnérabilités et éviter les faux positifs (une vulnérabilité identifiée qui n’existe pas) ou les faux négatifs (une vulnérabilité non identifiée qui existe). Les faux positifs font perdre du temps aux équipes de développement, tandis que les faux négatifs peuvent rendre votre application vulnérable.

De toutes ces critères de choix, nous pensons que les deux derniers, la personnalisation et la précision, sont vraiment essentiels pour répondre aux vagues de vulnérabilités et pour choisir ce qui convient de corriger ou pas.

[1] « DevSecOps Market Size, Share & Trends Analysis Report By Component (Software, Service), By Deployment (On-Premise, Cloud), By Organization, By Industry Vertical, By Region, And Segment Forecasts, 2021 – 2028 », grandviewresearch.com, 2020.

[2] « Cyber Resilience Act », europa.eu, 15 September 2022 et Alice Vitard, « Bruxelles instaure une obligation de cybersécurité « by design » pour les fabricants d’objets connectés », usine-digitale.fr, 15 September 2022.

[3] « Vue d’ensemble des règles de réduction de la surface d’attaque », microsoft.com, 29/03/2023.

[4] Guide ANSSI, « Recommandations pour la mise en place de cloisonnement système », gouv.fr, Une implémentation du principe de moindre privilège, page 4, 38 pages, 14/12/2017.

[5] OWASP Top 10, la liste des catégories de vulnérabilités les plus critiques, owasp.org, 2021

[6] « Common Vulnerability Scoring System SIG », first.org/cvss.

[7] « Vulnerability Metrics », nist.gov

[8] « CVSS 4.0 preview », first.org/cvss/v4-0/

[9] Common Vulnerabilities and Exposures (« Vulnérabilités et expositions communes ») ou CVE est un dictionnaire des informations publiques relatives aux vulnérabilités de sécurité. Le dictionnaire est maintenu par l’organisme MITRE : https://cve.mitre.org/

[10] « How BDSAs provide more-accurate vulnerable ranges » , synopsys.com

[11] « EPSS », first.org.

[12] Endpoint : Un endpoint est un point de terminaison dans une architecture de système distribué qui est accessible par des clients. Les endpoints sont utilisés pour définir les points de communication entre différents systèmes ou services dans une architecture distribuée. A cet égard, les DAST peuvent simuler des attaques contre ces endpoints pour détecter les vulnérabilités dans l’application.