Le gouvernement américain publie des conseils aux développeurs pour sécuriser la chaîne d’approvisionnement des logiciels : principaux points à retenir
Les attaques de la chaîne d’approvisionnement logicielle sont en augmentation, comme indiqué dans le catalogue des compromissions de la chaîne d’approvisionnement de la Cloud Native Computing Foundations (CNCF). Des leaders de l’industrie tels que Google, Linux Foundation, OpenSSF et des organisations du secteur public telles que le NIST ont fourni des conseils sur le sujet au cours de l’année écoulée.
La National Security Agency (NSA) des États-Unis, aux côtés de la Cybersecurity and Infrastructure Security Agency (CISA), et le Bureau du directeur du renseignement national (ODNI) rejoignent désormais cette liste avec leur publication Sécurisation de la chaîne d’approvisionnement logicielle : Guide des pratiques recommandées pour les développeurs. L’annonce de la publication met l’accent sur le rôle que jouent les développeurs dans la création de logiciels sécurisés et indique que le guide s’efforce d’aider les développeurs à adopter les recommandations du gouvernement et de l’industrie à cet égard. Les versions ultérieures de Enduring Security Framework (ESF) se concentreront sur le fournisseur et le consommateur de logiciels, étant donné le rôle unique que chacun joue dans la chaîne d’approvisionnement logicielle plus large et sa résilience.
À un niveau élevé, le document est organisé en trois parties :
- Partie 1 : conseils de sécurité pour les développeurs de logiciels
- Partie 2 : Considérations relatives aux fournisseurs de logiciels
- Partie 3 : recommandations des clients sur les logiciels
Le rôle des développeurs, des fournisseurs de logiciels et des clients
Le guide note le rôle unique que jouent les développeurs, les fournisseurs et les clients dans l’écosystème plus large de la chaîne d’approvisionnement des logiciels.
Département américain de la DéfenseRelations et activités du groupe de la chaîne d’approvisionnement des logiciels
Les fournisseurs de logiciels et leurs équipes de développement peuvent se retrouver dans la dichotomie de la rapidité de mise sur le marché, par rapport aux logiciels sécurisés et résilients ou aux produits logiciels.
Comme indiqué dans l’image ci-dessus, chacun des trois rôles a des activités de sécurité respectives qu’il peut et doit effectuer. Ces activités couvrent toute la gamme, depuis le développement initial du logiciel sécurisé, la composition et l’architecture jusqu’aux tests d’acceptation de la sécurité et à la validation de l’intégrité chez les clients.
Un logiciel sécurisé commence par un cycle de vie de développement logiciel sécurisé (SDLC) et les conseils citent de nombreuses options que les équipes peuvent utiliser, telles que le cadre de développement logiciel sécurisé (SSDF) du National Institute of Standards and Technology (NIST) des États-Unis.)les processus de cycle de vie du développement de logiciels sécurisés de l’université Carnegie Mellon, et d’autres, tels que les cours OpenSSF Secure Software Development Fundamentals récemment annoncés.
Département américain de la DéfenseProcessus de développement logiciel sécurisé
Comment développer un logiciel sécurisé
Les directives mettent l’accent non seulement sur l’utilisation de processus de développement de logiciels sécurisés, mais aussi sur la production d’artefacts et d’attestations tangibles qui sont utilisés pour la validation, à la fois par le producteur et le consommateur du logiciel, afin d’avoir des assurances liées à la sécurité et à la résilience du logiciel. Ces processus et activités incluent les meilleures pratiques telles que la modélisation des menaces, SAST, DAST et les tests d’intrusion, mais également l’utilisation d’activités de publication sécurisées telles que la signature numérique, un exemple notable étant l’adoption accrue de Sigstore., qui est une norme pour la signature, la vérification et la protection des logiciels. L’adoption et l’utilisation de Sigstore sont également citées dans le plan de mobilisation de la sécurité open source d’OpenSSF comme méthode pour renforcer la confiance dans la chaîne d’approvisionnement logicielle.
La modélisation des menaces obtient une mention importante, reconnaissant que pendant le développement et la livraison des produits, les équipes doivent examiner les scénarios de menace potentiels qui peuvent se produire et les contrôles qui pourraient être mis en place pour les atténuer. Les équipes doivent également avoir établi des plans de test de sécurité et des critères de préparation des versions associés pour s’assurer que des vulnérabilités inacceptables n’atteignent pas les environnements de production ou n’atteignent pas les clients.
Des équipes de produits matures ont également établi des politiques de support et de gestion des vulnérabilités. Cela inclut d’avoir un système où les vulnérabilités des produits peuvent être soumises et une équipe de réponse aux incidents associée qui est en mesure de répondre et de s’engager en cas d’incident. Compte tenu de l’impact que les développeurs peuvent avoir sur la production de produits sécurisés ou non, une évaluation et une formation formalisées doivent avoir lieu. Déterminez quelle formation est requise et qui doit la suivre à une fréquence précise. Le plan de mobilisation de la sécurité des logiciels open source d’OpenSSF répertorie la mise à niveau des compétences des développeurs sur le développement de logiciels sécurisés comme un objectif clé reconnu comme une nécessité à l’échelle de l’industrie. Les sujets de formation incluent le développement de logiciels sécurisés, les revues de code, les tests de vérification et l’utilisation d’outils d’évaluation des vulnérabilités pendant le développement pour réduire les vulnérabilités qui se retrouvent dans leurs produits finaux.
Les activités et pratiques décrites ci-dessus, telles que la formation au développement sécurisé, la modélisation des menaces, le plan de test de sécurité et les politiques et procédures de sécurité développées, sont mappées sur les activités du NIST SSDF mentionné précédemment, qui sera bientôt une exigence pour les éditeurs de logiciels d’auto-attestation. lors de la vente de produits logiciels au gouvernement fédéral américain.
Le développement de code sécurisé comporte de nombreux aspects, notamment la sélection de langages de programmation qui pourraient atténuer les vulnérabilités dès le début. Les organisations doivent également faire face aux menaces internes, qui peuvent être un ingénieur compromis ou simplement des ingénieurs mal formés. Les organisations peuvent atténuer ces menaces en codifiant les processus de contrôle des sources avec une authentification appropriée, en exécutant des tests statiques et dynamiques sur le code, ainsi qu’en recherchant les secrets exposés.
Les organisations doivent également mettre en œuvre des builds nocturnes et des tests de régression de sécurité pour reconnaître et corriger les failles et les vulnérabilités. Les efforts de développement ne doivent pas être ad hoc et doivent être mappés sur des exigences système spécifiques avec des tests de sécurité associés pour éviter le fluage des fonctionnalités qui peut introduire des risques.
Les revues de code doivent être prioritaires, en particulier le code critique pour s’assurer que les principes fondamentaux tels que la cryptographie sont en place et qu’il existe des exigences pour l’élévation des privilèges et la protection de l’accès aux ressources. Ce n’est pas seulement le code qu’il faut sécuriser mais aussi l’environnement de développement. Il y a eu des incidents notables tels que SolarWinds où l’environnement de développement peut être compromis et empoisonner les consommateurs en aval, de sorte que les systèmes, tels que les terminaux des développeurs, les référentiels de code source et les pipelines CI/CD, doivent être modélisés par les menaces et faire l’objet d’évaluations de vulnérabilité.
Les logiciels open source (OSS) présentent leur propre risque unique et les directives recommandent d’utiliser des systèmes dédiés pour télécharger, analyser et effectuer des vérifications récurrentes sur les composants OSS que les équipes de développement internes peuvent utiliser. Ce concept est également préconisé par le NIST dans son décret exécutif sur l’amélioration de la cybersécurité des Nations pour la section 4 et a été qualifié d’emballage continu.
Une autre pratique mise en avant est la sécurisation de l’environnement de développement, à l’aide de configurations de développement sécurisées et de chaînes d’outils et de bibliothèques de logiciels tiers sécurisés. Les systèmes de développement doivent être renforcés et utilisés uniquement à des fins de développement, sans accès à Internet et uniquement avec des outils et des logiciels pré-approuvés. Le guide recommande de vérifier les modules tiers pour les CVE par rapport à la base de données nationale sur les vulnérabilités (NVD) du NIST. Les outils et l’automatisation peuvent aider à faciliter ce processus et peuvent même être effectués dans le cadre de l’environnement de développement intégré (IDE) à l’aide d’analyseurs de dépendance de sécurité et d’outils similaires pour identifier les vulnérabilités.
Le renforcement de l’environnement de construction est essentiel, y compris le réseau de développeurs, le réseau d’entreprise et les environnements de construction internes. Cela atténue les menaces introduites à partir d’Internet et d’acteurs malveillants externes, ainsi que des mesures d’intégrité et de validation pour valider que des activités malveillantes n’ont pas eu lieu pour compromettre les produits.
Département américain de la DéfenseEnvironnement de construction sécurisé
Les composants logiciels doivent provenir de fournisseurs de confiance connus qui répondent aux exigences organisationnelles et validés par des méthodes telles que les formats SPDX ou CycloneDX SBOM, ainsi que la réactivité des fournisseurs aux vulnérabilités avec des méthodes établies pour le signalement des vulnérabilités.
Les conseils de sécurisation des chaînes d’approvisionnement logicielles vont au-delà du renforcement de l’environnement de construction pour formuler des recommandations telles que l’utilisation de versions reproductibles hermétiques également. Cela signifie des étapes de construction entièrement déclarées, des références immuables et aucun accès au réseau, ainsi que des sorties et des artefacts identiques, quels que soient les changements de métadonnées variables apportés à des éléments tels que les horodatages.
Les logiciels doivent être livrés en toute sécurité, y compris un SBOM de composition finale aux clients. Dans le cadre de la validation du package, les clients peuvent utiliser des sorties d’analyse binaire pour s’assurer que seuls les composants logiciels prévus sont en place. Pour résoudre les compromis des packages logiciels et des mises à jour, le produit et les composants peuvent utiliser des hachages et des signatures numériques pour la distribution des produits, les composants et les mises à niveau. Les organisations doivent également prendre des mesures pour atténuer les compromis du système de distribution lui-même. Cela peut inclure l’application de mesures de sécurité aux référentiels et aux gestionnaires de packages, ainsi que l’utilisation de mécanismes de couche de transport sécurisés.
Autres ressources pour sécuriser la chaîne d’approvisionnement logicielle
Les conseils comprennent un tableau de concordance entre divers scénarios avec des développeurs, des fournisseurs et des clients et des pratiques spécifiques décrites dans SSDF. Il comprend également une cartographie des dépendances et des artefacts qui existent entre le fournisseur, les fournisseurs tiers et le client final.
Une mise en correspondance avec le cadre SLSA montre comment les recommandations spécifiques du guide correspondent aux différents niveaux de SLSA, allant de L1 à L4. Enfin, il existe une liste complète d’artefacts et de listes de contrôle à utiliser tout au long du SDLC et une liste de références informatives telles que le cyber-ordre exécutif, la documentation du DoD et du NIST ainsi que des organisations industrielles telles que l’OWASP.
Ce guide sécurisé de la chaîne d’approvisionnement en logiciels est une ressource essentielle qui sera sans aucun doute adoptée par l’industrie comme référence incontournable pour les organisations qui cherchent à renforcer leurs pratiques en matière de chaîne d’approvisionnement en logiciels, tant pour les producteurs de logiciels que pour les consommateurs. Ce document étant centré sur le développeur, l’industrie serait bien avisée de rechercher les directives suivantes, qui se concentreront sur les fournisseurs de logiciels et les consommateurs.
Copyright © 2022 IDG Communications, Inc.