10 catégories d'outils de sécurité nécessaires pour renforcer la sécurité de la chaîne d'approvisionnement logicielle

Par Ericka Chickowski

Contributeur OSC, OSC |

Au fur et à mesure que les responsables de la sécurité progressent dans la mise en place de programmes de sécurité de la chaîne d'approvisionnement logicielle, ils font face à une situation de bonnes et de mauvaises nouvelles avec les outils à leur disposition - littéralement : la technologie progresse rapidement pour le meilleur et pour le pire.

La bonne nouvelle de l'évolution rapide de la technologie de sécurité de la chaîne d'approvisionnement logicielle est que le rythme soutenu de l'innovation offre de plus en plus d'opportunités d'obtenir une plus grande visibilité et transparence dans la vaste gamme de composants et de code qui alimentent les portefeuilles de logiciels.

La mauvaise nouvelle, cependant, est que l'expérimentation et l'innovation vont dans de nombreuses directions différentes en même temps et que le paysage des outils est un mélange déroutant d'acronymes de catégories et de produits de niche nouveaux et en évolution.

Certains d'entre eux sont des outils de sécurité d'application plus traditionnels qui évoluent pour être plus conviviaux pour les développeurs. D'autres sont des outils de développement traditionnels qui renforcent les contrôles et les fonctionnalités axés sur la sécurité pour relever le défi des risques de la chaîne d'approvisionnement. D'autres encore émergent du monde DevSecOps - spécialement conçus pour favoriser la collaboration mutuelle entre ces tribus.

"L'une des raisons pour lesquelles il est si difficile d'avoir une image claire de la sécurité de la chaîne d'approvisionnement logicielle est qu'il y a tellement d'éléments dans la chaîne d'approvisionnement où quelque chose peut mal tourner", a déclaré Tom Goings, consultant produit chez Tanium. "Vous pouvez avoir des vulnérabilités introduites directement dans le logiciel, comme l'exemple de SolarWinds d'il y a quelques années, des vulnérabilités dans des bibliothèques courantes comme Log4j, ou même quelque chose comme une autorité de certification (CA) compromise."

Alors que plusieurs piles et plates-formes de produits de sécurité de la chaîne d'approvisionnement logicielle plusieurs piles et plates-formes de produits de sécurité de la chaîne d'approvisionnement logicielle commencent à se consolider sur le marché, la combinaison de fonctionnalités de ces produits est omniprésente.

La principale catégorie d'outils sur laquelle ces plates-formes ont tendance à se concentrer est l'analyse de la composition logicielle (SCA) et les outils générant des nomenclatures logicielles (SBOM), ces soi-disant «listes d'ingrédients» des logiciels modernes. Alors que les SCA et les SBOM ont tendance à constituer l'épine dorsale de nombreux outils logiciels de sécurité de la chaîne d'approvisionnement, cela ne devrait être que la pointe de l'iceberg pour les CISO qui tentent d'élaborer une feuille de route pour soutenir un programme complet de gestion des risques de la chaîne d'approvisionnement.

"Lorsqu'ils examinent la sécurité de la chaîne d'approvisionnement, les gens se concentrent sur l'utilisation d'outils tels que SCA et ils examinent les SBOM", a déclaré Dale Gardner, directeur principal et analyste pour la sécurité des applications chez Gartner, à CSO. "Ce sont des éléments très importants de la solution. Mais ce ne sont vraiment qu'une sorte de solution très partielle."

De nombreuses autres parties mobiles sont impliquées, notamment la gestion des secrets, le mappage et la gestion des dépendances, la sécurité du pipeline CI/CD, la gestion efficace du référentiel, etc. La plupart des experts s'accordent à dire que les équipes de sécurité auront du mal à trouver tout ce dont elles ont besoin auprès d'un seul fournisseur.

"Je dirais qu'il n'y a pas un seul fournisseur qui gère tous les défis associés à la sécurité de la chaîne d'approvisionnement logicielle d'une manière qui répondrait aux exigences de toutes les organisations", explique Michael Born, responsable principal de la sécurité des applications chez le cabinet de conseil Coalfire. Il dit au CSO que le manque de consolidation n'est pas nécessairement une mauvaise chose. "Cela exposerait potentiellement les organisations aux risques associés au verrouillage des fournisseurs et pourrait signifier que l'organisation mûrit ou change plus rapidement que ce que le fournisseur pourrait suivre."

Cette fragmentation est le résultat non seulement de l'innovation organique provenant de plusieurs perspectives techniques différentes (outils axés sur le développement, outils axés sur les opérations, outils axés sur la sécurité), mais aussi du fait qu'il existe une gamme de cas d'utilisation différents traités.

