Le NIST propose des étapes concrètes pour le développement de logiciels sécurisés

Le NIST a récemment publié le SP 800-204D, ses lignes directrices finales destinées aux fournisseurs de logiciels sur la mise en œuvre des éléments constitutifs des garanties de sécurité de la chaîne d’approvisionnement dans les pipelines d’intégration continue et de livraison continue. Les directives recommandent aux fabricants de donner la priorité à une série de mesures concrètes, notamment l’établissement d’exigences de sécurité de base pour l’intégration de logiciels open source et l’extension de la surveillance des données de provenance.

« Ce cadre arrive à point nommé », a déclaré Henrik Plate, chercheur pour la société de sécurité logicielle Endor Labs, qui suit le NIST SP 800-204D depuis la première publication d’une version préliminaire en septembre.

Les lignes directrices décrivent le cadre de développement de logiciels sécurisés du NIST et le décret de l’administration sur la cybersécurité publié en 2021 comme une feuille de route pour fournir la base de son dernier ensemble de recommandations, ainsi que la contribution de l’industrie et des parties prenantes. Selon Plate, les directives précédentes telles que le SSDF ne fournissaient que des pratiques de développement sécurisées de haut niveau, indépendantes des cycles de vie et des technologies spécifiques du développement logiciel.

Plate a déclaré à Information Security Media Group que les nouvelles directives « vont encore plus loin » en fournissant aux fabricants un ensemble détaillé de mesures pour renforcer la sécurité de la chaîne d’approvisionnement, telles que l’analyse continue des dépendances pour les versions vulnérables connues et les logiciels malveillants. Il a déclaré que ces mesures constituent des étapes « absolument cruciales » qui « doivent être mises en œuvre pendant l’exécution du pipeline ».

Les fournisseurs de logiciels fédéraux seront bientôt tenus de signer un formulaire d’auto-attestation développé par la Cybersecurity and Infrastructure Security Agency pour confirmer que leurs systèmes ont été développés en toute sécurité conformément au SSDF et aux autres normes développées par le NIST. Le SSDF charge les fournisseurs de s’assurer qu’ils peuvent protéger tous les composants du logiciel contre la falsification et les accès non autorisés et répondre de manière appropriée aux vulnérabilités critiques, mais certains critiques affirment que le cadre manque de détails techniques supplémentaires pour mettre pleinement en œuvre ces demandes.

Le Bureau de la gestion et du budget a retardé en juin la date limite fixée par le gouvernement fédéral pour commencer à collecter les formulaires d’attestation auprès des sous-traitants et a fourni des informations supplémentaires dans une note détaillant ce que les agences sont réellement mandatées de collecter auprès des fournisseurs de logiciels. Les agences seront uniquement tenues de collecter des attestations auprès du « producteur du produit logiciel final » plutôt que auprès des producteurs de tous les composants logiciels tiers, selon l’OMB.

On ne sait pas encore quand les agences devront commencer à collecter les attestations. La prochaine étape formelle consiste pour la Maison Blanche à approuver le formulaire CSIA en vertu d’une loi connue sous le nom de Paperwork Reduction Act, après quoi les fournisseurs de logiciels critiques auront trois mois pour commencer à soumettre des formulaires et les autres fournisseurs auront six mois. L’OMB n’a pas fixé de délai pour le moment où la Maison Blanche envisage d’examiner ou d’approuver le formulaire et n’a pas répondu à une demande de commentaires.

Plate a déclaré que ces orientations sont particulièrement utiles « dans le contexte de la prochaine auto-attestation, qui a été reportée pour l’instant, mais qui obligera à un moment donné les fournisseurs de logiciels des agences fédérales à auto-déclarer leur adhésion au SSDF ».

Les directives clarifient les attentes des sous-traitants fédéraux en logiciels qui cherchent à déclarer eux-mêmes leur adhésion au SSDF et comprennent des étapes pour garantir que les fournisseurs intègrent la sécurité tout au long des cycles de vie des logiciels et dans les pipelines CI/CD. Les étapes comprennent la définition des rôles et des responsabilités, l’utilisation de plates-formes isolées tout au long des étapes de construction du développement logiciel et l’automatisation de l’ensemble du pipeline CI/CD en déployant les outils appropriés.

Les directives exhortent également les fournisseurs de logiciels à investir massivement dans des outils et techniques automatisés pour analyser les pipelines, effectuer des tests d’intégrité et aider à superviser les référentiels et les systèmes de gestion de code source.

Ces directives s’alignent sur des appels plus larges « à fournir des garanties non seulement sur l’artefact final du logiciel, mais aussi sur les processus de développement, les machines, les utilisateurs et bien d’autres personnes impliquées », selon Chris Hughes, architecte de sécurité en chef chez Endor Labs et membre de la Cybersecurity and Infrastructure Security Agency, qui se concentre sur la sécurité de la chaîne d’approvisionnement.

La CISA a dirigé les efforts visant à transférer les risques de cybersécurité des utilisateurs finaux aux développeurs de logiciels, et a récemment commencé à émettre des « alertes sécurisées dès la conception » avec le FBI qui se concentrent sur la manière dont les fabricants peuvent transférer le fardeau de la sécurité des clients en l’intégrant dans la vie du logiciel. faire du vélo.