Lorsque trois agences gouvernementales américaines se réunissent pour « encourager fortement » les développeurs à adopter certaines pratiques, il faut y prêter attention. La CISA, la NSA et l'ODNI, conscientes de la menace des cyberpirates et à la suite de l'attaque de SolarWinds, ont annoncé qu'elles publieraient conjointement un ensemble de recommandations visant à sécuriser la chaîne d'approvisionnement des logiciels afin d'éviter de telles vulnérabilités à l'avenir. . L'annonce a clairement indiqué que le but du document est d'encourager les développeurs à adopter les meilleures pratiques, déclarant que «Ces principes incluent la planification des exigences de sécurité, la conception de l'architecture logicielle du point de vue de la sécurité, l'ajout de fonctionnalités de sécurité et le maintien de la sécurité des logiciels et de l'infrastructure sous-jacente."
Ces conseils sont organisés en trois parties et seront publiés en même temps que le cycle de vie de la chaîne d'approvisionnement logicielle. Partie 1 de la série, qui se concentre sur les recommandations destinées aux développeurs de logiciels, a été publié en août 2022. Les deux parties restantes seront publiées dans un avenir proche : la partie 2 se concentrera sur les fournisseurs de logiciels et la partie 3 se concentrera sur les clients recevant le logiciel. L'objectif ultime est que cette série contribue à favoriser la communication entre ces trois parties prenantes clés et entre les professionnels de la cybersécurité afin de faciliter une résilience accrue et d'améliorer globalement la sécurité. sécurité de la chaîne logistique logicielle.
Bien qu'il ne soit pas toujours clair à qui incombe la responsabilité d'assurer la sécurité des logiciels, quelle que soit la personne qui en assume la responsabilité globale dans votre organisation spécifique, cela nouveau guide indique très clairement que tous les développeurs doivent se familiariser avec ces nouvelles bonnes pratiques et qu'ils ont tous un rôle à jouer dans la sécurisation de la chaîne d'approvisionnement logicielle. Ou, si je peux être plus direct : Développeurs, vous jouez un rôle essentiel dans la sécurisation de la supply chain logicielle de votre organisation ! Et c’est pour cette raison que nous avons pensé qu’il pourrait vous être utile de lire un (relativement) court résumé de cette première partie du guide, rien que pour vous. Ça vient.
Le guide en quelques mots :
Parmi les longues listes de menaces potentielles évoquées dans ce guide pratique destiné aux développeurs, quelques vulnérabilités clés ont été identifiées et vous devez vous assurer de les traiter et de vous y préparer :
- Fonctionnalités qui n'ont pas été correctement documentées ou qui implémentent des fonctionnalités à risque
- Changements discrets dans les hypothèses de base en matière de sécurité entre le moment de l'évaluation de la sécurité et la livraison du code.
- Changements corporatifs pour les parties prenantes de la chaîne d’approvisionnement
- Pratiques de codage ou de sécurité inférieures aux normes
Les responsables de la direction, des finances et des programmes ont tous la responsabilité de veiller à la sécurité de la chaîne d'approvisionnement des logiciels, mais l'intégrité des sécurité de la chaîne logistique logicielle dépend souvent de la vigilance des développeurs de logiciels et de la sensibilisation de tous les acteurs de la chaîne d’approvisionnement. La première partie du guide se concentre sur le rôle des développeurs et les menaces inhérentes à chaque étape du processus de développement, et propose des recommandations sur les stratégies d'atténuation qui devraient devenir des pratiques standard.
Étape n°1 : Sécuriser les critères et la gestion des produits
Le développement sécurisé commence par la reconnaissance de l'importance de la sécurité de la chaîne d'approvisionnement logicielle par toutes les parties prenantes clés des équipes produit et de développement. Les scénarios de menace sont courants et peuvent être clairs pour tout le monde ; le défi est de mettre tout le monde sur la même longueur d’onde en ce qui concerne les politiques d’atténuation qui ont été décidées. Ces politiques doivent couvrir l'ensemble du processus : la conception et l'architecture, la modélisation des menaces, le codage, les plans de tests de sécurité, les critères de publication et la manière de gérer les vulnérabilités à l'avenir. Cela implique également d'évaluer les capacités des équipes et de s'assurer qu'elles ont été correctement formées pour leurs tâches, puis de définir des pratiques de documentation ainsi que des examens de sécurité et des évaluations périodiques des menaces.
Étape n°2 : Développement de code sécurisé
En matière de développement de code, les bonnes pratiques pour un codage sécurisé ont déjà été définies dans le SSDF. C'est la raison pour laquelle, dans la mesure où le langage de programmation n'a pas été prédéterminé, les considérations de sécurité devraient également faire partie de cette décision. Le guide fournit des conseils utiles pour les développeurs, traitant d'un large éventail de scénarios, tels que l'insertion de code source nuisible par des « initiés » (par exemple, des développeurs), les logiciels open source et les meilleures pratiques pour y faire face. Comment créer un environnement sécurisé pour le codage (y compris des configurations de construction sécurisées et des outils logiciels tiers) et ensuite tester la sécurité d'un produit intégré. Étant donné que des vulnérabilités sont également susceptibles d'apparaître après la livraison, il existe également des recommandations pour traiter les vulnérabilités signalées et garantir que les futures extensions logicielles externes ne compromettent pas l'intégrité de la sécurité du produit.
Étape n°3 : Renforcer l'environnement de construction
Une fois le code développé en toute sécurité, la sécurité de la chaîne d'approvisionnement logicielle nécessite que l'environnement de construction soit renforcé selon les mêmes normes que le logiciel lui-même. Compromettre le système de build est un moyen intéressant d’infiltrer le code, car cela intervient à une étape du processus de développement qui est naturellement moins scrutée par les développeurs.
Étape n°4 : Livraison du code
La dernière faiblesse abordée par le guide concerne la dernière étape de la chaîne d'approvisionnement logicielle : la livraison du code. Même lorsque le code a été correctement sécurisé jusqu’à présent, il existe encore deux vulnérabilités clés de la chaîne d’approvisionnement qui doivent être atténuées. La première est la validation finale du package, qui peut être exploitée, par exemple, en exposant par inadvertance des métadonnées, les informations d'identification du développeur ou l'inventaire open source. L'autre étape souvent recherchée pour détecter ses faiblesses est le système de distribution, qui pourrait être compromis par une attaque de l'homme du milieu qui pourrait prendre en charge une ou plusieurs étapes de la livraison.
En appliquant ces pratiques d’atténuation des risques au niveau du développement logiciel, les éditeurs de logiciels peuvent éviter les faiblesses qui peuvent conduire, par exemple, à l’infiltration de mises à jour, à la manipulation de signatures de code et aux « surprises » cachées dans le code open source.
Il n’y a pas de repas gratuit : le coût caché des logiciels tiers
Une clé contributeur à la vitesse des développeurs est devenue la possibilité d’incorporer efficacement des logiciels tiers. Cela a permis aux développeurs de se concentrer, par exemple, sur l'innovation ou la fonctionnalité, tout en utilisant des composants prêts à l'emploi pour l'évolutivité ou les interfaces. Cette utilisation accrue de logiciels tiers a créé un défi majeur pour la sécurité de la chaîne d’approvisionnement logicielle. En plus de procéder à une évaluation d'un tel code conformément aux mêmes normes que celles utilisées pour évaluer le vôtre, le guide suggère d'analyser les binaires à la recherche d'éventuelles vulnérabilités et d'évaluer les risques qui en résultent. Les résultats de cette évaluation doivent être pris en compte dans la décision d’utiliser ou non un composant logiciel spécifique. La sélection d'un composant logiciel doit également tenir compte de sa source ; l'intégration de composants tiers dans votre code source est le début d'une longue relation et vous devez vous efforcer de travailler avec des partenaires en qui vous pouvez avoir confiance. La propriété du code, les pratiques de codage et les politiques de gestion des versions ne sont que quelques points à prendre en compte lors de la sélection d'une source fiable. Pensez simplement à toutes les futures mises à jour, versions et travaux de maintenance pour chaque composant à mesure que de nouvelles menaces sont découvertes. Le défi consistera à surveiller tous les changements apportés par des tiers, à évaluer les vulnérabilités et à réagir en conséquence, parfois sous de fortes contraintes de temps.
Renforcez la sécurité de votre chaîne d'approvisionnement logicielle avec un SBOM
Une pratique clé pour garantir l’intégrité à long terme de votre chaîne d’approvisionnement logicielle consiste à maintenir à jour une Nomenclature du logiciel (SBOM). Le SBOM est un inventaire détaillé des composants logiciels qui composent une solution donnée.
Cela vous fera gagner du temps et des efforts et, surtout, réduira votre exposition aux menaces permanentes. Chaque composant logiciel incorporé à votre produit doit être accompagné de son propre SBOM, qui doit être validé et fusionné en un seul SBOM « maître » pour le produit. Si vous avez l'intention d'incorporer des composants qui ne sont pas fournis avec un SBOM, vous devrez effectuer votre propre analyse à l'aide des outils d'analyse de la composition logicielle (SCA).
Plus le SBOM est précis et descriptif, plus il est facile à maintenir et à référencer. Compte tenu de la vitesse vertigineuse à laquelle les composants logiciels sont mis à jour, un SBOM bien structuré rapportera des dividendes lorsqu'il sera temps de retrouver et d'enregistrer chaque mise à jour, correctif ou version. Plus important encore, une fois qu’une menace à la sécurité est découverte, chaque instant est critique. Rappelles toi: Les sécurité de votre supply chain logicielle sera toujours aussi fort que votre maillon le plus faible. Lorsque des dizaines de composants logiciels sont menacés, vous serez reconnaissant d'avoir un SBOM qui contient toutes les réponses.
Pour un flux de travail efficace, un SBOM utile doit au moins inclure ces trois composants :
- Champs de données – Ce sont les descripteurs des composants que vous avez implémentés. Être capable d'identifier facilement les composants qui ont été utilisés, même longtemps après la fin du développement, permet de surveiller efficacement leurs vulnérabilités.
- Prise en charge de l'automatisation – Le contrôle automatique des SBOM nécessite qu'ils soient également identifiés dans l'un des formats acceptés lisibles par machine.
- Pratiques et promesses – La gestion d'un SBOM nécessite une compréhension commune des pratiques de maintenance, telles que la fréquence des versions, les dépendances, les inconnues connues, la distribution et la livraison, le contrôle d'accès et la manière de gérer les erreurs.
Le partage du SBOM entre les parties prenantes d'un produit spécifique (le développeur de logiciels, le fournisseur de logiciels et le client) contribue à promouvoir la transparence et l'alignement, augmentant ainsi la capacité d'une chaîne d'approvisionnement logicielle à défendre le produit contre les menaces de sécurité. Il convient de noter que, compte tenu de toutes les pièces mobiles d’une chaîne d’approvisionnement logicielle, la maintenance cohérente d’un tel SBOM (qui peut être facilement référencé, surveillé et entretenu) constitue un défi complexe.
Derniers mots : comment pouvez-vous faire passer la sécurité de votre chaîne d'approvisionnement logicielle à un niveau supérieur ?
Alors que la sécurité de la chaîne d’approvisionnement logicielle devient de plus en plus cruciale, les organisations sont régulièrement mises au défi d’instaurer une confiance transparente dans les logiciels qu’elles fournissent ou utilisent. Étant donné que l’adoption du SBOM en tant que meilleure pratique devrait se développer, disposer d’un outil qui vous permet de surmonter ce défi est une étape clé vers l’établissement de la sécurité de la chaîne d’approvisionnement logicielle. C'est pourquoi nous avons récemment lancé le premier hub de sécurité basé sur des preuves pour les produits logiciels, permettant à ses utilisateurs de renforcer la confiance dans leur logiciel au sein des équipes et des organisations. Cette plate-forme conviviale aidera les équipes de développement à atténuer les risques liés à la chaîne d'approvisionnement logicielle en rendant le SBOM accessible, facile à utiliser et, surtout :rendre la sécurité des produits logiciels transparente pour les clients, les acheteurs et les équipes de sécurité.
Si vous, en tant que développeur de logiciels, êtes préoccupé par les menaces qui pèsent sur la sécurité de votre chaîne d'approvisionnement logicielle, nous vous invitons à essayez la plateforme; son utilisation est gratuite, sans aucune condition. En mettant en œuvre notre workflow, vous serez en mesure de partager vos SBOM tout au long de votre chaîne d'approvisionnement.
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