"Nous devons être assez précis sur le risque ou le cas d'utilisation dont nous parlons pour pouvoir trouver les bonnes solutions logicielles ou le type global de pile de solutions pour pouvoir les résoudre", explique Sharon Chand, le cyber responsable de la chaîne d'approvisionnement sécurisée des risques pour la pratique Cyber Risk Services de Deloitte. "Parce que le type de solution dont j'ai besoin dépendra vraiment de ma place dans ce scénario de sécurité de la chaîne d'approvisionnement logicielle. Si je suis un producteur de logiciels, cela aura l'air différent que si je suis un consommateur de logiciels. Et plus souvent que tout le monde ne sera pas les deux à certains moments du cycle de vie global de la chaîne d'approvisionnement."

La façon dont les organisations assemblent tout cela dépendra fortement de leurs cas d'utilisation, de leur infrastructure et de la composition des compétences et de la culture de leurs équipes. Malheureusement, il n'y a pas encore de bouton facile pour construire cette pile.

La liste suivante offre aux RSSI une bonne liste de contrôle de démarrage pour planifier la pile de solutions logicielles de sécurité de la chaîne d'approvisionnement qui fonctionnera pour eux. La liste n'est pas exhaustive à 100 % - et elle changera probablement rapidement. Mais il inclut les principales catégories d'outils et fonctionnalités que les responsables de la sécurité voudront probablement prendre en compte pour leur feuille de route de sécurité de la chaîne d'approvisionnement logicielle.

Les outils SCA sont peut-être mieux connus à ce stade pour leur rôle dans la sécurité de la chaîne d'approvisionnement logicielle, mais l'histoire d'origine de cette catégorie a commencé sur un territoire encore plus prosaïque. Ces outils ont été initialement conçus pour aider les équipes de développement à suivre l'utilisation de leurs composants open source dans leurs versions afin de maîtriser la conformité des licences. Alors que la sécurité de la chaîne d'approvisionnement commençait à gagner du terrain, les outils SCA ont intégré une analyse et une gestion plus approfondies des vulnérabilités et des risques de sécurité liés aux composants suivis et sont devenus l'une des méthodes de référence permettant aux organisations de générer des SBOM et de régir leur utilisation open source. Mend.io (anciennement WhiteSource), FOSSA et Synopsys Black Duck sont d'excellents exemples de cette voie évolutive.

SCA n'est pas la seule option pour générer des SBOM. Certaines autres méthodes de génération de SBOM incluent l'utilisation d'outils d'interface de ligne de commande (CLI) comme CycloneDX CLI et SPDX Tool, l'analyse d'exécution comme Rezilion ou l'analyse binaire comme ReversingLabs. Mais la SCA a tendance à être un enjeu de table pour les fournisseurs qui créent des piles ou des écosystèmes de solutions de chaîne d'approvisionnement logicielle. Certains d'entre eux sont des fournisseurs SCA qui se sont diversifiés dans les autres catégories d'outils décrites ci-dessous - par le biais d'un développement interne ou d'une acquisition. D'autres ont peut-être commencé avec une mentalité de plate-forme avec les développeurs à l'esprit dès le départ, y compris SCA dans un mélange d'outils de chaîne d'approvisionnement ; Snyk en est un bon exemple. Il y a également eu plus de partenariats comme celui annoncé récemment entre Synopsys et ReversingLabs qui élargit les capacités de sécurité de la chaîne d'approvisionnement sans enfermer les clients dans une seule plate-forme.

La sécurisation de la chaîne d'approvisionnement logicielle est un problème d'appsec, il s'ensuit donc que les outils traditionnels d'analyse de code appsec vont jouer un rôle dans cette pile de solutions. Les outils SAST (tests de sécurité des applications statiques), DAST (tests de sécurité des applications dynamiques), IAST (tests de sécurité des applications interactifs) et RASP (protection de l'analyse des applications d'exécution), ainsi qu'une utilisation judicieuse des tests d'intrusion peuvent aider les organisations à tester leur propre code interne et fournir des vérifications supplémentaires dans le code tiers pour agir comme un filet de sécurité pour les risques qui "pourraient autrement être manqués en utilisant des outils et des techniques de test SCA ou SBOM courants", déclare Born of Coalfire.

Le maintien de plusieurs couches à travers une liste complète de numérisation de code est crucial, dit-il, tout comme ces vérifications ponctuelles des tests de stylo.

"Les produits SCA et SBOM s'appuient sur des vulnérabilités connues et précédemment identifiées, tandis qu'une évaluation approfondie de la pénétration des applications peut identifier l'utilisation de code vulnérable lors de l'examen de bibliothèques et de frameworks tiers qui n'avaient peut-être pas été signalés ailleurs", a-t-il déclaré.

