La sécurisation de votre chaîne d'approvisionnement en logiciels commence par la découverte et la gouvernance de votre « usine de logiciels »
Dans l'environnement de développement logiciel actuel, les équipes gèrent des ressources décentralisées telles que des référentiels de code, des pipelines de build et des images de conteneurs. Bien que ce modèle distribué offre de la flexibilité et accélère la production, il fragmente également les ressources et complique la gouvernance et la surveillance de la sécurité, en particulier à mesure que les applications cloud natives se généralisent.
En conséquence, les équipes de sécurité perdent souvent un temps précieux à rechercher les propriétaires de code des charges de travail de production orphelines lorsque des problèmes de sécurité surviennent ou lorsque des artefacts logiciels non autorisés parviennent à la production. La chaîne d'approvisionnement logicielle est devenue une surface d'attaque critique, et il est essentiel de recueillir les signaux de sécurité en amont, du développement jusqu'à la phase de construction, pour éviter les angles morts et garantir que tous les actifs tout au long du cycle de vie de développement logiciel (SDLC) sont surveillés.
Les équipes DevSecOps manquent généralement d’outils automatisés pour cartographier en permanence ce paysage de développement en constante évolution, où de nouveaux chemins de code et outils sont fréquemment introduits. Les informations restent souvent cloisonnées sur différentes plateformes, ce qui les rend difficiles d’accès à des fins de sécurité. Les plateformes et outils de développement varient souvent au cours du développement, de l’intégration et du déploiement à mesure que le logiciel progresse au fil des étapes.
Bien que les fournisseurs d’applications de sécurité (ASPM) et d’observabilité regroupent les analyses de sécurité, ils ne parviennent souvent pas à fournir une vue complète reliant les chemins de code à la production.
La présence d'actifs obsolètes aggrave le problème. Identifier les référentiels toujours actifs en production peut s'avérer compliqué, en particulier pour les grandes organisations. Les fusions et acquisitions compliquent encore davantage la tâche en ajoutant diverses plateformes et normes de développement.
Les équipes DevSecOps ont souvent recours à des processus manuels, comme le remplissage de manifestes ou l’étiquetage de conteneurs, qui sont fastidieux, sujets aux erreurs et souvent mis de côté au profit de priorités plus urgentes.
Considérez cela comme la défense d'un champ de bataille en constante évolution, où les équipes de sécurité ont besoin d'une carte précise pour protéger leurs actifs. Ces actifs sont en constante évolution et de nouvelles cibles doivent être identifiées et sécurisées. Pour résoudre ce problème, un mécanisme de découverte continu est nécessaire pour cartographier les changements au fur et à mesure qu'ils se produisent.
Les meilleures pratiques et cadres soutiennent cette approche. Par exemple, Agence de la cybersécurité et de la sécurité des infrastructures (CISA) oblige les organisations à vérifier la provenance des composants logiciels et à maintenir un inventaire complet dans le cadre de leur processus d'auto-attestation. De même, le Cadre de développement de logiciels sécurisés (SSDF) du NIST et les Modèle de maturité DevSecOps OWASP (DSOMM) souligner l’importance de la découverte et de la visibilité continues.
Dans la suite de cet article, nous présenterons un plan pour relever ces défis et explorerons comment Scribe Security aide les organisations à mettre en œuvre ces capacités de manière efficace.
Le plan directeur de Scribe pour une découverte efficace
Discovery génère une carte modélisée sous forme de graphique, offrant une vue des actifs, des relations et de la posture de sécurité de votre usine. Cela permet :
- Visibilité complète et contrôle de la propriété.
- Capacités d’interrogation améliorées.
- Suivi des KPI et des indicateurs de maturité de sécurité.
- Identification et priorisation plus rapides des facteurs de risque.
- Balayage initial
L'analyse initiale vise à créer une carte de haut niveau des ressources, en se concentrant sur l'identification de celles qui nécessitent une analyse plus approfondie. Une analyse approfondie complète peut prendre du temps et de nombreuses ressources, telles que celles qui ne sont pas liées à la production ou obsolètes, peuvent être sans intérêt. Cette analyse initiale rassemble généralement des informations de base telles que les noms des référentiels, les identifiants et les statistiques d'activité, mais n'inclut pas une liste complète des commits ou des contributeurs.
L'une des méthodes consiste à analyser de « droite à gauche ». En accédant aux environnements de production (par exemple, via l'API du cluster K8s), l'analyseur peut identifier les images de conteneurs en cours d'exécution, c'est-à-dire les actifs critiques qui reflètent la valeur commerciale. À partir de là, l'analyse remonte jusqu'au registre de conteneurs et aux référentiels pertinents. L'analyse s'arrête généralement ici, car il n'y a généralement pas de connexion directe entre le registre et le pipeline SDLC précédent.
Des analyses complémentaires peuvent être exécutées de « gauche à droite », en identifiant les référentiels de code, les pipelines de build et les registres à travers différentes étapes du SDLC (par exemple, développement, intégration, tests).
Le résultat est une liste hiérarchisée d'actifs sur plusieurs plateformes, prêts à être analysés en profondeur pour retracer la lignée du code à la production et évaluer la posture de sécurité du SDLC. La priorisation est basée sur des facteurs tels que la pertinence par rapport à la production, le niveau d'activité et la récence. Parfois, la connaissance institutionnelle de l'importance des actifs permet de guider ce processus.
L'analyse initiale peut être planifiée périodiquement ou déclenchée par des événements tels que des envois de code. Les analyses suivantes peuvent appliquer des critères de sélection automatique, tels que l'utilisation de globs pour une analyse approfondie des actifs nouvellement découverts.
- Analyse approfondie
Une fois les ressources pertinentes hiérarchisées, l'analyse approfondie collecte des attributs détaillés qui établissent des relations entre les ressources, telles que les identifiants de branche, les identifiants de validation et de validation et les identifiants d'exécution de pipeline. La durée de cette analyse peut varier en fonction de l'étendue des ressources et des limites de débit de l'API.
À la fin de cette étape, un graphique de relations entre les ressources commence à prendre forme, avec des clusters de ressources connectées autour des référentiels de code (contenant des informations de build) et des environnements d'exécution (avec des ressources de registre). Cependant, une lignée complète est encore incomplète, car les registres ne stockent généralement pas d'informations sur les pipelines qui ont poussé les artefacts de build.
- Connecter les clusters
Une fois l'inventaire établi, la lignée peut être complétée en instrumentant un outil CLI dans le pipeline pour capturer les détails de provenance de la build ou en traitant les journaux CI. L'instrumentation est la méthode la plus fiable, enregistrant des attributs clés tels que les identifiants de référentiel de code, les identifiants de pipeline et d'exécution et les identifiants d'image. Elle relie efficacement les clusters précédemment isolés et crée une lignée complète de bout en bout du code à la production.
Une approche complémentaire est le traitement des journaux CI, qui récupère les attributs pertinents mais nécessite davantage de ressources et dépend de la journalisation existante. Bien que cette méthode offre une mise en œuvre plus rapide, la combinaison des deux approches donne les meilleurs résultats : instrumentation des pipelines critiques et utilisation de l'analyse des journaux pour les pipelines nouvellement découverts, qui peuvent ensuite être évalués pour une instrumentation plus poussée.
Cette approche de clustering prend également en compte l’agrégation de lignées distinctes dans une structure unifiée pour des produits complexes, tels que des applications Web composées de plusieurs composants, tels que des microservices.
- Nomenclature logicielle (SBOM)
Jusqu'à présent, l'accent a été mis sur la connexion des ressources de développement entre les plateformes, en établissant une lignée claire du code à la production pour les ressources concernées. L'attention se porte désormais sur la composition des artefacts logiciels eux-mêmes. Au cours de cette étape, un SBOM est généré à partir de ces artefacts et de leurs référentiels de code associés, en les ajoutant à l'inventaire existant.
En synthétisant un référentiel de code et des SBOM d'artefacts en un seul SBOM, avec une logique permettant de corréler les dépendances et d'exclure celles qui ne sont pas pertinentes, telles que les bibliothèques de développement et de test, le résultat est un SBOM plus précis et plus complet que celui que l'une ou l'autre source pourrait fournir seule.
- Posture de sécurité et indicateurs clés de performance DevSecOPs
La cartographie continue de l'inventaire des actifs et de leurs relations offre la meilleure opportunité d'évaluer la posture de sécurité de ces actifs. Les facteurs clés incluent les autorisations d'accès pour les identités humaines et non humaines, la vérification de la signature du code, les dépendances risquées ou vulnérables et les paramètres de sécurité sur différentes plateformes et comptes.
Ces données peuvent être agrégées en différentes dimensions pour mesurer les indicateurs clés de performance (KPI) des versions de produits, les délais de déploiement en production et la maturité DevSecOps. Plus précisément, elles permettent aux équipes d'évaluer l'adoption des contrôles de sécurité, tels que la signature de code et le respect des paramètres de sécurité, ce qui permet de suivre les progrès et de garantir des pratiques de sécurité robustes.
- Visualisation et interrogation du SDLC et du graphique de la chaîne d'approvisionnement logicielle
L'un des principaux avantages du processus de découverte est la possibilité de visualiser le cycle de développement logiciel et la chaîne d'approvisionnement logicielle sous forme de graphique dynamique ou de « carte de bataille ». Cette visualisation offre une vue complète de l'ensemble du cycle de vie du développement, facilitant ainsi le suivi des actifs et de leurs relations.
La véritable puissance réside dans la possibilité d’interroger le graphique, ce qui permet aux équipes de poser des questions cruciales, telles que :
- « Quel composant a échoué à un contrôle de sécurité lors de sa création ou de son déploiement ? »
- « Quelles charges de travail en production sont orphelines ? »
- « Qui a commis le changement qui a introduit une vulnérabilité ? »
- « À qui appartient l’actif qui doit être corrigé ? »
L'interrogation de la lignée aide les équipes à identifier la cause profonde des problèmes, ce qui constitue un avantage évident par rapport à la documentation manuelle. Les mappages de propriété gérés manuellement deviennent rapidement obsolètes, ce qui conduit souvent les équipes DevSecOps à rechercher de manière inefficace les bonnes parties prenantes. En revanche, un graphique interrogeable garantit que la propriété et la responsabilité sont toujours à jour, réduisant ainsi le temps perdu à rechercher la responsabilité du code ou de l'infrastructure.
- Options de déploiement pour les outils de découverte
Les organisations ont des besoins variés en matière de déploiement d'outils de découverte, et il est essentiel de proposer des options de déploiement flexibles pour répondre aux différentes exigences de sécurité. Certaines équipes préfèrent l'accès à distance via une plateforme SaaS, ce qui simplifie la gestion et la mise à l'échelle. En revanche, les équipes ayant des protocoles de sécurité plus stricts peuvent choisir le déploiement d'un scanner local pour maintenir un contrôle plus strict sur les informations d'identification sensibles, telles que les jetons d'API de la plateforme de développement. Le choix entre le déploiement SaaS et le déploiement local dépend de facteurs tels que la posture de sécurité de l'organisation, les besoins de conformité et le contrôle des données.
Conclusion
La sécurisation de votre chaîne d'approvisionnement logicielle est une bataille permanente. Aucune organisation ne devrait s'y lancer sans une carte claire. En mettant en œuvre un processus de découverte robuste, vous obtenez une visibilité complète sur votre SDLC et votre chaîne d'approvisionnement, garantissant que chaque actif est pris en compte, du développement à la production. Avec des outils tels que le plan directeur de Scribe Security, vous pouvez créer une lignée connectée, générer des SBOM précis, évaluer votre posture de sécurité et visualiser les relations critiques au sein de votre écosystème de développement. Ce niveau de connaissance permet aux équipes DevSecOps d'identifier rapidement les vulnérabilités, de retracer leurs origines et de maintenir une compréhension à jour de leur paysage logiciel, ce qui est essentiel pour garder une longueur d'avance dans l'environnement de développement rapide et complexe d'aujourd'hui.
Scribe propose une solution complète pour la découverte et la gouvernance en tant qu'outil essentiel pour sécuriser votre chaîne d'approvisionnement en logiciels :
- Analyses initiales et approfondies – Identifie et hiérarchise les actifs tels que les référentiels de code, les pipelines et les images de conteneurs dans les environnements, en créant un inventaire des composants pertinents.
- Lignée de bout en bout – Connecte des clusters d’actifs isolés à l’aide d’outils CLI et de journaux CI, formant une lignée complète du code à la production.
- Nomenclature logicielle (SBOM) – Génère des SBOM précis en synthétisant les données des artefacts et du référentiel, en excluant les dépendances non pertinentes.
- Évaluation de la posture de sécurité – Évalue en permanence les contrôles d’accès, les signatures de code et les dépendances vulnérables pour mesurer les KPI de sécurité.
- Visualisation et interrogation – Visualise l’intégralité du SDLC et permet des requêtes pour retracer les vulnérabilités, les charges de travail orphelines et la propriété des actifs.
- Déploiement flexible – Prend en charge les déploiements SaaS et locaux pour répondre aux différents besoins de sécurité et de contrôle des données sensibles.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
