Version finale SSDF (NIST 800-218) – différences par rapport au projet et leurs implications pour vous

Le 22 mars, le NIST a publié la version finale du SSDF 1.1 (Secure Software Development Framework). 

Le cadre a été initialement publié en septembre 2021 sous forme de version préliminaire. Toutes les pratiques et tâches de haut niveau restent les mêmes avec de nombreuses différences centrées sur les différents exemples fournis.

Qu'est-ce que le cadre NIST SP 800-218 ? Le SSDF consolide les recommandations de bonnes pratiques de longue date pour le développement de logiciels sécurisés. Son approche personnalisable et indépendante du secteur est conçue pour faciliter les communications entre les départements (et entre les producteurs/acquéreurs) afin d'aider à définir les objectifs stratégiques et à évaluer les lacunes actuelles. 

Le NIST recommande d'équilibrer le risque par rapport au coût, à la faisabilité et à l'applicabilité au moment de décider des pratiques à mettre en œuvre. L'automatisation est une fonctionnalité clé à prendre en compte dans le but souhaité d'automatiser autant de contrôles et de processus favorisant la sécurité des logiciels que possible.

Différences entre la version finale et la version préliminaire : 

Vérification de l'intégrité – Lorsque l’on parle de vulnérabilités, l’accent est davantage mis sur la vérification de l’intégrité. lorsque vous examinez à la fois votre code et les bibliothèques/produits acquis auprès de sources externes.

Attestations immuables - La responsabilité de la mise en œuvre des pratiques peut être répartie entre différentes organisations, en particulier si l'on considère la complexité des chaînes d'approvisionnement logicielles. La visibilité diminue considérablement à mesure que vous avancez en amont ou en aval de la chaîne. C'est pourquoi le NIST recommande de codifier la responsabilité partagée impliquant à la fois les fournisseurs et les consommateurs d'une plateforme/service dans un contrat ou un accord. Il doit être clair quelle partie est responsable de chaque pratique et tâche et comment chaque prestataire attestera de sa conformité à l'accord. L’axiome « ​​faire confiance mais vérifier » est vrai ici – attestations immuables qui peuvent facilement être partagées entre les producteurs et les acquéreurs de logiciels sont essentielles pour accroître la confiance de toutes les parties prenantes dans la chaîne d'approvisionnement en logiciels.

Implication de la communauté open source – Le NIST déclare que les travaux futurs prendront probablement la forme de cas d'utilisation spécifiques et qu'il a l'intention de collaborer avec la communauté open source. Étant donné que la plupart des produits de code commerciaux utilisés aujourd'hui incluent d'importants éléments de code open source, il est naturel d'inclure la communauté open source dans la planification et la mise en œuvre de la sécurité du cycle de vie des logiciels.

Scores de gravité de la vulnérabilité en tant que KRI (Key Risk Indicator) – Un autre changement en cours concerne les scores de gravité en tant qu’indicateur clé. Sachant qu'un grand nombre de personnels de cybersécurité souffrent d'une lassitude face aux alertes, il est logique que chaque organisation définisse l'échelle de score de vulnérabilité qui lui convient et le traitement spécifique que mérite chaque score.

Moins d’accès humain, plus d’automatisation – Le NIST encourage à minimiser l’accès humain direct aux systèmes de chaîne d’outils, tels que les services de build. Plus les gens y ont accès, plus les erreurs peuvent se produire. Cela s’inscrit, encore une fois, dans la même veine que la recommandation en faveur d’une plus grande automatisation.

Des SBOM intègres – Lors de la discussion du SBOM (Software Bill of Materials), le NIST recommande d'employer une protection solide pour l'intégrité de l'artefact, ainsi que de fournir aux destinataires un moyen de vérifier cette intégrité. Les destinataires peuvent être des personnes internes ou externes à l’organisation. Il est donc logique d’utiliser un système tiers pour partager des SBOM sécurisés.

Intégrité du code binaire ou source – Si l'intégrité ou la provenance des binaires acquis ne peut pas être confirmée, il est suggéré de reconstruire ces binaires à partir du code source. Cela suppose que vous puissiez vérifier l'intégrité et la provenance du code source. Il est de la responsabilité de tous les maillons de la chaîne d'approvisionnement des logiciels de fournir une preuve vérifiable d'intégrité, via des signatures numériques ou d'autres mécanismes comme un SBOM.  

Résumé

Dans l'ensemble, le NIST considère que « les pratiques, les tâches et les exemples de mise en œuvre du SSDF représentent un point de départ à considérer. Ils sont destinés à être modifiés et personnalisés, et à évoluer au fil du temps.

Le SSDF n'est pas une liste de contrôle que vous devez suivre, mais fournit plutôt des conseils pour planifier et mettre en œuvre une approche basée sur les risques pour sécuriser le développement de logiciels.

Contrairement aux réglementations fondées sur la loi américaine, le SSDF sera axé sur les entreprises : le gouvernement tirera parti de son pouvoir d'achat pour amener le marché à adhérer à ce nouveau cadre de bonnes pratiques. Si vous ne pouvez pas démontrer votre adhésion au cadre, vous ne serez pas pris en considération pour les contrats gouvernementaux. Nous assisterons probablement à un effet de retombée dans lequel les organisations envisageant de postuler à des contrats gouvernementaux exigeront que tous leurs vendeurs et fournisseurs s'y conforment également, et ainsi de suite tout au long de la chaîne d'approvisionnement en logiciels.

Pour en savoir plus sur la nouvelle réglementation et le SSDF, consultez notre webinaire sur « Démystifier les nouvelles réglementations en matière de cybersécurité en 2022 ».