Au fur et à mesure que les organisations créent leurs propres SBOM et ingèrent les SBOM de leurs fournisseurs, l'agrégation, l'enrichissement et la gestion de ces artefacts vont jouer un rôle de plus en plus important dans leur opérationnalisation. Par exemple, l'ajout d'informations d'échange d'exploitabilité de vulnérabilité (VEX) sera une partie de plus en plus importante de la contextualisation des SBOM. De même, les données avec lesquelles ces outils pourraient potentiellement enrichir les informations SBOM incluent des vérifications de l'état des composants telles que les données OpenSSF Scorecard et les scores EPSS (Exploit Prediction Scoring System) de la base de données Known Exploited Vulnerabilities (KEV) de CISA.

De plus, la simple agrégation des informations SBOM sur les portefeuilles de logiciels et les secteurs d'activité sera une préoccupation croissante pour les responsables de la sécurité. Il s'agit toujours d'un domaine nouvellement émergent qui n'a pas vraiment fusionné dans une catégorie identifiée par les analystes de l'industrie, de sorte que les CISO doivent rechercher ces fonctionnalités dans les outils de type SCA+, les outils open source et les nouvelles plates-formes qui flamboient ce qu'ils espèrent être. leurs propres chemins de définition de catégorie. Certains exemples en jeu incluent Cybellum, Anchore et Rezilion, ainsi que de nouveaux outils open source comme Bomber.

L'analyse et la gestion des secrets partagés passent rapidement d'une catégorie d'outils autonomes à une fonctionnalité intégrée à toutes les versions des outils de sécurité de la chaîne d'approvisionnement logicielle. En effet, les secrets intégrés dans le code source, les fichiers de configuration et le code d'infrastructure sont toujours répandus dans les environnements de développement et en direct et il est urgent de maîtriser le problème.

"Les secrets tels que les fichiers d'informations d'identification, les clés privées, les mots de passe et les jetons d'API ne doivent pas être validés dans un référentiel de contrôle de source", recommande un rapport Gartner récemment mis à jour. "Utilisez un outil de gestion des secrets pour stocker et chiffrer en toute sécurité les secrets, appliquer les contrôles d'accès et gérer les secrets (c'est-à-dire créer, faire pivoter et révoquer)."

Il s'agit d'un composant d'outillage fondamental, car les attaquants peuvent tirer parti des secrets partagés pour saper complètement l'intégrité de la chaîne d'approvisionnement logicielle d'une organisation.

La gestion et l'analyse des dépendances sont une autre catégorie quelque peu nébuleuse avec un degré élevé de chevauchement avec d'autres catégories d'outils comme l'agrégation SCA et SBOM. Mais cela vaut la peine d'être appelé car il touche au cœur de certains des problèmes de sécurité de la chaîne d'approvisionnement des logiciels les plus épineux.

Certaines des plus grandes plaintes des défenseurs de la sécurité concernant l'état des SBOM aujourd'hui sont qu'ils ont encore du mal à communiquer les dépendances transitives liées aux logiciels énumérés.

Les RSSI et leurs équipes vont avoir besoin de meilleures façons de cartographier et de gérer le réseau caché de dépendances qui s'étendent sur leurs applications, leurs API, leurs composants de pipeline CI/CD et leur infrastructure en tant que code. Certains outils disponibles incluent des outils de cartographie des dépendances sur lesquels les acteurs de la performance et de la résilience s'appuient également, comme ceux de Datadog et Atlassian. De plus, les outils de gestion SCA et SBOM intègrent souvent ces fonctionnalités dans leur combinaison. Un acteur notable qui a récemment frappé le marché sur ce front est Endor Labs, qui est sorti du mode furtif en octobre 2022, se décrivant comme une solution de « gestion du cycle de vie des dépendances ». Le mois dernier, l'entreprise a été finaliste de l'Innovation Sandbox de la RSA Conference.

Bien que les référentiels d'artefacts et les registres de conteneurs ne soient pas des outils de sécurité en soi, leur utilisation avec des politiques et des procédures disciplinées peut jouer un rôle important dans la gestion des risques de la chaîne d'approvisionnement. La mise en place de référentiels d'artefacts et de registres de conteneurs fiables est un élément fondamental de l'infrastructure permettant d'établir des « garde-corps sécurisés » pour les développeurs. Offrir des sources centralisées de composants approuvés est un moyen proactif d'éviter les problèmes et d'établir une saine gouvernance de ce qui entre dans le logiciel d'une organisation.

