Comprendre les exigences de sécurité de la chaîne logistique logicielle du décret présidentiel sur la cybersécurité

Le décret présidentiel sur la cybersécurité publié le mois dernier par Joe Biden ne devrait guère surprendre quiconque a suivi l’actualité au cours de l’année écoulée. Ce décret constitue une réponse majeure du gouvernement fédéral américain à une longue série d’incidents, depuis l’attaque contre SolarWinds jusqu’à la récente attaque par rançongiciel visant Colonial Pipeline — la plus grande attaque connue contre une entreprise énergétique américaine.

Étant donné que bon nombre des attaques récentes sont liées à la chaîne logistique logicielle, il n’est pas étonnant que la sécurité logicielle, et plus particulièrement celle de la chaîne logistique logicielle, soit un thème récurrent du décret. L’attaque désormais tristement célèbre contre SolarWinds a touché de nombreuses agences gouvernementales, dont le Pentagone, le département d’État et le département de la Sécurité intérieure des États-Unis, ainsi que des entreprises privées comme Microsoft, Intel et Cisco. Elle a mis la sécurité de la chaîne logistique logicielle au premier plan.

Les attaques contre la chaîne logistique logicielle ne sont pas nouvelles. Chez Snyk, nous parlons depuis 2018 du développement et de la composition des logiciels modernes comme d’un maillon faible et d’un vecteur potentiel de distribution de logiciels malveillants. Mais ces attaques se multiplient chez les cybercriminels, en raison de changements notables dans la manière dont les applications logicielles sont aujourd’hui conçues. Le décret de Joe Biden reconnaît ces changements et vise à réduire les risques qu’ils représentent, en chargeant le département du Commerce d’établir des normes strictes pour les entreprises qui vendent des logiciels au gouvernement fédéral.  

Que sont les attaques contre la chaîne logistique logicielle ?

Lors d’une attaque contre la chaîne logistique logicielle, les cybercriminels accèdent aux logiciels et les modifient au sein de la chaîne complexe de développement logiciel afin de compromettre une cible en aval en y insérant du code malveillant. Une attaque de ce type n’est pas une fin en soi. Elle sert à ouvrir une fenêtre d’opportunité permettant à un cybercriminel d’introduire un logiciel malveillant ou de créer une porte dérobée pour obtenir un accès ultérieur. Lors de l’attaque contre SolarWinds, par exemple, des pirates ont réussi à accéder à Orion, la plateforme de surveillance des réseaux et des applications de SolarWinds, afin de diffuser des mises à jour malveillantes aux milliers d’utilisateurs du logiciel.

Les attaques contre la chaîne logistique logicielle sont un vecteur d’attaque extrêmement efficace en raison de la manière dont les logiciels modernes sont conçus. Comme les chaînes logistiques industrielles, la chaîne logistique logicielle comprend la planification, l’approvisionnement en matériaux, la fabrication et la vente au détail. Ici, les matériaux sont remplacés par du code. Ce code peut être propriétaire, mais une part croissante provient de fournisseurs, qu’ils soient commerciaux ou open source. Ces dépendances peuvent servir à introduire du code malveillant dans les logiciels. Le code sert à développer des logiciels et, dans la chaîne logistique logicielle moderne, le développement implique un nombre toujours plus grand de processus pouvant chacun être exploités pour distribuer efficacement des logiciels malveillants.

Exigences fédérales en matière de sécurité de la chaîne logistique logicielle

Le décret présidentiel de Joe 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é, ainsi qu’à renforcer la sécurité des logiciels achetés par le gouvernement fédéral. Les risques liés aux attaques contre la chaîne logistique logicielle sont clairement exposés au début de la section 4 du décret :

Le développement des logiciels commerciaux manque souvent de transparence, ne met pas suffisamment l’accent sur la capacité des logiciels à résister aux attaques et ne dispose pas de contrôles adéquats pour empêcher toute altération par des acteurs malveillants. Il est urgent de mettre en place des mécanismes plus rigoureux et prévisibles afin de garantir que les produits fonctionnent de manière sécurisée et conformément à leur objectif... En conséquence, le gouvernement fédéral doit agir rapidement pour améliorer la sécurité et l’intégrité de la chaîne logistique logicielle...

Afin de protéger les agences gouvernementales contre ce risque, le décret charge le NIST d’établir des bonnes pratiques, des lignes directrices et des critères pour les futures normes que les fournisseurs de logiciels devront respecter afin de pouvoir vendre leurs logiciels au gouvernement fédéral.

Nomenclature logicielle (SBOM)

Seule une petite partie du code qui compose les logiciels est développée en interne à partir de zéro ; la majeure partie provient de composants open source ou tiers. L’exigence du décret relative à une nomenclature logicielle (SBOM) tient compte de cette réalité et souligne la nécessité d’une meilleure transparence sur le contenu exact des logiciels, afin de pouvoir atténuer les risques liés aux attaques contre la chaîne logistique logicielle.  

Environnement de développement sécurisé

Les fournisseurs de logiciels devront attester qu’ils utilisent un environnement de développement sécurisé. Le décret demande au NIST de définir les critères permettant de considérer un environnement de développement comme sécurisé, notamment des processus de compilation 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és

