Pourquoi le gouvernement américain exigera des éditeurs de logiciels qu’ils certifient la sécurité de leurs produits
Écrit par Dave Nyczepir
De nouvelles directives publiées par la Maison Blanche mercredi donnent aux agences un calendrier pour commencer à obtenir des auto-attestations des développeurs de logiciels avant d’utiliser leurs produits, plutôt que de s’appuyer sur des évaluations de tiers.
L’auto-attestation fait référence à la documentation que les développeurs doivent fournir pour démontrer leur conformité au cadre de développement logiciel sécurisé. Il s’agit d’un cadre clé dont les responsables informatiques fédéraux et l’industrie technologique au sens large sont conscients depuis au moins mars, lorsque la Maison Blanche a demandé aux agences de commencer à l’adopter.
Les détails inclus dans le dernier mémo de l’OMB apaisent les inquiétudes exprimées par les experts en informatique et en cybersécurité interrogés par FedScoop en juin, qui craignaient que cela puisse obliger les développeurs de logiciels à obtenir une vérification par un tiers de leur conformité, ce qui prendrait des années pour mettre en place des capteurs et surveille et s’assure de l’existence d’auditeurs qualifiés.
S’adressant à FedScoop après la publication de la note de service mercredi, Dan Lorenc, PDG de la startup de sécurité logicielle Chainguard, a déclaré que la décision de la Maison Blanche de commencer par l’auto-attestation était « assez évidente dès le début ».
S’ils avaient fait un tiers, cela aurait été choquant à ce stade », a-t-il ajouté. Selon Lorenc, il s’agit de la première étape pour lancer un écosystème complexe dans lequel les fournisseurs seront bientôt tenus d’évaluer leurs propres fournisseurs dans une vague qui devrait se propager assez rapidement dans l’industrie ».
Lorenc pense qu’une transition vers des évaluations par des tiers se produira à un moment donné, un point de vue qui n’est pas partagé par tout le monde dans l’industrie.
Selon Henry Young, directeur des politiques du groupe industriel The Software Alliance, de telles évaluations par un fournisseur tiers peuvent ne pas être nécessaires.
Ce que je vois, c’est qu’il est probable que la majorité des achats puissent être effectués avec une attestation de fournisseur, plutôt qu’avec la certification tierce plus onéreuse », a-t-il déclaré, soulignant que les fournisseurs de logiciels prennent très au sérieux les assurances qu’ils donnent en raison de leur effet direct. sur les clients.
Le mémo de la Maison Blanche exige que toute auto-attestation inclue le nom du développeur du logiciel, une description des produits concernés et une déclaration attestant que le développeur se conforme aux pratiques de développement sécurisées.
Malgré cela, les agences peuvent toujours exiger des évaluations de tiers basées sur des déterminations basées sur les risques sur la criticité du produit ou des services, selon les directives. Celles-ci peuvent être effectuées par un évaluateur du programme fédéral de gestion des risques et des autorisations (FedRAMP) ou par un autre qu’ils approuvent.
Le Federal Acquisition Regulatory Council prévoit également de développer un formulaire standard d’auto-attestation pour les agences.
Actuellement, des outils de numérisation de base ou d’analyse de la composition logicielle sont utilisés après la création du logiciel pour générer une nomenclature logicielle lisible par machine (SBOM), mais les agences peuvent déjà le faire. Les SBOM modernes seront générés par les développeurs et incluront plus d’informations pour une image plus complète de la chaîne d’approvisionnement logicielle, a déclaré Lorenc.
Malgré les efforts récents des législateurs pour codifier les SBOM dans le processus d’approvisionnement fédéral dans le cadre du projet de loi sur les dépenses de la Chambre, les développeurs de logiciels souhaitent que le gouvernement clarifie les modèles de menace d’artefacts, les entrées de journal, les fichiers de code source et les rapports d’analyse de vulnérabilité qu’ils contiendront et comment ils doivent être partagés avant de continuer. .
Le libellé de ce projet de loi interdirait l’achat de logiciels contenant des vulnérabilités connues.
C’est le genre de chose qui sonne bien au début, jusqu’à ce que vous pénétriez dans les tranchées et que vous réalisiez à quel point nombre de ces bases de données de vulnérabilités sont désordonnées et à quel point la qualité des données est médiocre, a ajouté Lorenc.
Les SBOM ne feront qu’amplifier cette mauvaise qualité des données, a-t-il déclaré.
Alors que Young est heureux que le mémo de la Maison Blanche inclue de nombreuses meilleures pratiques de l’industrie concernant le développement de logiciels sécurisés, les capacités et le cycle de vie, il est déçu que les mêmes pratiques ne soient pas requises au sein des agences et des sous-traitants développant des logiciels.
La note de service ne traite pas non plus de la manière de rationaliser l’auto-attestation dans l’ensemble du gouvernement.
Les directives ne font rien pour harmoniser les exigences entre les agences, a déclaré Young. Cela signifie donc que les fournisseurs pourraient devoir fournir la même documentation ou une documentation similaire à différentes agences, ce qui ne semble pas être la meilleure utilisation des ressources de cybersécurité.