3 conseils pour assurer la sécurité de la chaine d'approvisionnement

Temps de lecture : 5 minutes.

À une époque où "l'attaque de la chaîne d'approvisionnement logicielle" est devenue une expression courante, la récente vulnérabilité découverte dans Apache Log4J a sonné l'alarme tant pour les développeurs que pour les consommateurs de logiciels : l'époque où l'on faisait aveuglément confiance aux logiciels tiers est révolue.

La vulnérabilité de Log4J, qui est utilisée dans des applications allant de Minecraft aux serveurs d'infrastructure exécutant les services Web iCloud et Amazon d'Apple, permet aux attaquants de prendre le contrôle des appareils exécutant certaines versions de cet utilitaire de journalisation. Il s'agit de la dernière d'une série d'attaques de la chaîne d'approvisionnement logicielle, notamment SolarWinds, REvil et Urgent/11.

Face à ces menaces de sécurité, les développeurs sont continuellement pressés de fournir des applications avec rapidité et efficacité, ce qui conduit à une utilisation accrue de code tiers et de bibliothèques open source telles que Log4J. Pour éviter de sacrifier la sécurité, les organisations s'appuient de plus en plus sur des technologies capables de générer une nomenclature logicielle (SBOM) qui répertorie le contenu d'une application logicielle et toutes les vulnérabilités associées qu'elle contient.

Comme toute nomenclature dans l'entreprise, le SBOM définit les composants du produit fini, donc si un problème est détecté, la cause première peut être corrigée tout en minimisant les perturbations. Les SBOM sont reconnus comme le fondement de la sécurité de la chaîne d'approvisionnement logicielle ; ils permettent aux développeurs de créer des applications plus sécurisées, de fournir aux équipes de sécurité des renseignements sur les menaces et aux services informatiques de maintenir des environnements plus résilients.

Les SBOM fournissent des informations précieuses à trois étapes différentes du cycle de vie du développement logiciel (SDLC) - en développement, en livraison et en déploiement, comme décrit ci-dessous.

Créer des programmes à partir de zéro est coûteux, prend du temps et tout simplement peu pratique pour les organisations qui doivent évoluer à la vitesse des affaires et avec un budget limité. Au cours des cinq dernières années, l'utilisation de code développé en interne pour les projets IoT a diminué de 50 % et il n'y a aucune raison de penser qu'elle ne continuera pas à baisser.

Les développeurs doivent utiliser des composants tiers et open source pour suivre le rythme, et bien que l'intégration des tests de composants dans le flux de travail soit une bonne pratique, les développeurs font souvent confiance. La génération d'un SBOM au cours de cette étape donne aux équipes de développement plus de visibilité sur ces composants, afin qu'elles puissent repérer toutes les vulnérabilités connues (N-day) ou Zero-day qui pourraient se cacher, et s'assurer qu'elles utilisent des versions sous licence et mises à jour du programme.

L'analyse régulière des composants et la génération de SBOM peuvent donner aux équipes de développement la certitude qu'elles respectent les normes de qualité et de sécurité, tout en leur permettant de gérer de manière proactive leurs bibliothèques de composants.

La flambée de la cybercriminalité observée lors de la pandémie de Covid a mis en lumière la sécurité, les équipes de développement de logiciels et les fournisseurs sont donc sous pression pour fournir des produits qui répondent à des normes plus strictes. Trop de logiciels utilisés aujourd'hui pourraient être la proie de vulnérabilités inconnues qui se cachent dans leur code tiers, de sorte que les nouveaux produits doivent être soigneusement vérifiés pour répondre aux normes d'assurance qualité. Lorsque Osterman Research a analysé les logiciels commerciaux prêts à l'emploi, il a découvert que tous les programmes avaient des composants et des vulnérabilités open-source ; 85 % présentaient des vulnérabilités critiques dans leurs composants open source.

Avant la publication et le déploiement, le logiciel compilé doit être soumis à un contrôle d'assurance de sécurité pour produire un SBOM. À ce stade, l'analyse peut identifier l'utilisation de l'open source et vérifier les vulnérabilités qui doivent être corrigées ou atténuées. Il s'agit d'une étape clé pour s'assurer que les logiciels mis sur le marché sont aussi sécurisés que possible et exempts de vulnérabilités connues, et ce n'est qu'une question de temps avant que ce ne soit une exigence générale.

Le  décret présidentiel sur la cybersécurité de 2021 publié en réponse aux récentes cyberattaques de la chaîne d'approvisionnement a désigné les SBOM comme un outil de cybersécurité efficace. L'ordonnance stipule qu'en fin de compte, les SBOM pour les éditeurs de logiciels travaillant avec le gouvernement fédéral devront être inclus dans les lignes directrices sur les meilleures pratiques qu'il recommanderait à toutes les entreprises, via l'Institut national des normes et de la technologie du Département du commerce. Pendant ce temps, un certain nombre d'industries ont commencé à exiger des SBOM lors de la livraison de produits critiques tels que des dispositifs médicaux et des contrôles d'infrastructure.

Avec tout, des imprimantes de bureau aux systèmes critiques désormais connectés via l'Internet des objets (IoT), il existe une surface d'attaque beaucoup plus grande pour trouver et exploiter les vulnérabilités. À mesure que de plus en plus de processus sont numérisés, les entreprises consacrent des budgets croissants aux logiciels nécessaires à leur exécution ; Gartner prévoit que les dépenses en logiciels d'entreprise atteindront près de 670 milliards de dollars en 2022, en hausse de 11,5 % par an.

Les développeurs et les fournisseurs de logiciels améliorent les pratiques de fourniture de logiciels sécurisés, mais les équipes de cybersécurité des entreprises sont responsables en dernier ressort de la sécurité des logiciels commerciaux déployés. Ils doivent faire confiance, mais vérifier et générer leurs propres SBOM.

En analysant les logiciels achetés, les équipes de sécurité de l'information peuvent obtenir une visibilité sur les logiciels que leur organisation utilise déjà ou envisage d'utiliser. Cela peut les aider à améliorer leur posture de sécurité, à prendre des décisions plus intelligentes et à accélérer la réponse aux menaces si une autre vulnérabilité telle que Log4j apparaît.

Heureusement, la création de SBOM est à la portée de pratiquement toutes les organisations grâce à la technologie d'analyse de composition logicielle (SCA). Ces outils peuvent générer un SBOM via le code source ou l'analyse binaire. Les outils SCA binaires analysent le code compilé, le logiciel fini réel qui est livré et déployé par les organisations. Cela leur donne un avantage car ils peuvent fonctionner sans accès au code source et analyser les composants logiciels, les bibliothèques et les packages dans les applications pour générer un SBOM.

Avec la fréquence et la sophistication croissantes des attaques de la chaîne d'approvisionnement, la valeur qu'apportent les SBOM ne peut être sous-estimée lorsqu'il s'agit d'identifier et d'atténuer les risques de sécurité dans les logiciels que les organisations développent, fournissent ou déploient.