Une raison l’open source est populaire dans l’entreprise est qu’il fournit des éléments de base éprouvés qui peuvent accélérer la création d’applications et de services sophistiqués. Mais les composants logiciels tiers et la commodité des packages et des conteneurs présentent des risques ainsi que des avantages, car les applications que vous créez ne sont aussi sécurisées que ces dépendances.
Les attaques de la chaîne d’approvisionnement logicielle sont de plus en plus répandues que Gartner les a classées parmi les deuxième plus grande menace pour 2022. D’ici 2025, la société de recherche prédit que 45 % des organisations dans le monde auront subi une ou plusieurs attaques de la chaîne d’approvisionnement logicielle – et 82% des DSI pensent ils y seront vulnérables. Il s’agit notamment d’attaques via des vulnérabilités dans des composants logiciels largement utilisés tels que Log4j, des attaques contre le pipeline de construction (cf, hacks SolarWinds, Kaseya et Codecov), ou les pirates compromettent eux-mêmes les dépôts de paquets.
“Les attaquants ont déplacé la priorité des environnements de production vers les chaînes d’approvisionnement en logiciels, car les chaînes d’approvisionnement en logiciels sont le maillon le plus faible”, explique Lior Levy, PDG de Cycode. “Tant que les chaînes d’approvisionnement en logiciels resteront des cibles relativement faciles, les attaques de la chaîne d’approvisionnement en logiciels augmenteront.”
Les récents incidents très médiatisés ont été un signal d’alarme pour l’industrie du développement de logiciels, déclare Rani Osnat, vice-président senior de la stratégie chez Aqua Security. “Nous avons découvert des décennies d’opacité et de manque de transparence et c’est pourquoi c’est si grave.”
Des études de bases de code utilisant du code open source montrent que les vulnérabilités et les composants obsolètes ou abandonnés sont courants : 81% des bases de code avaient au moins une vulnérabilité, 50 % avaient plus d’une vulnérabilité à haut risqueet 88 % utilisaient des composants qui n’étaient pas à la dernière version ou qui n’avaient fait l’objet d’aucun développement depuis deux ans.
Il est peu probable que ces problèmes nuisent à la popularité de l’open source – et les logiciels et services commerciaux sont également vulnérables. Lorsque LastPass a été attaqué, il n’a pas perdu de données client, mais une partie non autorisée a pu afficher et télécharger une partie de son code source, ce qui pourrait faciliter l’attaque des utilisateurs du gestionnaire de mots de passe à l’avenir, et la violation de Twilio a permis aux attaquants pour lancer des attaques de la chaîne d’approvisionnement sur les organisations en aval.
La menace du “code fantôme”
Tout comme les équipes de sécurité défendent leurs réseaux comme s’ils étaient déjà piratés, les DSI doivent supposer que tout le code, interne ou externe, et même les environnements et outils de développement que leurs développeurs utilisent ont déjà été compromis et mettre en place des politiques pour se protéger et minimiser l’impact des attaques. contre leurs chaînes d’approvisionnement en logiciels.
En fait, Osnat suggère aux DSI de penser à ce “code fantôme” comme ils le font avec le shadow IT. “Cela doit être considéré comme quelque chose qui n’est pas seulement un problème de sécurité, mais vraiment quelque chose qui va profondément dans la façon dont vous obtenez un logiciel, qu’il soit open source ou commercial : comment vous l’introduisez dans votre environnement, comment vous le mettez à jour, le type de contrôles que vous souhaitez mettre en place et le type de contrôles que vous souhaitez exiger de vos fournisseurs », dit-il.
Transparence : vers une nomenclature logicielle
Les chaînes d’approvisionnement physiques utilisent déjà des étiquettes, des listes d’ingrédients, des fiches de données de sécurité et des nomenclatures afin que les régulateurs et les consommateurs sachent ce qui se retrouve dans les produits. De nouvelles initiatives visent à appliquer des approches similaires aux logiciels, en aidant les organisations à comprendre le réseau de dépendances et la surface d’attaque de leur processus de développement logiciel.
maison Blanche décret 14028 sur la sécurité de la chaîne d’approvisionnement des logiciels oblige les fournisseurs de logiciels qui fournissent le gouvernement fédéral à fournir une nomenclature des logiciels (SBOM) et à utiliser le niveaux de la chaîne d’approvisionnement pour les artefacts logiciels (SLSA) liste de contrôle de sécurité pour empêcher la falsification. Pour cette raison, « nous constatons que de nombreuses entreprises examinent de plus près leur chaîne d’approvisionnement logicielle », déclare Janet Worthington, analyste senior chez Forrester. “Aujourd’hui, toutes les entreprises produisent et consomment des logiciels et nous voyons de plus en plus de producteurs venir nous voir et nous dire : ‘Comment puis-je produire des logiciels sécurisés et dont je peux attester avec une nomenclature logicielle.'”
Il existe de nombreux projets intersectoriels, notamment l’initiative nationale du NIST pour l’amélioration de la cybersécurité dans les chaînes d’approvisionnement (NIICS), l’intégrité, la transparence et la confiance de la chaîne d’approvisionnement (SCITT) initiative de Microsoft et d’autres membres de l’IETF, ainsi que de l’OpenSSF Groupe de travail sur l’intégrité de la chaîne d’approvisionnement.
“Tout le monde adopte une approche plus holistique et dit, attendez une minute, j’ai besoin de savoir ce que j’apporte dans ma chaîne d’approvisionnement avec lequel je crée le logiciel”, déclare Worthington.
Une récente Sondage de la Fondation Linux ont constaté que la sensibilisation aux SBOM est élevée, avec 47 % des fournisseurs informatiques, des fournisseurs de services et des industries réglementées utilisant les SBOM aujourd’hui et 88 % prévoyant de les utiliser en 2023.
Les SBOM seront particulièrement utiles aux organisations qui disposent déjà d’une gestion des actifs pour les composants logiciels et les API. “Les personnes qui disposent aujourd’hui de processus de développement de logiciels robustes trouvent plus facile d’insérer des outils capables de générer une nomenclature logicielle”, déclare Worthington.
Les SBOM peuvent être créés par le système de construction, ou ils peuvent être générés par des outils d’analyse de composition logicielle après coup. De nombreux outils peuvent s’intégrer dans les pipelines CI/CD et s’exécuter dans le cadre d’une construction, ou même lorsque vous extrayez des bibliothèques, dit-elle. “Il peut vous avertir : ‘Hé, vous avez ce composant dans votre pipeline et il y a un problème critique, voulez-vous continuer ?'”
Pour que cela soit utile, vous avez besoin de politiques claires sur la manière dont les équipes de développeurs acquièrent des logiciels open source, déclare Dan Lorenc, PDG de Chainguard. “Comment les développeurs savent-ils quelles sont les politiques de leur entreprise pour ce qui est considéré comme “sécurisé” et comment savent-ils que l’open source qu’ils acquièrent, qui constitue la grande majorité de tous les logiciels utilisés par les développeurs de nos jours, est en effet inaltéré ?”
Il pointe du doigt le projet open source Sigstore que JavaScript, Java, Kubernetes et Python utilisent pour établir la provenance des packages logiciels. « Sigstore est à l’intégrité du logiciel ce que les certificats sont aux sites Web ; ils établissent essentiellement une chaîne de contrôle et un système de vérification de la confiance », dit-il.
“Je pense qu’un CIO devrait commencer par endoctriner ses équipes de développeurs dans ces étapes fondamentales d’utilisation des approches standard émergentes de l’industrie pour un, verrouiller les systèmes de construction, et deux, créer une méthode reproductible pour vérifier la fiabilité des artefacts logiciels avant de les intégrer dans l’environnement, », dit Lorenc.
Faire la contribution
Qu’il s’agisse de composants, d’API ou de fonctions sans serveur, la plupart des organisations sous-estiment ce qu’elles utilisent d’un ordre de grandeur à moins qu’elles n’exécutent des inventaires de routine, souligne Worthington. “Ils découvrent que certaines de ces API n’utilisent pas les méthodes d’authentification appropriées ou ne sont peut-être pas écrites de la manière à laquelle ils s’attendaient et peut-être que certaines d’entre elles sont même obsolètes”, dit-elle.
Au-delà des vulnérabilités, évaluer le support de la communauté derrière un paquet est aussi important que de comprendre ce que fait le code car tous les mainteneurs ne veulent pas le fardeau de voir leur code traité comme une ressource critique. “Tous les open source ne sont pas créés de la même manière”, prévient-elle.
“L’open source peut être téléchargé gratuitement, mais son utilisation n’est certainement pas gratuite. Votre utilisation signifie que vous êtes responsable de la compréhension de la posture de sécurité qui la sous-tend, car elle fait partie de votre chaîne d’approvisionnement. Vous devez y contribuer. Vos développeurs doivent participer à la correction des vulnérabilités », déclare Worthington, qui suggère que les organisations doivent également être prêtes à contribuer financièrement, soit directement à des projets open source, soit à des initiatives qui les soutiennent avec des ressources et des fonds. “Lorsque vous créez une stratégie open source, une partie de cela consiste à comprendre le budget et les implications.”
Ne considérez pas cela comme une simple dépense, mais comme une opportunité de mieux comprendre les composants dont vous dépendez. « Cela aide même à retenir les développeurs parce qu’ils ont l’impression de faire partie de la communauté. Ils peuvent apporter leurs compétences. Ils peuvent l’utiliser sur leur CV », ajoute-t-elle.
N’oubliez pas que les vulnérabilités peuvent être trouvées n’importe où dans votre pile technologique, y compris les mainframes, qui exécutent de plus en plus Linux et open source dans le cadre de la charge de travail, mais manquent souvent des processus et des cadres de sécurité qui sont devenus courants dans d’autres environnements.
Protéger votre pipeline
La protection de votre pipeline de livraison de logiciels est également importante. Le cadre de développement logiciel sécurisé (SSDF) et le SLSA du NIST sont un bon point de départ : ils couvrent les meilleures pratiques à différents niveaux de maturité, en commençant par un système de construction simple, puis en utilisant des journaux et des métadonnées pour l’audit et la réponse aux incidents jusqu’à un pipeline de construction entièrement sécurisé. . La CNCF Meilleures pratiques de la chaîne d’approvisionnement des logiciels papier blanc, Conseils de Gartner sur l’atténuation des risques de sécurité de la chaîne d’approvisionnement des logicielset Microsoft Cadre de chaîne d’approvisionnement sécurisée OSSqui comprend à la fois des processus et des outils, sont également utiles.
Il est important de noter, cependant, que le simple fait d’activer des outils d’analyse automatisés destinés à trouver du code malveillant peut produire trop de faux positifs être utile. Et bien que les systèmes de contrôle de version tels que BitBucket, GitHub, GitLab et autres incluent des fonctionnalités de sécurité et de protection d’accès (y compris de plus en plus granulaire contrôles de politique d’accès, protection de branche, signature de code, exigence de MFA pour tous les contributeurs et recherche de secrets et d’informations d’identification), ils doivent souvent être explicitement activés.
En outre, des projets tels que Factory for Repeatable Secure Creation of Artifacts (FRSCA) qui visent à sécuriser les pipelines de build en implémentant SLSA dans une pile unique ne sont pas encore prêts pour la production, mais les DSI doivent s’attendre à ce que les systèmes de build incluent davantage de ces pratiques à l’avenir.
En effet, si les SBOM ne sont qu’une partie de la réponse, les outils pour les créer et les utiliser sont également encore en cours de maturation, tout comme les processus pour les demander et les consommer. Les contrats doivent spécifier non seulement que vous voulez des SBOM, mais à quelle fréquence vous vous attendez à ce qu’ils soient mis à jour et s’ils incluront des rapports de vulnérabilité et des notifications, conseille Worthington. “Si une nouvelle vulnérabilité importante comme Log4j est découverte, est-ce que le fournisseur va me le dire ou est-ce que je vais devoir chercher moi-même dans le SBOM pour voir si je suis concerné ?”
Les organisations auront également besoin d’outils pour lire les SBOM et mettre en place des processus pour agir sur ce que ces outils trouvent. “J’ai besoin d’un outil qui puisse me dire quelles sont les vulnérabilités connues [in the SBOM]quelles sont les implications de la licence et est-ce que cela se produit en permanence », déclare Worthington.
Les DSI doivent garder à l’esprit qu’un SBOM « est un facilitateur, mais qu’il ne résout en fait rien en termes de sécurisation de votre chaîne d’approvisionnement. Cela vous aide à faire face aux incidents qui pourraient survenir », déclare Osnat, qui est optimiste quant à la rapidité de la réponse de l’industrie et à la large collaboration qui se déroule autour des normes pour les SBOM et de l’attestation de code qui contribuera à rendre les outils interopérables (quelque chose que les organisations ont soulevé comme une préoccupation particulière dans la recherche de la Linux Foundation). Cela pourrait conduire aux mêmes améliorations des normes de transparence et de reporting dans l’ensemble de l’industrie que celles fournies par SOC 2.
Cela dit, les DSI n’ont pas besoin d’attendre de nouvelles normes ou de nouveaux outils pour commencer à faire de la sécurité autant une partie du rôle du développeur que la qualité l’est devenue ces dernières années, explique Osnat. Sa suggestion : “Commencez par réunir votre CISO et votre ingénieur principal dans une pièce pour déterminer quel est le bon modèle pour que cela fonctionne pour votre organisation et comment cette transformation se produira.”
