La chaîne d'approvisionnement mondiale en logiciels est toujours sous menace des cybercriminels qui menacent de voler des informations sensibles ou des propriétés intellectuelles et de compromettre l’intégrité du système. Ces problèmes peuvent avoir un impact sur les entreprises commerciales ainsi que sur la capacité du gouvernement à fournir des services au public de manière sécurisée et fiable.
L'Office of Management and Budget (OMB) des États-Unis a publié en juillet 2022 une note sur le sujet, dont nous avons parlé ici en détail. En septembre 2022, une nouvelle note a été publiée, axée cette fois sur la sécurité et l'intégrité de la chaîne d'approvisionnement logicielle, soulignant le rôle important des SBOM. Il présente une liste d’exigences précises et, pour la première fois, partage un véritable calendrier contraignant pour la mise en œuvre des changements.
Le mémo contient deux points principaux liés au décret (EO) 14028, Améliorer la cybersécurité de la nation :
- L'EO demande au National Institute of Standards and Technology (NIST) de partager des conseils pour développer des pratiques visant à renforcer la sécurité de la chaîne d'approvisionnement en logiciels. Pour y parvenir, le NIST a publié deux documents : le Secure Software Development Framework (SSDF), PS 800-218 et Guide de sécurité de la chaîne d’approvisionnement logicielle. Ensemble, ils s'appellent NIST Guidance et décrivent un ensemble de pratiques qui constituent la base de la création de logiciels sécurisés.
- L'EO ordonne également au Bureau de la gestion et du budget de commencer à exiger des agences qu'elles se conforment aux directives du NIST et à toute autre mise à jour.
L’auto-attestation est un prérequis, mais est-ce tout ?
Les producteurs de logiciels sont désormais tenus de fournir une auto-attestation aux agences avant de commencer à utiliser leur logiciel. Il existe en fait trois catégories qui nécessitent une auto-attestation : les achats de nouveaux logiciels, les mises à niveau de versions majeures et les renouvellements de logiciels. L'objectif est d'équiper les agences de produits logiciels sécurisés et résilients qui les protègent contre les menaces telles que SolarWinds vécu, ce qui a compromis plusieurs agences.
Commençons par les bases : qu’est-ce que l’auto-attestation exactement ?
L'auto-attestation est un document qui fonctionne comme une déclaration de conformité, attestant que le producteur du logiciel se conforme aux pratiques des directives du NIST. L'idée est que les agences obtiennent une auto-attestation pour chaque produit ou service logiciel tiers qui répond aux exigences du mémo. Cela inclut les renouvellements de logiciels et les mises à jour de versions majeures.
Un autre point important du mémo est que les agences encouragent les éditeurs de logiciels à inclure leurs produits. Cela leur permettrait de fournir la même attestation à toutes les agences d'achat.
L'agence peut conserver le document d'auto-attestation à moins que l'éditeur de logiciels ne le publie publiquement et propose un lien vers la publication dans sa proposition.
Remarque : Alors que tous les autres mémos ou lignes directrices à ce jour affirment que l'auto-attestation est suffisante pour commencer, celle-ci place la confiance et la transparence comme objectifs clés. Il se concentre spécifiquement sur la chaîne d'approvisionnement des logiciels, et pas seulement sur la cybersécurité ou le SSDF (même s'ils en font partie).
Que se passe-t-il si l'éditeur de logiciels ne peut pas fournir d'auto-attestation au format standard ?
Un producteur de logiciels peut ne pas être en mesure d'attester d'une ou plusieurs pratiques du guide NIST telles qu'identifiées dans le formulaire d'auto-attestation standard. Dans ce cas, l’agence qui demande le logiciel exigera de l’entreprise :
- Identifier les pratiques dont ils ne peuvent pas attester
- Documenter toutes les pratiques utilisées pour atténuer ces risques
- Élaborer un plan d'action et des jalons (POA&M)
Naturellement, l'agence doit s'assurer que la documentation n'est pas publiée publiquement (ni par le vendeur, ni par l'agence elle-même).
Supposons que le fournisseur fournisse toute la documentation et qu'elle soit satisfaisante pour l'agence. Dans ce cas, celui-ci peut utiliser les produits ou services logiciels malgré l'absence d'une auto-attestation complète de la part du producteur.
Que doit inclure une auto-attestation acceptable ?
Un document d’auto-attestation doit inclure les exigences minimales suivantes :
- Le nom de l'éditeur de logiciels
- Une description des produits logiciels auxquels la déclaration fait référence (idéalement, ce point décrit l'entreprise de logiciels ou le niveau de la gamme de produits, y compris tous les produits non classés proposés aux agences)
- Une déclaration confirmant que le fournisseur opère conformément aux pratiques et tâches de développement sécurisées (détaillées dans le formulaire d'auto-attestation)
Ce type d'auto-attestation constitue le niveau minimum requis. Néanmoins, si les agences souhaitent acquérir un logiciel sans celui-ci – par exemple, en raison de son caractère critique – elles peuvent effectuer des déterminations basées sur les risques à l'aide d'une évaluation par un tiers (définie dans M-21-30).
La directive encourage néanmoins les agences à utiliser un formulaire standard d’auto-attestation. Le Conseil fédéral de réglementation des acquisitions (FAR) proposera des règles concernant l’utilisation d’un tel formulaire d’auto-attestation standard et uniforme.
Auto-attestation pour les logiciels open source
Supposons que l'agence souhaite acquérir un logiciel open source ou un produit logiciel comprenant des composants open source. Dans ce cas, il peut se tourner vers une évaluation tierce fournie par une organisation d’évaluation tierce certifiée FedRAMP (3PAO) ou approuvée par l’agence elle-même.
Une telle évaluation est acceptable à la place de l'auto-attestation d'un fournisseur à condition que le 3PAO utilise les directives du NIST comme référence.
Les SBOM deviennent un standard de l’industrie. Êtes-vous prêt pour cela?
Bien que l'auto-attestation soit le niveau minimum requis, les agences peuvent ne pas en avoir besoin si le produit ou le service qu'elles cherchent à obtenir est essentiel et ne peuvent pas fournir d'auto-attestation sous une forme standard.
Ce qui est important, c'est que la note encourage les agences à obtenir des fournisseurs des artefacts démontrant leur conformité aux pratiques de développement de logiciels sécurisés. Une de ces pratiques consiste à avoir un SBOM.
Qu’est-ce qu’un SBOM et comment ça marche ?
SBOM fait référence à une nomenclature logicielle, un inventaire de tous les composants et dépendances qui font partie du développement et de la livraison d'un produit logiciel.
Une agence peut exiger un SBOM dans le cadre des exigences de l'appel d'offres, en fonction du caractère critique du logiciel pour l'agence.
Le mémo comprend les lignes directrices suivantes pour l’achat et l’utilisation du SBOM par les agences :
- L'agence peut conserver le SBOM à moins que le producteur du logiciel ne le publie et ne partage un lien vers celui-ci avec l'agence.
- Les SBOM doivent être générés en utilisant l'un des formats de données définis dans le Rapport de la NTIA « Les éléments minimum pour une nomenclature logicielle (SBOM) » ou les directives qui lui succèdent publiées par le Agence de cybersécurité et de sécurité des infrastructures.
- Lorsqu’elles envisagent les SBOM, les agences doivent prendre en compte la réciprocité des SBOM et des autres artefacts des producteurs de logiciels gérés par d’autres agences. Ceci est basé sur l’applicabilité directe et l’actualité de l’artefact.
- L'agence peut exiger des artefacts autres que SBOM si nécessaire, par exemple ceux liés aux outils et processus automatisés pour valider l'intégrité du code source ou effectuer des vérifications des vulnérabilités.
- L'agence peut également exiger que l'éditeur de logiciels prouve qu'il participe à un Programme de divulgation des vulnérabilités.
Le mémo suggère également que les agences informent les fournisseurs de ces exigences le plus tôt possible dans le processus d'acquisition. Pour se conformer à l'Ordre et aux directives du NIST, les agences doivent planifier de manière appropriée et inclure toutes les exigences dans leur processus d'évaluation de logiciels. Notez que cela doit également être conforme au calendrier spécifié par le mémo (cela sera abordé dans la section suivante).
Les agences doivent préciser les exigences dans la demande de proposition (RFP) ou dans d'autres documents de sollicitation. L'idée ici est que l'agence s'assure que le fournisseur met en œuvre et utilise pratiques de développement de logiciels sécurisés conformément aux directives du NIST tout au long du cycle de vie du développement logiciel.
Le SBOM est clairement une bonne pratique de l'industrie sur la voie d'une utilisation généralisée, en particulier pour atténuer risques liés à la chaîne d'approvisionnement en logiciels.
Pour aider les entreprises à renforcer la confiance dans leurs produits logiciels, nous avons récemment lancé une plateforme facile à utiliser qui permet de générer des SBOM et de les partager au sein et entre les organisations. Faites un essai gratuitement pour voir à quel point il peut être facile de générer, gérer et partager des SBOM.
Ce n'est plus seulement une recommandation ; maintenant il y a un calendrier obligatoire à suivre
Les agences doivent se conformer aux exigences de mémorisation conformément à ce calendrier :
- Les agences ont 90 jours d'inventorier tous leurs logiciels tiers, y compris un inventaire distinct pour les « logiciels critiques ».
- Dans 120 jours, ils doivent créer « un processus cohérent pour communiquer les exigences pertinentes de ce mémorandum aux fournisseurs et garantir que les lettres d’attestation non publiées publiquement par les fournisseurs de logiciels soient collectées dans un système d’agence centrale ».
- Ils ont aussi 270 jours pour collecter les lettres d'attestation qui n'ont pas été publiées publiquement pour les « logiciels critiques ». D’ici un an, les agences devraient avoir collecté les lettres de tous les logiciels tiers.
- Enfin, au sein 180 jours À compter de la date de la note (14 septembre 2022), les DSI des agences doivent avoir évalué tous les besoins de formation et élaborer des plans de formation pour examiner et valider les documents et artefacts d'attestation.
Les agences peuvent demander une prolongation au moins 30 jours avant toute date limite pertinente indiquée dans la note, accompagnée d'un plan pour répondre aux exigences en suspens. Il est également possible de demander une dérogation, mais uniquement dans des circonstances exceptionnelles et pour une durée limitée.
Résumé
L'OMB partagera des instructions spécifiques pour soumettre des demandes de dérogation ou de prolongation dans les 90 jours suivant la date de la note (jusqu'à la mi-décembre 2022). De plus, en consultation avec la CISA et l'Administration des services généraux, il déterminera les exigences d'un « référentiel centralisé pour les attestations de logiciels et les artefacts » doté des mécanismes appropriés de protection et de partage entre les agences.
Un tel lieu central pourrait un jour devenir un lieu central pour une variété de preuves et d'attestations de sécurité au-delà du formulaire d'auto-attestation ou SBOM. Placer toutes les preuves dans un endroit unique et partageable aide les organisations à faire face à des problèmes communs, tels que l'émergence de nouveaux exploits ou CVE.
C’est exactement ce qu’est Scribe. Jeter un coup d'œil à cette page pour en savoir plus sur notre plateforme complète de génération, de gestion et de partage de SBOM au sein et entre les organisations.
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
