Understanding the software supply chain security requirements in the cybersecurity Executive Order

Le décret du président Biden sur la cybersécurité du mois dernier ne devrait pas surprendre ceux qui ont suivi les actualités de l’année passée. Le décret est la réponse importante du gouvernement fédéral des États-Unis à une longue liste d’incidents, en commençant par l’attaque de SolarWinds et en terminant par une récente attaque par ransomware à l’encontre de Colonial Pipeline - plus importante attaque connue à l’encontre d’une entreprise d’énergie américaine.

Bon nombre des attaques récentes étant liées à la chaîne d’approvisionnement logicielle, il n’est pas surprenant que la sécurité des logiciels, et plus particulièrement celle de la chaîne d’approvisionnement logicielle, soit un thème récurrent du décret. L’attaque désormais célèbre de SolarWinds a touché une longue liste d’agences gouvernementales, dont le Pentagone, le Département d’État, le Département de la sécurité intérieure, ainsi que des organisations privées telles que Microsoft, Intel et Cisco, ont été touchés par cette attaque qui a mis en lumière le problème de la sécurité de la chaîne d’approvisionnement logicielle.

Les attaques envers la chaîne d’approvisionnement logicielle ne sont pas nouvelles. Chez Snyk, nous parlons du développement et de la composition des logiciels modernes comme d’un maillon faible et d’un canal potentiel de distribution de logiciels malveillants depuis 2018. Mais ils deviennent de plus en plus populaires parmi les attaquants en raison de certains changements notables dans la manière dont les applications logicielles sont construites aujourd’hui. Le décret du président Biden reconnaît ces changements et vise à minimiser le risque qu’ils posent en demandant au ministère du commerce de créer des normes strictes pour les entreprises qui vendent des logiciels au gouvernement fédéral.  

Qu’est-ce qu’une attaque de la chaîne d’approvisionnement logicielle ?

Lors d’une attaque de la chaîne d’approvisionnement des logiciels, les attaquants accèdent aux logiciels et les modifient dans la chaîne d’approvisionnement complexe du développement de logiciels, dans le but de compromettre une cible en aval en y insérant du code malveillant. L’attaque de la chaîne d’approvisionnement logicielle ne constitue pas l’objectif final. Elle sert à ouvrir une fenêtre d’opportunité permettant à un attaquant d’insérer des logiciels malveillants ou de fournir un accès dérobé pour accès ultérieur. Dans l’attaque de SolarWinds, par exemple, les pirates ont réussi à accéder à la plateforme de surveillance des réseaux et des applications de SolarWinds, Orion, pour distribuer des mises à jour malveillantes aux milliers d’utilisateurs du logiciel.

Les attaques de la chaîne d’approvisionnement logicielle constituent un vecteur d’attaque redoutablement efficace en raison de la manière dont les logiciels modernes sont construits. À l’instar des chaînes d’approvisionnement industrielles, la chaîne d’approvisionnement logicielle comprend la planification, l’approvisionnement en matériaux, la fabrication et la vente au détail. Au lieu de matériaux, la chaîne d’approvisionnement logicielle repose sur du code. Bien que ce code puisse être propriétaire, une part croissante provient de plus en plus souvent de fournisseurs, commerciaux ou open source. Ces dépendances peuvent être utilisées pour insérer du code malveillant dans le logiciel. Le code est utilisé pour développer des logiciels et, dans la chaîne d’approvisionnement moderne, le développement implique un nombre toujours croissant de processus susceptibles d’être exploités pour la distribution efficace de logiciels malveillants.

Exigences fédérales relatives à la sécurité de la chaîne d’approvisionnement logicielle

Le décret du président Biden appelle à moderniser la cybersécurité du gouvernement fédéral, à améliorer la communication et la collaboration en matière de cybersécurité entre le gouvernement fédéral et le secteur privé, et à renforcer la sécurité des logiciels achetés par le gouvernement fédéral. Le risque posé par les attaques de la chaîne d’approvisionnement des logiciels est clairement énoncé au début de la section 4 du décret :

Le développement de logiciels commerciaux manque souvent de transparence, d’une attention suffisante à la capacité du logiciel à résister aux attaques et de contrôles adéquats pour prévenir les manipulations par des acteurs malveillants. Il est urgent de mettre en œuvre des mécanismes plus rigoureux et plus prévisibles pour s’assurer que les produits fonctionnent en toute sécurité et comme prévu... En conséquence, le gouvernement fédéral doit prendre des mesures pour améliorer rapidement la sécurité et l’intégrité de la chaîne d’approvisionnement logicielle...

Afin de protéger les agences gouvernementales de ce risque, le décret demande au NIST de mettre en place les meilleures pratiques, les directives et les critères requis pour les futures normes auxquelles les fournisseurs de logiciels devront se conformer pour pouvoir vendre des logiciels au gouvernement fédéral.

Nomenclature des logiciels (SBOM)

Si une petite partie du code qui constitue les logiciels est développée en interne à partir de zéro, la plus grande partie est issue de composants open source ou de composants tiers. L’exigence d’une nomenclature des logiciels (SBOM) dans le décret reconnaît ce fait, soulignant la nécessité d’une plus grande transparence quant à ce qui est exactement inclus dans un logiciel afin de pouvoir atténuer le risque d’attaques de la chaîne d’approvisionnement logicielle.  

Environnement de développement sécurisé

Les fournisseurs de logiciels devront attester de l’existence d’un environnement de développement sécurisé. Le décret demande au NIST de formuler des critères selon lesquels un environnement de développement serait considéré comme sûr, notamment des processus de développement sécurisés, le chiffrement des données, l’audit, l’authentification, ainsi que la surveillance et la gestion des incidents.

