À une époque où les organisations sont confrontées à des difficultés liées à la complexité des environnements numériques, l'gestion des surfaces d'attaque (ASM) devient un élément clé des stratégies modernes de cybersécurité. À la base, l'ASM consiste en une activité continue de découverte, d'enregistrement, de classification et de surveillance de tous les actifs numériques susceptibles d'être utilisés à des fins malveillantes. Il peut s'agir d'applications web accessibles au public, de réseaux internes, de ressources cloud publiques et, surtout, de composants open source intégrés ou compilés dans la pile technologique de l'organisation.
Lorsque les entreprises s'appuient sur des bibliothèques, des frameworks et des outils open source pour accélérer le développement et réduire les dépenses, elles doivent également faire face aux risques de sécurité associés à ces dépendances. La gestion des surfaces d'attaque open source est plus que jamais une préoccupation majeure depuis l'ancien incident SolarWinds et le plus récent incident Log4j, où des vulnérabilités ont été découvertes dans un composant open source, ce qui a entraîné une attaque généralisée contre un certain nombre d'entreprises.
Qu'est-ce que la gestion des surfaces d'attaque open source ?
La gestion des surfaces d'attaque open source désigne la pratique consistant à identifier, surveiller et atténuer les risques liés aux composants open source au sein de l'infrastructure technologique d'une organisation.
Alors que l'ASM traditionnelle se concentre sur le périmètre et les actifs visibles de l'extérieur, l'ASM open source explore plus en profondeur la chaîne logistique logicielle et examine les bibliothèques, les frameworks et les packages qui constituent les éléments de base des applications modernes. Cette prise de conscience reconnaît que les vulnérabilités ne sont pas exclusives au code propre à une organisation, mais qu'elles sont inhérentes à l'écosystème étendu des dépendances open source tierces dont dépendent les applications.
L'ASM traditionnelle est généralement centrée sur la découverte et la surveillance des points d'extrémité du réseau, des domaines, des adresses IP et d'autres actifs exposés à l'extérieur. L'ASM open source élargit cette vision vers l'intérieur, en examinant la composition des applications elles-mêmes. Il implique la création et la mise à jour d'une nomenclature logicielle complète (SBOM), la collecte d'informations sur les versions et les vulnérabilités connues dans les dépendances, ainsi que la compréhension du réseau complexe de relations entre les composants logiciels.
Pourquoi l'ASM open source est-il important ?
Les logiciels open source constituent l'épine dorsale des piles technologiques modernes des entreprises. Selon certaines estimations, plus de 90 % des applications commerciales contiennent des composants open source, et une application moyenne contient des centaines de bibliothèques open source. Cette adoption massive a généré des gains d'efficacité et stimulé l'innovation, mais elle a également considérablement élargi la surface d'attaque que les organisations doivent protéger.
La surface d'attaque en expansion
Les dépendances open source ont de graves implications en termes de sécurité. La vulnérabilité suivie sous le nom de Log4j (CVE-2021-44228) a servi de signal d'alarme pour de nombreuses organisations, touchant des millions d'appareils et entraînant des efforts de correction massifs à l'échelle mondiale. De même, des incidents tels que la compromission du paquet npm event-stream montrent comment des acteurs malveillants peuvent utiliser la popularité des bibliothèques open source comme vecteur d'attaques de la chaîne d'approvisionnement contre les utilisateurs en aval.
Le défi de la visibilité
La plupart des organisations n'ont pas une visibilité étendue sur l'impact de l'open source. Souvent, les équipes de développement introduisent de nouvelles dépendances sans examen de sécurité, ce qui conduit à la création de " dépendances fantômes " à l'insu de l'équipe de sécurité. Cette mauvaise visibilité fait que les vulnérabilités ne sont pas corrigées longtemps après la mise à disposition des correctifs, exposant les organisations à des attaques facilement évitables.
Pressions réglementaires et de conformité
Les cadres réglementaires exigent des organisations qu'elles tiennent de plus en plus à jour des inventaires précis des composants logiciels et qu'elles corrigent rapidement les vulnérabilités connues. Du RGPD aux réglementations sectorielles telles que la norme PCI DSS, la conformité nécessite des pratiques de gestion open source saines qui s'inscrivent parfaitement dans les principes de l'ASM open source.
Composantes clés de la gestion des surfaces d'attaque open source
Une approche structurée est nécessaire pour une gestion ASM open source efficace qui utilise la technologie et les processus et les intègre dans l'organisation. Les composantes clés permettent aux organisations de travailler intelligemment pour découvrir, hiérarchiser et corriger les risques liés aux dépendances open source.
Inventaire des logiciels
La gestion des surfaces d'attaque open source commence par une liste potentiellement complète et précise de tous les actifs logiciels. Cela implique de conserver des nomenclatures logicielles (SBOM) détaillées, qui répertorient chaque composant open source utilisé, sa version, ses informations de licence et sa provenance. Des formats standardisés, tels que CycloneDX et SPDX, permettent aux développeurs de décrire ces dépendances de manière indépendante, ce qui les rend plus visibles, plus faciles à analyser et plus faciles à partager avec d'autres parties.
Surveillance continue des vulnérabilités
Analyse régulière des bases de code et comparaison avec des bases de données de vulnérabilités telles que la National Vulnerability Database (NVD), les avis de sécurité GitHub et les flux de vulnérabilités spécifiques à chaque langage. La surveillance des CVE n'est pas suffisante, elle doit mettre en corrélation les vulnérabilités avec la manière dont une organisation utilise réellement ses systèmes afin de déterminer ce qui est réellement exploitable.
Cadre de hiérarchisation basé sur les risques
Conscients que toutes les vulnérabilités ne sont pas égales, il est nécessaire de les hiérarchiser afin d'allouer efficacement les ressources. La hiérarchisation doit être basée sur de nombreux aspects, à savoir le degré de vulnérabilité (scores CVSS), l'exploitabilité dans l'environnement, l'accessibilité du composant vulnérable, l'impact global sur l'activité ou les mesures d'atténuation disponibles.
Intégration transparente aux pipelines de développement
L'intégration d'Open Source ASM au pipeline CI/CD transforme ASM d'une activité manuelle périodique en un processus automatisé et continu. La vérification des dépendances vulnérables à l'aide de hooks pré-commit, les analyses pendant la phase de construction automatisée et l'analyse des images de conteneurs empêchent les mauvaises dépendances d'atteindre la production.
Stratégies de remédiation et d'atténuation
Des workflows de remédiation clairement définis font également partie d'un écosystème permettant de traiter les vulnérabilités détectées. Les stratégies de remédiation consistent à passer à des versions corrigées, à appliquer des solutions de correctifs virtuels (WAF ou RASP), à utiliser des composants alternatifs ou à appliquer des contrôles compensatoires lorsqu'aucun correctif n'est disponible.
Menaces courantes traitées par l'ASM open source
La gestion des surfaces d'attaque open source évalue les menaces à travers un large éventail de vulnérabilités de sécurité qui ciblent ou exploitent des composants open source. En comprenant ces menaces, les organisations seront mieux à même de mettre en œuvre des contre-mesures.
Exploitation des vulnérabilités connues
Les attaquants ciblent souvent les vulnérabilités connues des composants open source populaires, car elles constituent la voie d'accès la plus facile à des systèmes par ailleurs bien protégés. Ce risque permanent a été mis en évidence lors de la violation de données d'Equifax en 2017, au cours de laquelle les attaquants ont exploité une vulnérabilité connue mais non corrigée dans Apache Struts, qui avait été corrigée depuis des mois mais n'avait pas été déployée sur les systèmes d'Equifax. Le même schéma se répète dans tous les secteurs, les vulnérabilités open source courantes telles que Log4j, Spring4Shell et OpenSSL devenant des cibles de choix pour les pirates en raison de leur ampleur de mise en œuvre.
Compromission de la chaîne d'approvisionnement
La chaîne d'approvisionnement logicielle est une cible de choix pour les pirates sophistiqués, car elle leur permet de toucher plusieurs victimes avec un seul vecteur d'attaque. Les incidents SolarWinds ont démontré les dégâts que peuvent causer de telles attaques, tandis que des incidents de moindre ampleur, tels que la manipulation du paquet npm event-stream, ont prouvé que les pirates commencent à cibler les paquets open source utilisés par leurs victimes. D'autres types d'attaques de ce type reposent sur l'injection de code dans des paquets ou des référentiels légitimes, la compromission de serveurs de compilation ou le détournement de comptes de développeurs.
Attaques par confusion de dépendances
La confusion de dépendances est un type d'attaque de la chaîne d'approvisionnement qui exploite le comportement des gestionnaires de paquets lorsqu'ils rencontrent des conflits de noms entre les référentiels publics et privés. Les attaquants peuvent enregistrer des paquets publics dont les noms sont identiques à ceux des paquets internes d'une organisation, et les systèmes de compilation extraient automatiquement la version publique, qui est la version malveillante. Ce vecteur d'attaque a commencé à attirer l'attention en 2021, lorsque le chercheur Alex Birsan a démontré son efficacité contre plusieurs grandes organisations.
Risques liés aux paquets abandonnés
À mesure que les projets open source se développent, certains paquets ne sont plus maintenus ou sont dépréciés par leurs développeurs d'origine. Ces dépendances " mortes " constituent un risque majeur pour la sécurité, car elles ne bénéficient plus de mises à jour de sécurité ni de corrections de bogues. Ainsi, toute nouvelle faille découverte expose les organisations à des attaques. Dans certains cas, des acteurs malveillants ont pris le contrôle de paquets abandonnés pour y injecter des logiciels malveillants.
Violations de la conformité des licences
Les problèmes de conformité des licences ne constituent pas à proprement parler des menaces pour la sécurité, mais ils peuvent représenter des menaces juridiques et financières majeures pour les utilisateurs de logiciels open source. Certaines licences sont assorties d'exigences qui peuvent entrer en contradiction avec le modèle économique ou la stratégie de propriété intellectuelle d'une organisation. Malheureusement, l'inclusion involontaire de code packagé sous une licence incompatible peut exposer une entreprise à des poursuites pour violation du droit d'auteur, à la divulgation forcée du code dans sa chaîne logicielle de production et à des efforts de remédiation coûteux.
Défis de l'ASM open source
L'ASM open source pose de nombreux défis aux organisations qui le mettent en œuvre. Avec l'accélération continue de l'utilisation des composants open source, les équipes de sécurité doivent trouver un moyen de relever ces défis afin de protéger leur organisation contre les vulnérabilités pouvant entraîner des violations de données et à une interruption des services pouvant entraîner des pertes financières ou des amendes réglementaires.
Complexité des dépendances
Les applications modernes ont des structures de dépendances profondément imbriquées, où une seule application peut dépendre de centaines ou de milliers de dépendances directes et transitives. Cela crée un " pool de dépendances " dans lequel les équipes de sécurité ne peuvent plus déterminer la composition de leurs logiciels. Ces couches créent un réseau complexe de relations, et il est très difficile de comprendre avec précision les implications des vulnérabilités dans l'ensemble d'une organisation ; une vulnérabilité critique dans une dépendance hypertechnique de troisième ou quatrième niveau pourrait se répercuter en cascade sur de nombreux systèmes de l'organisation.
Visibilité globale limitée
La plupart des organisations ne disposent pas d'une nomenclature logicielle (SBOM) complète, ce qui empêche d'identifier tous les composants open source utilisés dans leur environnement. Le manque de visibilité ne fait que s'accentuer en raison des pratiques de développement décentralisées, du shadow IT et la tendance DevOps à accélérer le rythme de déploiement des logiciels. Les composants peuvent être ajoutés à partir de diverses sources, gestionnaires de paquets, images de conteneurs, copiés à partir d'une page Web ou de logiciels fournis par des fournisseurs, ce qui entraîne des angles morts dans la surveillance de la sécurité.
Manque de ressources et contraintes techniques
La mise en œuvre d'une ASM open source efficace nécessite des outils spécialisés et du personnel qualifié, qui peuvent tous deux faire défaut. De nombreuses organisations ne disposent pas de ressources dédiées à la gestion de la sécurité open source et répartissent plutôt cette responsabilité entre des équipes de développement et de sécurité déjà surchargées. Les défis techniques liés à l'analyse des applications conteneurisées, des fonctions sans serveur et du code compilé dynamiquement compliquent encore davantage les efforts de détection.
Intégration aux workflows de développement
L'intégration a posteriori de pratiques de sécurité dans des workflows de développement établis crée des frictions qui peuvent entraver l'adoption de l'ASM open source. Les développeurs qui se concentrent sur la livraison de fonctionnalités peuvent résister à la mise en place de barrières de sécurité supplémentaires qui ralentissent leurs cycles de publication ou nécessitent une refonte des implémentations existantes. Les outils de sécurité traditionnels génèrent souvent un volume élevé de résultats sans contexte, ce qui entraîne une fatigue des alertes et une diminution de l'efficacité.
Principaux outils open source pour la gestion des surfaces d'attaque
La gestion des surfaces d'attaque open source s'appuie sur une multitude d'outils qui aident les organisations à découvrir, surveiller et traiter les vulnérabilités de leurs composants open source.
CrowdStrike Falcon
CrowdStrike Falcon va au-delà de ses capacités de protection des terminaux pour offrir des fonctionnalités robustes de gestion des risques de sécurité open source. Le module de sécurité des applications de la plateforme assure une analyse continue des environnements de développement afin d'identifier les composants open source vulnérables dès le début du cycle de développement.
RiskIQ
Désormais intégré à Microsoft, RiskIQ offre de puissantes fonctionnalités de détection des surfaces d'attaque qui aident les organisations à identifier leurs actifs externes, y compris ceux qui dépendent de composants open source vulnérables. Le graphique Internet Intelligence Graph de la plateforme cartographie l'infrastructure exposée à Internet d'une organisation, détectant les systèmes obsolètes, les services mal configurés et les applications exécutant des composants vulnérables connus. RiskIQ excelle dans la découverte des technologies informatiques parallèles et des actifs oubliés qui échappent souvent aux inventaires internes mais restent accessibles aux attaquants.
Palo Alto Xpanse
Xpanse offre une gestion complète de la surface d'attaque externe avec des capacités spécialisées pour la détection des vulnérabilités open source. La plateforme surveille en permanence les actifs exposés à Internet afin d'identifier les systèmes exécutant des logiciels open source vulnérables, qu'il s'agisse de serveurs web, d'applications, de services réseau ou d'appareils IoT. La force de Xpanse réside dans sa capacité à découvrir des actifs inconnus ou oubliés chez les fournisseurs de cloud, les filiales et les entreprises récemment acquises, autant d'endroits où se cachent souvent des composants open source vulnérables.
Nuclei Cloud
Nuclei Cloud s'appuie sur le célèbre scanner de vulnérabilités open source Nuclei pour assurer une surveillance continue de la surface d'attaque externe d'une organisation à la recherche de composants open source vulnérables. La plateforme utilise un scan basé sur des modèles pour détecter des modèles de vulnérabilité spécifiques dans les applications web, les API et les composants d'infrastructure. Ce qui rend Nuclei particulièrement précieux pour l'ASM open source, c'est sa vaste bibliothèque de modèles qui comprend des vérifications des vulnérabilités open source courantes et son approche communautaire qui garantit une couverture rapide des problèmes nouvellement découverts.
Meilleures pratiques pour l'ASM open source
Les meilleures pratiques énumérées ci-dessous aideront les organisations à créer un programme ASM open source solide qui équilibre la réduction des risques et l'innovation.
Catégoriser en fonction du risque
Allez au-delà des scores CVSS bruts en créant une approche standard pour la hiérarchisation des vulnérabilités. Tenez compte d'éléments tels que : la fonctionnalité vulnérable est-elle réellement utilisée ? Le composant est-il directement accessible aux utilisateurs externes ? Les données traitées par le composant sont-elles sensibles ? Des contrôles compensatoires sont-ils en place ? Créez une documentation pour ce cadre et appliquez-la de manière similaire dans toutes les équipes. La bonne nouvelle, c'est que des outils automatisés peuvent enrichir automatiquement les données sur les vulnérabilités avec des informations sur les risques spécifiques au contexte.
Intégrez la sécurité dans les processus de développement
Intégrez l'ASM open source dans les outils et pratiques de développement actuels afin que la sécurité devienne une extension naturelle du processus de développement. Vous pouvez le faire de différentes manières, par exemple en créant des plugins IDE qui informent les développeurs des composants vulnérables lorsqu'ils écrivent le code. Utilisez des systèmes de compilation pour vérifier automatiquement les dépendances avant de packager les applications. Formulez des conseils de correction concis qui permettent aux développeurs de les corriger rapidement sans avoir besoin d'être eux-mêmes des spécialistes de la sécurité.
Politiques et normes de gouvernance
Établissez des politiques formelles d'utilisation de l'open source qui associent les tolérances au risque à des licences acceptables et à des exigences minimales en matière de maintenance pour les dépendances. Appliquez ces politiques pour automatiser les vérifications dans le pipeline CI/CD grâce à des contrôles techniques. Formez un comité de gouvernance qui comprend des représentants des services de sécurité, juridique et de développement et qui gère les exceptions et l'évolution des politiques. Ces cadres de gouvernance permettent une approche commune de la gestion des risques dans toute l'organisation, tout en offrant une certaine flexibilité pour les applications critiques grâce à un processus d'exception bien documenté.
Investissez dans l'automatisation de la correction des vulnérabilités
Réduisez au minimum l'intervention humaine dans le processus de correction afin de rationaliser la réponse aux faiblesses découvertes. Lorsque cela est autorisé, les outils peuvent créer des demandes d'extraction qui mettent à jour de manière réactive les dépendances vulnérables avec des alternatives sûres. Disposez de modèles pour les schémas de correction courants afin de permettre aux développeurs de trouver la solution la plus rapide pour différents types de vulnérabilités. Mettez en œuvre des tests automatisés pour vous assurer que les nouvelles modifications ne compromettent pas les fonctionnalités existantes.
Suivre la chaîne d'approvisionnement des dépendances
Adoptez une vision plus large pour évaluer la posture de sécurité de votre chaîne d'approvisionnement open source. Évaluez vos dépendances par paquet en fonction de l'activité des responsables de maintenance, de la qualité et de la sécurité du code, ainsi que du soutien de la communauté. Restez vigilant face à toute activité inhabituelle dans les référentiels de dépendances, telle que l'ajout de nouveaux responsables, des modèles de validation inhabituels ou des modifications inattendues des autorisations qui pourraient révéler une compromission. Téléchargez les paquets en toute sécurité, en vérifiant leur intégrité à l'aide de sommes de contrôle ou de signatures.
Conclusion
La gestion des surfaces d'attaque open source est une évolution importante dans l'adoption des pratiques de sécurité par les organisations modernes. Les entreprises s'appuyant de plus en plus sur des composants open source pour accélérer l'innovation et réduire les délais de développement, elles doivent également faire face aux défis de sécurité uniques que ces dépendances soulèvent. Une solution ASM open source adaptée, dotée de capacités de visibilité, de surveillance et de correction, permet d'équilibrer la vitesse de développement et la nécessité de gérer ces risques.
La saga des menaces liées à l'ASM open source, de l'exploitation des vulnérabilités connues aux attaques de la chaîne d'approvisionnement, illustre pourquoi cette discipline est devenue indispensable pour garantir la maturité des programmes de sécurité. Cependant, les organisations qui adoptent des pratiques ASM open source solides réduisent considérablement leur surface d'attaque et le temps d'exposition aux nouvelles vulnérabilités, et créent davantage d'opportunités pour résister aux nouvelles menaces.
"FAQ sur la gestion des surfaces d'attaque open source (ASM)
La gestion des surfaces d'attaque open source (ASM) est une discipline de sécurité spécialisée qui se concentre sur l'identification, la surveillance et l'atténuation des risques associés aux composants open source au sein de l'écosystème logiciel d'une organisation. Elle étend l'ASM traditionnelle en approfondissant la composition des applications afin d'examiner les bibliothèques, les frameworks et les paquets qui constituent les éléments de base des applications modernes, créant ainsi une visibilité sur les dépendances susceptibles d'introduire des vulnérabilités ou des problèmes de conformité.
L'utilisation d'outils open source pour la gestion des surfaces d'attaque offre plusieurs avantages : rentabilité par rapport aux solutions commerciales, flexibilité pour personnaliser les outils en fonction des besoins spécifiques de l'organisation, accès à des innovations communautaires qui répondent souvent rapidement aux menaces émergentes, transparence permettant aux équipes de sécurité de vérifier le fonctionnement des outils et compatibilité avec les pratiques DevOps grâce à des intégrations basées sur des API.
Les solutions ASM open source et commerciales présentent chacune des avantages distincts. Les outils open source offrent généralement une plus grande personnalisation, le soutien de la communauté et des économies de coûts, mais peuvent nécessiter une expertise technique plus importante pour leur mise en œuvre et leur maintenance. Les solutions commerciales telles que SentinelOne fournissent des plateformes intégrées avec une assistance professionnelle, une automatisation plus sophistiquée et une évolutivité de niveau entreprise, et incluent souvent des fonctionnalités supplémentaires telles que la protection en temps réel.
Les outils populaires pour la gestion des surfaces d'attaque comprennent CrowdStrike Falcon, Cycode ASPM, RiskIQ, Palo Alto Xpanse et Nuclei Cloud. Chacun d'entre eux offre des fonctionnalités spécialisées pour détecter les composants open source vulnérables, de la protection à l'exécution à la découverte des surfaces d'attaque externes et à la surveillance continue.
