La philosophie de sécurité « shift-left » promeut l'idée que les organisations doivent intégrer les processus de sécurité plus tôt dans les phases de conception et de développement du cycle de vie logiciel. Cet idéal est largement encouragé dans les programmes DevOps et DevSecOps comme un moyen de détecter les problèmes de qualité ou de sécurité en amont et de les corriger avant qu'ils n'atteignent la production, où leur impact devient plus coûteux. À juste titre, de nombreuses organisations ont adopté pleinement le « shift-left » pour tenter de concrétiser ces avantages et ces économies.
Un axe spécifique du « shift-left » est la « sécurisation du pipeline de build », qui exige que les équipes intègrent des outils de sécurité dans les pipelines CI/CD et les flux de travail des développeurs basés sur Git. La sécurisation des pipelines de build nécessite une gamme d'outils de sécurité, notamment l'analyse des dépendances, l'analyse statique, l'analyse dynamique, les validateurs de schéma, les fuzzers et les scanners de vulnérabilités. Le type d'outils de sécurité nécessaires varie en fonction des artefacts transitant par le pipeline, de ce qui doit être construit et de l'endroit où cela doit être livré.
Les organisations sont souvent confrontées à deux difficultés concernant la sécurité des pipelines de build :
- Une couverture « complète » nécessite de s'approvisionner en plusieurs types d'outils de test de sécurité — Certaines organisations tentent de réduire les coûts en optant partiellement ou totalement pour des outils open source gratuits. Les décisions varient en fonction de la sensibilisation, des budgets de sécurité et de la tolérance au risque.
- Les outils doivent être intégrés et automatisés pour servir le pipeline — Il ne suffit pas de scanner, de trouver des problèmes et de générer un rapport. Le résultat final de l'analyse de sécurité doit être exploitable et s'intégrer aux processus CI/CD.
Même si vous parvenez à satisfaire ces exigences, un certain nombre d'autres problèmes apparaissent pour les organisations qui ont la vision myope selon laquelle sécuriser le pipeline de build est l'objectif ultime d'une stratégie de sécurité des API.
L'analyse de vulnérabilités est banalisée et à faible valeur ajoutée
Les outils d'évaluation et de gestion des vulnérabilités (VA/VM) dominent dans de nombreuses organisations de sécurité. Ce type d'analyse réseau et infrastructure est extrêmement courant, car il est promu comme une bonne pratique informatique et de sécurité depuis des décennies. Certains fournisseurs de solutions VA/VM prétendent couvrir également les applications, mais il s'agit généralement d'identifier des vulnérabilités dans des logiciels commerciaux ou open source. Ces outils peuvent également être utiles pour identifier certains types de mauvaises configurations de serveurs ou de charges de travail. Cependant, ils ne permettent guère d'évaluer la sécurité de vos applications et API personnalisées. Il est courant de voir la VA/VM utilisée comme approche standard dans les programmes de sécurité plutôt qu'une approche formalisée de sécurité applicative avec des outils dédiés tels que les outils de test de sécurité des applications (AST).
Si la VA/VM est l'outil qui vous permet de scanner l'infrastructure de production à la recherche de vulnérabilités connues, alors le SCA est l'outil qui vous permet de scanner les composants pour identifier les dépendances externes vulnérables dans le code source de l'application ou dans l'infrastructure as code. Les analyses SCA peuvent être déclenchées lors des commits de code, exécutées dans le cadre des builds, initiées lors de la livraison (par exemple, lors de l'instanciation d'une charge de travail conteneurisée) ou exécutées en continu en production pour détecter les dérives. Le SCA s'est également banalisé et peut être trouvé sous forme de fonctionnalités intégrées dans les suites AST, inclus dans des offres basées sur Git comme GitHub et GitLab, et intégré dans la myriade d'offres de protection des charges de travail. Il existe également de nombreuses alternatives open source pour le SCA. Même si le SCA ne fonctionne que comme un vérificateur de dépendances de base, cela peut offrir une sécurité « suffisante » pour de nombreuses organisations.
Scanner des images de conteneurs ou des registres de conteneurs à la recherche de vulnérabilités publiées et bien connues est trivial par rapport à l'analyse à l'exécution et à la détection d'anomalies. Même les offres de protection des charges de travail doivent fournir une analyse continue à l'exécution pour être utiles. La recherche de dépendances vulnérables ne se limite pas à un instant T ou à une analyse de pipeline. La dérive de l'environnement est courante dans les opérations quotidiennes, à mesure que l'application ou son infrastructure de support vieillit. Si vous explorez les méandres des dépendances imbriquées ou transitives, vérifier si un code vulnérable est réellement exploitable vous entraîne dans un monde complexe d'analyse statique étendue, d'analyse dynamique, de fuzzing, d'analyse à l'exécution et d'analyse comportementale.
Les problèmes de sécurité ne se résument pas aux CVE
Common Vulnerabilities and Exposures (CVE) Les identifiants CVE couvrent les vulnérabilités connues dans les logiciels et matériels publiés. Ces types de problèmes de sécurité sont plus facilement identifiés par des outils d'analyse. Les techniques courantes incluent le scan des plages d'adresses IP réseau à la recherche de services en écoute, l'interrogation des informations de bannière des serveurs, l'empreinte numérique des logiciels exécutés sur les hôtes et l'évaluation des en-têtes dans les réponses des serveurs.
Common Weakness Enumeration (CWE) Les identifiants CWE sont des catégories plus larges de faiblesses logicielles, ce qui constitue le système de classification le plus approprié pour les problèmes dans les applications et API développées en interne. Ils sont moins connus mais aussi définis de manière plus large, ce qui signifie qu'un problème donné dans votre application personnalisée peut correspondre à plusieurs identifiants CWE. Malheureusement, cela complique le scoring des risques et le suivi des remédiations, mais c'est la réalité du développement sur mesure. Même les organisations qui achètent plus de logiciels qu'elles n'en développent finissent par créer du code personnalisé pour intégrer des systèmes et échanger des données. La CWE est la taxonomie la plus pertinente pour les types de problèmes de sécurité que vous pourriez créer par inadvertance lors de la construction ou de l'intégration de code. Si vous ne regardez que les CVE, vous passez à côté de la vue d'ensemble.
Les dépendances vulnérables connues que vous référencez dans votre code ou votre infrastructure as code deviennent partie intégrante de vos charges de travail en cours d'exécution. Par conséquent, la plupart des organisations se retrouvent avec un mélange de CWE, de CVE et plus encore. Bien qu'il s'agisse de taxonomies bien définies par le MITRE et le NIST, elles ne couvrent pas tout. Il existe également une latence inhérente dans le signalement et la divulgation des vulnérabilités. Il n'existe pas nécessairement de « correctif » pour la latence de signalement des CVE. C'est un sous-produit du processus d'auto-déclaration, du temps moyen de détection des problèmes, des accords de divulgation coordonnée des vulnérabilités et de la logistique de coordination des parties responsables.
Les secrets inavouables de l'AST
Il y a un éléphant dans la pièce lorsqu'on aborde les limites des outils d'AST :
Les outils d'analyse statique et dynamique sont incapables de détecter les failles de logique métier.
C'est tout simplement impossible compte tenu de la conception même de ces outils. La logique métier est propre à votre organisation, à la manière dont vous concevez et codez vos API. Par conséquent, le code qui représente votre logique métier suit rarement des modèles bien définis permettant d'établir des signatures ou des règles. Cette limite est comparable aux pièges des mécanismes de protection contre les menaces intégrés aux passerelles API et aux WAF.
L'AST capable d'instrumenter et d'analyser des applications ou des API au niveau du code pendant leur exécution (comme l'IAST) peut parfois révéler certaines faiblesses liées à l'élévation de privilèges. Les tests de sécurité basés sur l'instrumentation peuvent offrir une couverture limitée pour les failles d'autorisation au niveau de l'objet (BOLA) et les failles d'authentification . Cependant, la plupart des solutions du marché ne testent pas l'authentification ou l'autorisation en profondeur, se limitant à des vérifications superficielles comme la détection de méthodes d'authentification faibles (type Basic ou Digest). L'outil d'AST peut également analyser la manière dont les identifiants sont saisis, transmis ou stockés, ce qui ne constitue qu'une infime partie du problème. Techniquement, tester les failles d'élévation de privilèges nécessite de multiples exécutions d'un outil de DAST sur une application et son API. Malheureusement, le temps est une ressource rare dans de nombreuses organisations qui adoptent le DevOps et cherchent à réduire les cycles de mise en production. Les outils de DAST sont connus pour leur lenteur d'exécution, pire que le SAST et à peine mieux que le fuzzing.
Les outils de DAST ne sont pas non plus conçus pour le test d'API web. Ils nécessitent généralement une interface front-end pour initier les requêtes, comme du JavaScript s'exécutant dans un navigateur ou un binaire mobile sur un appareil. Les outils de DAST détectent les problèmes en interceptant, analysant et manipulant le trafic. Une partie de ce trafic peut concerner des API, mais ces outils n'ont aucune compréhension du fonctionnement interne de ces dernières. Scanner efficacement des API REST avec un DAST demande beaucoup de soin et de maintenance, un peu comme le paramétrage d'un WAF. La configuration du scanner peut être partiellement alimentée par la documentation de l'API ou définie manuellement, mais elle est indispensable pour qu'un outil de DAST puisse analyser un point de terminaison d'API de manière un tant soit peu intelligente. Malgré cela, un DAST peut tenter de détecter des vulnérabilités non pertinentes dans le monde des API, comme des panneaux d'administration cachés ou des tentatives de brute force sur des répertoires URL. Il incombe alors à l'expert de peaufiner la configuration du scan DAST et de supprimer ces règles. Cependant, un tel réglage exige une connaissance approfondie du système et de toutes ses API.
En résumé, les organisations doivent se tourner vers l'analyse à l'exécution et l'établissement de lignes de base des comportements des API afin d'identifier le large spectre des attaques et des abus de logique métier. L'analyse statique et dynamique a toujours eu ses lacunes. Le problème est exacerbé dans l'univers des API.
Les limites des validateurs de schéma
Forme d'analyse statique, les validateurs de schéma d'API sont souvent présentés comme la solution idéale pour la sécurité des pipelines DevOps. L'argument est généralement le suivant : « Donnez-nous vos définitions de schéma, nous scannerons vos API, nous assurerons leur conformité et vérifierons l'absence de vulnérabilités. »
L'approche par validation de schéma présente plusieurs problèmes :
- Tout n'a pas besoin d'être défini dans le schéma de l'API : Les formats de spécification d'API comme OpenAPI (OAS) et Swagger n'exigent pas que vous définissiez tous les champs ou fonctions dans la documentation. Il est courant que les développeurs oublient de documenter certains éléments, surtout s'ils ne travaillent pas avec des outils de conception d'API comme Postman.
- De nombreuses organisations négligent la documentation : Les humains sont notoirement mauvais pour documenter, et plus encore pour documenter de manière exhaustive. Le manque de documentation n'est pas un problème spécifique aux développeurs. L'OAS peut aider car il est auto-documenté, mais un effort manuel reste nécessaire. Certains outils sont également plus performants que d'autres pour générer la définition OAS.
- La dérive des API : Il est courant que la réalité de la production s'écarte des spécifications initiales. La dérive des API illustre l'un des problèmes majeurs auxquels les organisations sont confrontées lors des revues de conception sécurisée et des processus de modélisation des menaces. Il arrive souvent que le produit final diffère considérablement de ce qui avait été initialement prévu.
La validation et l'application de schémas ne sont que le vieux paradigme de la sécurité positive sous un nouveau jour. Au lieu que les équipes de sécurité aient à créer des règles ou des signatures, la charge est transférée aux équipes de développement. Le mélange de CWE et de CVE finira inévitablement par refaire surface. Tout comme leurs homologues AST, les validateurs de schémas restent incapables de détecter les failles de logique métier et peuvent également passer à côté d'expositions de données sensibles.
L'illusion des miroirs de production
Des environnements hors production reflétant la production sont nécessaires pour exécuter efficacement certains types d'AST, notamment le DAST et l'IAST. Malheureusement, ces environnements de test sont souvent un luxe pour de nombreuses organisations. Des écarts entre la production et le hors production sont probables si tous les éléments ne sont pas entièrement conteneurisés et facilement déployables. Les plateformes de conteneurs et les maillages de services peuvent faciliter la mise en place d'environnements à la demande, mais ces technologies imposent une courbe d'apprentissage abrupte. Les organisations dont la maturité DevOps est limitée peinent à les déployer et à les opérationnaliser. Il existe également des contraintes de coût ou de licence pour maintenir un environnement hors production pleinement fonctionnel et identique à la production. Le cloud peut sembler être une solution, car il est facile d'y lancer des instances éphémères, mais les coûts de calcul s'accumulent rapidement.
En l'absence d'environnements hors production fonctionnels, certaines organisations choisissent d'exécuter des outils DAST ou IAST directement en production. Bien que les fournisseurs assurent que leurs outils sont raisonnablement sûrs pour la production, de nombreuses organisations sacrifient la profondeur ou la précision des analyses en désactivant certains types de tests et en limitant les analyses récursives qui pourraient entraîner une interruption de service. Ces concessions réduisent encore davantage l'efficacité limitée des outils AST lorsqu'il s'agit d'API.
L'automatisation des tests de sécurité ne peut réussir sans l'automatisation des tests non liés à la sécurité
Automatiser vos tests de sécurité dans les chaînes d'outils de développement, les systèmes de contrôle de version et les pipelines de build exige de la discipline dans de nombreuses pratiques non liées à la sécurité. Une bonne couverture de code et de tests ne peut être atteinte sans une gestion adéquate des données de test, des environnements de test proches de la production, des tests unitaires définis, des scripts d'automatisation de tests fonctionnels (par exemple, Appium, Selenium), et plus encore.
Les données, les outils et les processus nécessaires à la réussite de l'automatisation des tests sont une responsabilité partagée entre les équipes d'identité, d'infrastructure et opérations (I&O), d'assurance qualité (QA) et de développement. Dans certaines organisations, le département QA n'existe même pas. Bien souvent, ce rôle a été considérablement réduit, voire totalement supprimé. Et même en supposant que tous ces fondamentaux de l'automatisation des tests soient en place, il est encore plus rare que les équipes de sécurité collaborent avec les équipes applicatives pour en tirer parti.
La collaboration entre la sécurité et les autres départements est inexistante dans certaines organisations, et la maturité DevOps peut y être plus faible. Le cloisonnement des équipes informatiques et l'isolationnisme peuvent persister tant que l'organisation n'a pas adopté une initiative de transformation numérique plus large. Ces approches pluriannuelles ne se limitent pas à la recherche d'outils de pipeline pour résoudre un problème. La transformation numérique implique de refondre radicalement le fonctionnement de l'organisation, la culture qu'elle encourage, sa manière de recruter des talents, et bien plus encore. Les méthodologies agiles et les pratiques DevOps sont généralement étroitement liées à cette transformation, mais de nombreux piliers nécessitent des années pour être maîtrisés. De nombreuses équipes de sécurité continuent d'opérer indépendamment des équipes de développement afin de rester concentrées sur d'autres risques de sécurité impactant leur organisation. Les frictions entre les équipes de développement, d'exploitation et de sécurité restent également plus fréquentes que nous ne voudrions le croire.
Lutter contre la pensée « chaîne de montage »
En tant que praticiens de l'informatique, nous ne travaillons pas dans des usines. Dans certains cercles, ces approches de pipeline et ces programmes DevOps sont parfois qualifiés d'usines logicielles. Le concept d'usine logicielle promeut une pensée de chaîne de montage, sauf que nous ne sommes ni des machines ni des ouvriers produisant des objets. Beaucoup soutiendraient également que les ouvriers d'usine ne sont pas toujours des travailleurs heureux. Si un travailleur est mécontent, cela impacte directement la qualité (et la sécurité). Toute forme de code doit être considérée comme imparfaite, car nous sommes des humains qui le créons. Nous n'avons pas encore atteint ce point de bascule où les machines génèrent le code elles-mêmes. Le code évolue également au fil du temps, passant entre de nombreuses mains tout au long de sa durée de vie. Il est soumis à de nombreux scanners et peut pourtant rester de faible qualité, exploitable ou vulnérable. De nombreuses organisations modèles en matière de DevOps, dotées de pipelines de build sécurisés, ont tout de même subi des attaques d'API entraînant des pertes de données, des atteintes à la vie privée, des problèmes de sécurité, des dommages à l'image de marque, et plus encore.
Toyota est souvent cité comme une réussite de l'agilité, ayant été pionnier du lean manufacturing et de la pensée agile. Toyota donnait également à ses ouvriers sur la chaîne de montage le pouvoir d'arrêter la production en tirant sur une corde andon s'ils observaient un problème. Pourtant, les véhicules Toyota ont été en proie à des problèmes d'accélération involontaire pendant des années dans les années 2000. Des experts ont par la suite examiné le code source de Toyota pour les nombreux systèmes embarqués et ont témoigné que les problèmes d'accélération involontaire étaient probablement causés par du code spaghetti, et non par des tapis de sol gênants ou des pédales d'accélérateur bloquées comme cela avait été initialement affirmé. Même si vous considérez cet événement comme le résultat de la corruption ou d'objectifs commerciaux passant avant la sécurité publique, ce sont toujours des facteurs qui ont conduit au contournement des protocoles de sécurité établis et des normes de développement.
Les problèmes détectés lors des tests de sécurité doivent être enregistrés en tant que bugs ou défauts, finissant inévitablement dans un backlog, ou vous devez arrêter le pipeline et faire échouer le build. Faire échouer les builds de manière excessive bloque les cycles de publication. D'autres aspects de la mise en production entrent également en jeu. Savons-nous si les problèmes sont réellement exploitables ou vulnérables ? Quelle sévérité et quelle priorité doivent être attribuées à un problème détecté ? Jusqu'où dans le backlog des défauts le problème détecté doit-il aller ? Faut-il arrêter une mise en production pour des problèmes de sévérité potentiellement faible qui pourraient ou non être exploitables ?
Il y a probablement plus d'un pipeline
La plupart des organisations utilisent un mélange de technologies impliquant différents langages de programmation et processus de développement. Il existe probablement une combinaison d'architectures monolithiques et de microservices, de technologies héritées et modernes, ainsi que de méthodologies en cascade et agiles. Ce mélange conduit inévitablement à la multiplication des pipelines de build au sein des organisations, ainsi qu'à une réduction de la visibilité ou du contrôle sur ces derniers. Parmi les facteurs contributifs, on peut citer :
- Certains codes et les pipelines qu'ils empruntent peuvent échapper à votre contrôle.
- Un pipeline de build formalisé peut être inexistant si l'équipe responsable n'a pas adopté le CI/CD.
- De nombreuses organisations externalisent ou délocalisent tout ou partie de leur développement.
- Les efforts de développement sont souvent fragmentés, avec des équipes front-end et back-end distinctes, ou des équipes dédiées à certains sous-ensembles de fonctionnalités.
- Les plateformes low-code peuvent ne pas fournir de flux de travail et de services de build formalisés, ou les artefacts de code peuvent être des éléments inconnus.
Les réalités du développement d'applications d'entreprise, de l'intégration et de l'ingénierie système entraînent inévitablement la multiplication des pipelines de build. Plus il existe de pipelines, plus il devient difficile pour la sécurité d'obtenir de la visibilité, d'intégrer des outils ou d'exercer un contrôle. Unifier tous les builds en un seul pipeline est irréaliste pour la plupart des organisations, car il existe souvent des besoins métier légitimes justifiant des piles technologiques différentes.
Considérez les pipelines sous un nouvel angle
Les meilleures pratiques et les outils pour sécuriser le pipeline de build lui-même sont également encore récents. Les organisations font parfois des compromis sur la sécurité des services CI/CD, ou les outils ne sont pas correctement conçus pour garantir l'intégrité de tout ce qui transite par un pipeline. Les divers services VCS, CI et CD sont eux-mêmes des applications, souvent basées sur des API. Ils peuvent également être attaqués de diverses manières, ce qui met en péril tout ce qui passe par votre pipeline. Les équipes qui opèrent au sein du pipeline peuvent supprimer des contrôles ou des résultats afin de publier le code. Les risques inhérents à la chaîne d'approvisionnement s'aggravent à mesure que vous vous approvisionnez en code ou en dépendances auprès de tiers. Des partenaires ou des fournisseurs peuvent également fournir du code personnalisé qui ne fait pas partie de votre pipeline, mais qui finit par intégrer le code compilé ou le système complet de l'organisation. Tous ces facteurs ont un impact potentiel sur la qualité et la sécurité de tout ce qui transite par vos pipelines.
Il est important de se rappeler que l'analyse des pipelines inclut des vérifications pour toutes les formes de code, mais aussi des contrôles pouvant être audités par programmation. Les pratiques DevOps s'étendent au-delà du simple code source des applications pour inclure également l'infrastructure en tant que code (IaC) et la politique en tant que code (PaC). Tout comme la fonctionnalité ne dépend pas uniquement du code de l'application, il en va de même pour la sécurité, et de nombreux contrôles de sécurité existent en dehors du code. Les éléments que vous validez dans les pipelines peuvent simplement consister à confirmer qu'un contrôle de sécurité d'exécution donné est activé et configuré de manière appropriée dans l'IaC ou la PaC.
Conclusion
Établir et faire adopter des approches de pipeline de build sécurisées est une entreprise de plusieurs années pour les organisations. Et aucun effort de sécurisation de pipeline ne peut réussir sans atteindre un certain niveau de maturité DevOps. On dit souvent que le DevOps est un voyage, et ce n'est pas pour rien. Il faut des années pour faire mûrir vos processus et vos chaînes d'outils. Plus important encore, il faut du temps pour obtenir l'adhésion de tous les profils informatiques, au sein et à l'extérieur de l'organisation. Les attaquants, eux, ne se soucient pas de votre parcours DevOps et, en attendant, ils contournent les contrôles d'accès, exploitent les faiblesses et abusent de la logique métier.
Les approches « shift-left » et de sécurisation des pipelines de build ont leurs mérites. Cependant, les organisations doivent accepter le risque qu'il existe de nombreux types de problèmes de sécurité qui ne peuvent tout simplement pas être détectés dans le cadre d'analyses automatisées de conception, de développement et de build. Les organisations matures dans leurs stratégies de sécurité des API et leurs programmes DevSecOps admettent qu'au mieux, elles ne détectent qu'une partie des problèmes de sécurité avec un outil d'analyse donné. Les problèmes détectables se limitent aux vulnérabilités et faiblesses qui suivent des modèles bien définis. De nombreux problèmes de sécurité ne se manifestent qu'au moment de l'exécution, au sein du système complet et dans l'architecture d'entreprise.
L'analyse comportementale à l'exécution est une voie à suivre pour les organisations et un moyen de se protéger contre le large spectre des problèmes et attaques liés aux API. Toute offre doit permettre une détection et une prévention précoces, arrêtant les attaquants avant qu'ils ne réussissent à exploiter ou à abuser de vos API. La plateforme de protection des API de Salt Security a été conçue pour éviter les nombreux pièges des approches d'analyse traditionnelles et des mesures d'atténuation à l'exécution. La plateforme de protection des API de Salt est :
- Cycle de vie complet, offrant des capacités pour les phases de conception, de build et d'exécution afin de renforcer et de protéger vos API contre le large spectre des modèles d'attaque d'API.
- Intégrée, fonctionnant avec vos investissements technologiques existants et minimisant l'impact sur les flux de travail de tous les profils qui interagissent avec les API
- Inspirée par le ML, apportant une expertise intelligente sur les multiples domaines de sécurité critiques pour la protection des API, pour lesquels il est par ailleurs difficile de recruter des compétences
- Automatisé, en apprenant la logique métier et les modèles de conception d'API propres à votre entreprise afin de proposer automatiquement des analyses de sécurité sur mesure
Pour en savoir plus sur la façon dont Salt peut aider à protéger votre organisation contre les risques liés aux API, vous pouvez contacter un représentant ou planifier une démonstration personnalisée.