Processus de développement sécurisé

Les fournisseurs de logiciels devront également adhérer à des pratiques de développement sécurisées et être en mesure d’attester des mesures prises. Il s’agit notamment d’utiliser des tests de sécurité automatisés dès le début et pendant le développement pour garantir l’intégrité du code, et détecter et corriger les vulnérabilités. Les « artefacts » attestant du développement des logiciels et de l’exécution des outils et processus utilisés doivent être disponibles sur demande.

Intégrité des logiciels open source

Généralement, 80 à 90 % du code composant une application est un code open source. Reconnaissant cette réalité, le décret exige des fournisseurs de logiciels qu’ils « garantissent et attestent de l’intégrité et de la provenance des logiciels open source utilisés dans toute partie d’un produit ».

Améliorer la sécurité de la chaîne d’approvisionnement logicielle

Se préparer aux directives NIST en renforçant votre chaîne d’approvisionnement logicielle commence par une sécurité des applications plus stricte. En fournissant une sécurité des applications natives du cloud au service des développeurs, Snyk prend en charge la grande majorité des exigences énoncées dans le décret.

Responsabiliser les développeurs

La mise en œuvre réussie des pratiques de développement sécurisé demandées dans le décret dépend de la capacité des développeurs à intégrer facilement la sécurité dans leur workflow de développement. Le développement sécurisé commence avec les développeurs eux-mêmes. Ce sont eux qui décident de la manière de construire leurs applications et qui, en fin de compte, assument la responsabilité de l’intégrité, de la qualité et de la sécurité de leur code. Les modèles de sécurité traditionnels, qui s’intègrent tardivement dans le processus de développement et ajoutent des frictions avec des workflows non intuitifs, ne sont plus une option dans un contexte de développement rapide.

L’approche de Snyk consiste à donner aux développeurs les moyens d’agir grâce à des outils conviviaux et à des conseils appropriés prodigués par l’équipe de sécurité. La plateforme Snyk a été conçue pour fournir aux développeurs un outil dont ils apprécient réellement l’utilisation, un outil qui se comporte et ressemble à n’importe quel autre outil de développement de leur boîte à outils et ne les ralentit pas.

Sécurité automatisée tout au long du cycle du développement logiciel

Pour garantir l’intégrité des logiciels dès le début du processus de développement, le décret appelle à une mise en œuvre précoce de tests de sécurité automatisés, « ...qui doivent être effectués régulièrement, ou au minimum avant la sortie du produit, de la version ou de la mise à jour ». Les clients de Snyk utilisent une variété d’intégrations disponibles, ainsi que l’API Snyk, pour automatiser les tests de sécurité tout au long des différentes étapes du processus de développement logiciel. Cela commence dès l’environnement de développement local du développeur, se poursuit à travers les workflows basés sur Git, le processus de build, et se termine par l’environnement de production. 

Sécuriser TOUT le code qui compose les logiciels modernes

Le décret reconnaît que le code qui compose une application a changé. Le code propriétaire, les paquets open source, les conteneurs et le code responsable de l’approvisionnement de l’infrastructure cloud (infrastructure en tant que code) sont les matériaux utilisés dans la chaîne d’approvisionnement logicielle moderne.

Pour permettre aux organisations de gérer et d’atténuer ce nouveau profil de risque, une approche plus holistique de la sécurité des applications est nécessaire. Les équipes de sécurité qui se concentrent sur les outils de tests de sécurité des applications statiques (SAST) pour sécuriser le code écrit par leurs équipes de développement ignorent le risque introduit par l’open source et l’utilisation de conteneurs, et vice versa - les outils d’analyse de la composition des logiciels (SCA) ne fournissent pas de couverture pour le code propriétaire. La plateforme de Snyk fournit une solution complète au service des développeurs, qui aide les organisations à sécuriser l’ensemble du code composant les logiciels modernes.

Attestation et rapports au niveau des composants

Comme décrit ci-avant, la transparence vis-à-vis du gouvernement fédéral sur les processus et mesures mis en place, ainsi que les matériaux utilisés pour construire le logiciel sous la forme d’une nomenclature des logiciels, jouent un rôle déterminant dans les exigences stipulées dans le décret. Snyk fournit des capacités de rapport étendues pour permettre la visualisation et l’exportation d’une nomenclature des logiciels, ainsi que d’autres types de rapports. Les clients de Snyk peuvent également utiliser l’API Snyk pour l’intégration automatique dans des outils tiers de rapport et de gestion des vulnérabilités afin de surveiller en continu la posture de l’organisation en matière de sécurité et de conformité.

Perspectives d’avenir

Le décret demande au NIST de publier des directives préliminaires dans un délai de six mois et des directives définitives dans un délai d’un an.  Bien que les exigences du décret s’adressent aux entreprises qui vendent au gouvernement fédéral, on peut s’attendre à ce que les normes aient des répercussions dans le secteur privé et affectent à l’avenir le marché des logiciels dans son ensemble.

Il serait donc prudent de commencer à planifier en examinant dans le détail les dispositions du décret et en identifiant les principales lacunes de votre chaîne d’approvisionnement logicielle existante.

Chez Snyk, nous suivrons l’évolution des directives à mesure de leur introduction par le NIST, et nous fournirons des informations supplémentaires sur notre blog, alors restez à l’écoute. Nous participons également activement aux efforts du NIST pour se conformer au décret, en particulier en ce qui concerne les spécifications de nomenclature des logiciels via le SBOM SIG.

Pour en savoir plus sur la façon dont Snyk aide les agences gouvernementales à répondre aux exigences de ce décret, contactez-nous à l’adresse snyk_federal@snyk.io ou visitez notre page web Snyk pour le secteur public.