"Les référentiels agissent comme une source fiable pour les artefacts et les composants logiciels sanctionnés et vérifiés", ont écrit les analystes de Gartner. "Cela permet une gouvernance, une visibilité, une auditabilité et une traçabilité centralisées dans les 'ingrédients' logiciels."

La signature de code devient de plus en plus la meilleure pratique pour garantir l'intégrité du code et des conteneurs lorsque les développeurs valident et déploient des logiciels tout au long de leur cycle de vie. Il s'agit d'un processus crucial non seulement pour mettre en place des contrôles internes solides contre la falsification, mais aussi pour renforcer la confiance des clients envers les produits expédiés à des clients externes. Naturellement, les certificats de signature de code sont une cible privilégiée pour les attaquants de la chaîne d'approvisionnement logicielle. Les RSSI et leurs équipes devront donc s'assurer qu'ils choisissent les bons outils et établissent des contrôles pour s'assurer que leur processus de signature de code est vraiment sécurisé. Certains des poids lourds de cette catégorie incluent Garantir, Keyfactor, CircleCI, Cosign et Venafi.

Le pipeline d'intégration continue/livraison continue fait partie de l'« usine » logicielle sur laquelle les développeurs s'appuient pour produire leur code et fait donc partie intégrante de l'ensemble de la chaîne d'approvisionnement. En tant que tels, les outils de sécurité pour renforcer ces environnements font partie intégrante d'un programme de sécurité de la chaîne d'approvisionnement solide. Nous avons déjà abordé la gestion des secrets, qui est une facette importante de cette catégorie. D'autres incluent la politique CI/CD et la gestion de la gouvernance, comme ce que produisent des entreprises comme Apiiro et Cycode, ainsi qu'un contrôle d'accès privilégié et une authentification forte bien implémentés.

La plupart des outils décrits jusqu'à présent visent principalement à approfondir les composants tiers utilisés dans les logiciels développés en interne. Mais qu'en est-il de tous ces logiciels commerciaux tiers sur lesquels les organisations n'ont pas autant de visibilité ? C'est là que les outils et processus de gestion des risques tiers (TPRM) jouent un rôle. Même avec les exigences fédérales du SBOM en lice pour pousser une plus grande transparence de la part des éditeurs de logiciels dans les années à venir, pour le moment, la plupart des organisations volent assez aveuglément. Bien que les outils de notation des risques TPRM tels que SecurityScorecard ou RiskRecon ne résolvent pas complètement ce problème, ils peuvent au moins servir de proxy pour le risque qui pourrait potentiellement amener les organisations à identifier où elles doivent travailler avec certains fournisseurs et fournisseurs de logiciels pour approfondir leur code.

"Là où je pense que l'offre TPRM peut intervenir, c'est s'il y a un risque et que je suis capable d'identifier le risque, c'est peut-être là que je veux vraiment concentrer mes efforts autour de SCA et comprendre la composition du logiciel", déclare Chand de Deloitte. "Cela devient une technique d'atténuation des risques plutôt qu'une solution au beurre de cacahuète que je répands sur tous les logiciels que je produis ou que j'acquiers."

Elle dit que le monde de la sécurité de la chaîne d'approvisionnement logicielle manque toujours d'un lien d'outillage solide entre les risques d'appsec et les risques commerciaux et pense que la prochaine grande opportunité d'innovation résidera probablement dans la façon dont les fournisseurs et les praticiens peuvent relier les plates-formes TPRM et la gestion plus large des risques de la chaîne d'approvisionnement (SCRM ) traite avec les données des SBOM et du pipeline CI/CD.

L'infrastructure sous-jacente utilisée pour tester et déployer le code est également le code lui-même et un élément fondamental de la chaîne d'approvisionnement. Par conséquent, les RSSI devraient envisager au minimum d'inclure des outils d'analyse et de sécurité de l'infrastructure en tant que code (IaC) dans le cadre de leur initiative plus large de sécurité de la chaîne d'approvisionnement. Ces outils ont tendance à chevaucher la ligne entre les outils de sécurité de la chaîne d'approvisionnement logicielle et les plates-formes de protection des applications natives du cloud (CNAPP), qui commencent sans doute à entrer dans la sécurité du cloud et le territoire des opérations de sécurité générales. Mais le CNAPP propose de nombreux autres supports de sécurité de la chaîne d'approvisionnement, notamment en ce qui concerne la visibilité des conteneurs et la sécurité d'exécution. Les conteneurs sont une cible d'attaque croissante dans la chaîne d'approvisionnement logicielle et les mesures de sécurité d'exécution peuvent fournir un filet de sécurité pour les charges de travail une fois qu'elles sont entrées en production.

Ensuite, lisez ceci