Les fournisseurs de logiciels devront également respecter des pratiques de développement sécurisées et pouvoir attester des mesures prises. Cela comprend l’utilisation de tests de sécurité automatisés dès le début du développement et tout au long de celui-ci, afin de garantir l’intégrité du code, de détecter les vulnérabilités et de les corriger. Les « artefacts » attestant du développement logiciel et de l’exécution des outils et processus utilisés devront être disponibles sur demande.

Intégrité de l’open source

En règle générale, 80 à 90 % du code d’une application est open source. Conscient de cette réalité, le décret exige des fournisseurs de logiciels qu’ils « garantissent et attestent l’intégrité et la provenance des logiciels open source utilisés dans tout ou partie d’un produit ».

Renforcer la sécurité de la chaîne logistique logicielle

Pour vous préparer aux lignes directrices du NIST et renforcer votre chaîne logistique logicielle, commencez par améliorer la sécurité de vos applications. Grâce à sa plateforme de sécurité des applications cloud native conçue pour les développeurs, Snyk répond à la grande majorité des exigences énoncées dans le décret.

Donner les moyens d’agir aux développeurs

La mise en œuvre réussie des pratiques de développement sécurisées préconisées par le décret présidentiel dépend de la capacité des développeurs à intégrer facilement la sécurité à leur workflow de développement. Le développement sécurisé commence par les développeurs eux-mêmes. Ce sont eux qui décident comment concevoir leurs applications et qui sont, en définitive, responsables de l’intégrité, de la qualité et de la sécurité de leur code. Les modèles de sécurité traditionnels, qui interviennent tard dans le processus de développement et le ralentissent avec des workflows peu intuitifs, ne sont plus adaptés à un environnement de développement dynamique.

L’approche de Snyk consiste à donner aux développeurs des outils adaptés à leurs besoins, ainsi que des conseils pertinents de la part de l’équipe de sécurité. La plateforme Snyk a été conçue pour leur offrir un outil qu’ils aiment vraiment utiliser, qui ressemble aux autres outils de leur boîte à outils et qui ne les ralentit pas.

Sécurité automatisée tout au long du SDLC

Pour garantir l’intégrité des logiciels dès le début du processus de développement, le décret présidentiel préconise la mise en place précoce de tests de sécurité automatisés, « ... qui seront exécutés régulièrement, ou au minimum avant la publication d’un produit, d’une version ou d’une mise à jour ». Les clients de Snyk s’appuient sur diverses intégrations disponibles, ainsi que sur l’API Snyk, pour automatiser les tests de sécurité à différentes étapes du processus de développement logiciel. Ceux-ci commencent dès l’environnement de développement local des développeurs, se poursuivent dans les workflows basés sur Git et le processus de compilation, puis jusqu’à l’environnement de production. 

Sécuriser TOUT le code des logiciels modernes

Le décret présidentiel reconnaît que la composition du code d’une application a évolué. Le code propriétaire, les packages open source, les conteneurs et le code chargé de provisionner l’infrastructure cloud (l’infrastructure as code) sont les matériaux qui composent la chaîne logistique logicielle moderne.

Pour aider les entreprises à gérer et à atténuer ce nouveau profil de risque, il faut adopter une approche plus globale de la sécurité des applications. Les équipes de sécurité qui se concentrent sur les outils de test statique de sécurité des applications (SAST) pour protéger le code écrit par leurs équipes de développement ignorent les risques liés à l’utilisation de composants open source et de conteneurs, et inversement : les outils d’analyse de la composition logicielle (SCA) ne couvrent pas le code propriétaire. La plateforme Snyk offre une solution complète conçue pour les développeurs, qui aide les entreprises à sécuriser l’ensemble du code qui compose les logiciels modernes.

Attestations et rapports au niveau des composants

Comme indiqué ci-dessus, les exigences du décret présidentiel accordent une place centrale à la transparence vis-à-vis du gouvernement fédéral sur les processus et les mesures mis en place, ainsi que sur les matériaux utilisés pour créer les logiciels, sous la forme d’une SBOM. Snyk propose de nombreuses fonctionnalités de reporting permettant de consulter et d’exporter une SBOM, ainsi que d’autres types de rapports. Les clients de Snyk utilisent également l’API Snyk pour s’intégrer automatiquement aux outils tiers de reporting et de gestion des vulnérabilités, afin de surveiller en continu la situation de l’entreprise en matière de sécurité et de conformité.

Et maintenant ?

Le décret demande au NIST de publier des lignes directrices préliminaires dans les six mois, puis leur version définitive dans un délai d’un an.  Si les exigences du décret s’adressent aux entreprises qui vendent leurs produits au gouvernement fédéral, les normes devraient également s’étendre au secteur privé et toucher l’ensemble du marché des logiciels.

Il serait judicieux de commencer dès maintenant à vous préparer en examinant attentivement le décret et en repérant les principales lacunes de votre chaîne logistique logicielle actuelle.

Chez Snyk, nous suivrons l’évolution des lignes directrices au fur et à mesure de leur publication par le NIST et partagerons de nouvelles informations sur notre blog. Restez à l’écoute. Nous participons également activement aux travaux du NIST visant à répondre aux exigences du décret, en particulier concernant les spécifications SBOM dans le cadre du SBOM SIG.

Pour en savoir plus sur la manière dont Snyk aide les agences gouvernementales à répondre aux exigences de ce décret, contactez-nous à l’adresse snyk_federal@snyk.io ou consultez la page Snyk for Government.