TL;DR

Le NIST SSDF est un cadre de haut niveau pour l'élaboration de logiciels sécurisés tout au long du cycle de développement durable.

Organisé en 4 catégories : Préparer, Protéger, Produire, Réagir.

Intègre les normes OWASP, SAFECode et les meilleures pratiques du monde réel.

Il s'agit d'une conception sécurisée, et non d'un théâtre de la conformité. C'est une nécessité si vous créez des logiciels pour le gouvernement américain ou si vous vous préoccupez de votre chaîne d'approvisionnement.

Résumé de la fiche d'évaluation du NIST SSDF (SP 800-218) :

• Effort du développeur : Modéré (se concentre sur l'intégration des pratiques sécurisées que les développeurs devraient idéalement déjà apprendre/faire - modélisation des menaces, codage sécurisé, tests, gestion des vulnérabilités). L'effort réside dans la formalisation et l'application cohérente de ces pratiques.
• Coût de l'outillage : Modéré (repose fortement sur l'outillage DevSecOps standard : SAST, DAST, SCA, IAST, outils de modélisation des menaces, référentiels sécurisés, plateformes de gestion des vulnérabilités).
• Impact sur le marché : élevé (de plus en plus important en raison des exigences fédérales américaines via l'EO 14028 ; considéré comme la meilleure pratique pour un SDLC sécurisé à l'échelle mondiale, influence les attentes en matière de sécurité de la chaîne d'approvisionnement).
• Flexibilité : élevée (fournit des pratiques et des tâches, et non des contrôles rigides ; adaptable à divers modèles SDLC tels que Agile, Waterfall, DevOps).
• Intensité de l'audit : Modérée (pas de certification formelle, mais obligation d'auto-attestation pour les fournisseurs fédéraux ; les évaluations se concentrent sur la démonstration de la mise en œuvre des pratiques).

Qu'est-ce que le NIST SSDF (SP 800-218) ?

La publication spéciale 800-218 du NIST, Secure Software Development Framework (SSDF) Version 1.1, fournit un ensemble de pratiques de haut niveau recommandées pour la création de logiciels sécurisés. Il est conçu pour être intégré dans n'importe quel modèle SDLC (Agile, DevOps, Waterfall, etc.) afin d'aider les producteurs de logiciels à réduire les vulnérabilités, à atténuer l'impact de toute faille restante et à traiter les causes profondes afin d'éviter qu'elles ne se reproduisent.

Le NIST SSDF n'est pas prescriptif sur la manière exacte de mettre en œuvre les choses ; il définit les résultats à atteindre. Il organise ces résultats en pratiques, qui sont regroupées en quatre catégories reflétant le cycle de vie :

1. Préparer l'organisation (PO) : Préparer le personnel, les processus et la technologie.
   
   • Exemples : Définir les rôles/responsabilités en matière de sécurité (PO.1), mettre en œuvre les processus de soutien (PO.2), définir les exigences en matière de sécurité (PO.3).
2. Protéger le logiciel (PS) : Protection des composants logiciels contre la falsification.
   
   • Exemples : Protéger toutes les formes de code contre les accès non autorisés et les manipulations (PS.1), fournir des mécanismes de vérification de l'intégrité des versions logicielles (PS.2), archiver et protéger les composants des versions (PS.3).
3. Produire des logiciels bien sécurisés (PW) : Minimiser les vulnérabilités pendant le développement.
   
   • Exemples : Concevoir un logiciel pour répondre aux exigences de sécurité/atténuer les risques (PW.1), vérifier la conformité de la conception (PW.2), réutiliser un logiciel existant sécurisé (PW.3), créer le code source en respectant les pratiques de codage sécurisé (PW.4), configurer le processus de construction de manière sécurisée (PW.5), examiner et tester le code (PW.6/PW.7), configurer le logiciel en vue d'un déploiement sécurisé (PW.8).
4. Répondre aux vulnérabilités (RV) : Identifier et traiter les vulnérabilités après la publication.
   
   • Exemples : Identifier et analyser les vulnérabilités (RV.1), évaluer, hiérarchiser et remédier aux vulnérabilités (RV.2), analyser les causes profondes (RV.3).

Chaque pratique est subdivisée en tâches (actions spécifiques) et comprend des exemples de mise en œuvre théorique (suggestions d'outils/processus) et des références (renvois à des pratiques établies telles que OWASP SAMM, BSIMM).

Le SSDF du NIST a pris de l'importance avec le décret américain 14028 sur l'amélioration de la cybersécurité de la nation, qui a imposé aux agences fédérales de n'utiliser que des logiciels provenant de producteurs qui attestent suivre des pratiques de développement sécurisées telles que celles du SSDF.

Pourquoi est-ce important ?

Le NIST SSDF est important pour plusieurs raisons :

• S'attaque aux causes profondes : L'accent est mis sur l'intégration de la sécurité tout au long du cycle de développement durable afin de prévenir les vulnérabilités et de ne pas se contenter de les détecter ultérieurement.
• Langage commun : Fournit un vocabulaire commun pour discuter des pratiques de développement sécurisé entre les développeurs, les équipes de sécurité et les acquéreurs.
• Flexibilité : Adaptable à toute méthodologie de développement et à tout contexte organisationnel.
• Consolidation des meilleures pratiques : S'appuie sur des pratiques éprouvées provenant de sources respectées telles que OWASP, SAFECode et BSA.
• Sécurité de la chaîne d'approvisionnement en logiciels : Fournit une base pour l'amélioration de la sécurité de la chaîne d'approvisionnement en logiciels, qui est au cœur des cybermenaces et des réglementations récentes.
• Exigences fédérales : Essentiel pour les producteurs de logiciels qui vendent au gouvernement fédéral américain en raison de l'EO 14028 et des mémorandums OMB associés (comme le M-22-18) qui exigent l'auto-attestation.
• Une référence dans l'industrie : De plus en plus considéré comme une référence en matière de pratiques de développement sécurisées, même en dehors des exigences fédérales.

L'adoption du NIST SSDF permet de créer des logiciels plus sûrs dès le départ, de réduire les travaux de correction des vulnérabilités à un stade avancé et de répondre aux attentes croissantes des clients et des autorités réglementaires en matière de sécurité des logiciels.

Quoi et comment mettre en œuvre (technique et politique)

La mise en œuvre du NIST SSDF implique l'intégration de ses pratiques et tâches dans votre SDLC existant :

1. Préparer l'organisation (PO) :
   
   • Définir les rôles (champions de la sécurité, équipe AppSec).
   • Mettre en œuvre des politiques de développement sécurisé, de gestion des vulnérabilités et de divulgation.
   • Fournir aux développeurs, aux testeurs et aux architectes une formation à la sécurité basée sur les rôles.
   • Définir et communiquer les exigences de sécurité applicables au développement de logiciels.
2. Protéger le logiciel (PS) :
   
   • Utiliser des systèmes de contrôle de version (par exemple, Git) avec des contrôles d'accès stricts.
   • Mettre en œuvre la signature du code ou d'autres mécanismes pour vérifier l'intégrité de la version.
   • Utiliser des référentiels d'artefacts (par exemple, Artifactory, Nexus) avec une analyse de sécurité.
   • Archiver en toute sécurité les publications antérieures.
3. Produire des logiciels bien sécurisés (PW) :
   
   • Modélisation des menaces (PW.1) : Intégrer la modélisation des menaces dans la phase de conception (par exemple, à l'aide de STRIDE).
   • Examen de la conception sécurisée (PW.2) : Examiner l'architecture/la conception en fonction des exigences de sécurité.
   • Réutilisation sécurisée des composants (PW.3/PW.4) : Utiliser des outils d'analyse de la composition des logiciels (SCA) pour vérifier les composants libres ; respecter les normes de codage sécurisé (par exemple, les pratiques de codage sécurisé de l'OWASP).
   • Processus de construction sécurisé (PW.5) : Durcir les pipelines CI/CD, analyser les artefacts de construction.
   • Examen du code (PW.6) : Mettre en œuvre des revues de code obligatoires, axées sur la sécurité (manuelles ou assistées par des outils).
   • Tests de sécurité (PW.7) : Intégrer les tests SAST, DAST, IAST et les tests de pénétration manuels tout au long du cycle de développement durable.
   • Configuration sécurisée (PW.8) : Définir des configurations sécurisées par défaut ; analyser l'infrastructure en tant que code (IaC).
4. Répondre aux vulnérabilités (RV) :
   
   • Identification des vulnérabilités (RV.1) : Agréger les résultats de divers outils (SAST, DAST, SCA, bug bounty, etc.) dans un système central.
   • Remédiation (RV.2) : Utiliser une plateforme de gestion des vulnérabilités pour suivre, hiérarchiser (par exemple, à l'aide de CVSS, EPSS), attribuer et vérifier les correctifs dans le cadre des accords de niveau de service (SLA) définis.
   • Analyse des causes profondes (RV.3) : Analyser les problèmes systémiques à l'origine de vulnérabilités récurrentes et mettre à jour les processus/la formation.

La mise en œuvre implique souvent la sélection et l'intégration d'outils de sécurité appropriés (SAST, DAST, SCA, IAST, analyse des secrets, analyse IaC) dans le pipeline CI/CD et le flux de travail des développeurs, ainsi que l'établissement de processus clairs et la fourniture d'une formation. Aikido Security, par exemple, intègre plusieurs scanners (SCA, SAST, Secrets, IaC, etc.) dans une plateforme unique pour aider à traiter les pratiques PW et RV.

Les erreurs courantes à éviter

Lors de l'adoption du NIST SSDF, il convient de se méfier de ces pièges :

1. Le traiter comme une norme rigide : Le NIST SSDF est un guide flexible ; il est inefficace d'essayer d'appliquer littéralement chaque exemple sans l'adapter à votre contexte. Se concentrer sur le résultat de chaque pratique.
2. Manque d'adhésion de l'organisation (PO) : Ne pas établir clairement les rôles, les responsabilités, la formation et les politiques de soutien avant de se lancer dans la mise en œuvre technique.
3. Mise en œuvre axée sur les outils : L'achat d'outils sans les intégrer correctement dans le flux de travail du SDLC ou sans tenir compte des processus sous-jacents et des aspects humains.
4. Ignorer le SDLC existant : Essayer d'intégrer des pratiques de SSDF sans tenir compte de la façon dont elles s'intègrent naturellement dans votre processus de développement actuel (sprints Agile, étapes CI/CD, etc.).
5. Formation insuffisante : Attendre des développeurs qu'ils suivent des pratiques sécurisées sans leur fournir une formation adéquate et adaptée à leur rôle.
6. Une mauvaise gestion des vulnérabilités (VR) : L'identification des vulnérabilités mais l'absence d'un processus clair de hiérarchisation, de suivi des mesures correctives et d'analyse des causes profondes.
7. Se concentrer uniquement sur les "produits" (PW) : Négliger les aspects cruciaux de la préparation (PO), de la protection (PS) et de la réaction (RV).

Les questions que les auditeurs/évaluateurs pourraient poser (accent mis sur les développeurs)

Bien qu'il n'y ait pas d'audit officiel du NIST SSDF, les organisations qui attestent de leur conformité (en particulier pour les contrats fédéraux) peuvent être soumises à des évaluations. Les questions posées aux équipes de développement pourraient être les suivantes

• (PO.1) "Comment les responsabilités en matière de sécurité sont-elles définies et attribuées au sein de l'équipe de développement ?"
• (PO.4) "Quelle formation à la sécurité les développeurs ont-ils reçue récemment ?"
• (PS.1) "Comment contrôlez-vous l'accès aux dépôts de code source ?"
• (PW.1) "Pouvez-vous montrer des preuves de la modélisation des menaces effectuée pour cette application ?"
• (PW.4) "Quelles normes ou lignes directrices en matière de codage sécurisé l'équipe suit-elle ? Comment la conformité est-elle vérifiée ?"
• (PW.6/PW.7) "Décrivez votre processus de révision du code. Quels outils de test de sécurité (SAST, DAST, SCA) sont intégrés dans votre pipeline CI/CD ? Montrez-moi des résultats récents."
• (PW.8) "Comment assurez-vous la sécurité des configurations pour les applications et l'infrastructure déployées ?"
• (RV.1/RV.2) "Expliquez-moi comment vous traitez une vulnérabilité récemment découverte dans une bibliothèque tierce".

Les évaluateurs recherchent des processus documentés, des preuves de l'utilisation des outils (rapports d'analyse, modèles de menace), des dossiers de formation et une application cohérente des pratiques sécurisées tout au long du cycle de développement durable.

Des gains rapides pour les équipes de développement

L'alignement du NIST SSDF peut commencer par des étapes réalisables :

1. Intégration de base de SAST/SCA (PW.7) : Ajouter des outils automatisés d'analyse statique et d'analyse de la composition des logiciels à votre pipeline principal de CI.
2. Analyse des secrets (PW.4/PS.1) : Mettre en œuvre une analyse automatisée pour empêcher la transmission de secrets dans les référentiels de code.
3. Examens obligatoires du code (PW.6) : imposer des examens par les pairs pour toutes les modifications de code, éventuellement à l'aide d'une simple liste de contrôle de la sécurité.
4. Mises à jour des dépendances (RV.2) : Établir un processus de base pour la mise à jour régulière des bibliothèques tierces vulnérables.
5. Formation OWASP Top 10 (PO.4) : Fournir aux développeurs une formation de base sur les vulnérabilités courantes du web.
6. Modélisation simple des menaces (PW.1) : Commencer à intégrer la modélisation des menaces de base (par exemple, séances de tableau blanc pendant la conception) pour les nouvelles fonctionnalités.

Ignorez ceci et... (Conséquences de la non-conformité)

Bien que le NIST SSDF lui-même ne soit pas passible d'amendes directes, le fait d'ignorer ses principes (en particulier si l'on est soumis à des exigences fédérales américaines) peut avoir des conséquences :

• Impossibilité de vendre au gouvernement américain : Le fait de ne pas fournir l'auto-attestation requise sur la base des pratiques du SSDF peut bloquer les ventes de logiciels aux agences fédérales.
• Vulnérabilités accrues : Le fait de ne pas suivre des pratiques de développement sécurisées entraîne directement une augmentation des failles de sécurité dans les logiciels publiés, ce qui accroît le risque de violation.
• Coûts de correction plus élevés : La correction des vulnérabilités à un stade ultérieur du cycle de développement durable (ou après la publication) est nettement plus coûteuse que leur prévention à un stade précoce.
• Risque pour la chaîne d'approvisionnement : la production de logiciels non sécurisés contribue à accroître les risques pour la chaîne d'approvisionnement de vos clients.
• Atteinte à la réputation : La mise sur le marché de logiciels présentant des vulnérabilités importantes et évitables nuit à la confiance et à la réputation.
• Développement inefficace : L'absence de pratiques sûres peut entraîner des retouches, des retards et des exercices d'alerte imprévisibles.

FAQ

Le NIST SSDF (SP 800-218) est-il obligatoire ?

Elle n'est pas obligatoire pour toutes les organisations. Cependant, la conformité (par auto-attestation) est requise pour les producteurs de logiciels qui vendent au gouvernement fédéral américain, conformément à l'Executive Order 14028 et à l'OMB Memo M-22-18. Il est considéré comme un cadre de bonnes pratiques pour tous les producteurs de logiciels.

Existe-t-il une certification NIST SSDF ?

Non, le NIST ne propose pas de certification pour le SSDF. La conformité est démontrée par l'auto-attestation, en particulier pour les fournisseurs fédéraux. Des évaluations tierces peuvent valider cette attestation, mais ne donnent pas lieu à un certificat NIST officiel.

Quel est le lien entre le NIST SSDF et le NIST CSF ou le NIST 800-53 ?

Le NIST SSDF se concentre spécifiquement sur les pratiques de développement de logiciels sécurisés tout au long du cycle de développement logiciel (SDLC). Le NIST CSF est un cadre plus large pour la gestion du risque global de cybersécurité de l'organisation. Le NIST 800-53 est un catalogue détaillé de contrôles de sécurité et de protection de la vie privée. Les pratiques du SSDF aident à mettre en œuvre certaines fonctions du CSF (comme Protéger, Détecter) et des contrôles 800-53 spécifiques liés au développement de logiciels (comme la famille SA - System Acquisition).

Quel est le lien entre le NIST SSDF et l'OWASP SAMM ou le BSIMM ?

Le NIST SSDF s'est fortement inspiré de modèles établis tels que OWASP SAMM (Software Assurance Maturity Model) et BSIMM (Building Security In Maturity Model). Le SSDF fournit un ensemble de pratiques de haut niveau, tandis que le SAMM et le BSIMM proposent des modèles de maturité et des descriptions d'activités plus détaillés. Ils sont complémentaires ; une organisation peut utiliser SAMM ou BSIMM pour évaluer et améliorer les activités spécifiques qui soutiennent les pratiques SSDF.

Le SSDF peut-il être appliqué à Agile/DevOps ?

Oui, absolument. Le NIST SSDF est conçu pour être agnostique sur le plan méthodologique. Ses pratiques et ses tâches peuvent et doivent être intégrées dans les sprints Agile, les pipelines CI/CD et les flux de travail DevOps (par exemple, l'automatisation des tests de sécurité, la modélisation itérative des menaces).

Qu'est-ce que le formulaire d'attestation de logiciel sécurisé ?

Il s'agit du formulaire requis par le mémo M-22-18 de l'OMB, selon lequel les producteurs de logiciels qui vendent au gouvernement fédéral américain doivent attester que leur logiciel a été développé selon des pratiques sécurisées alignées sur le NIST SSDF.

Le respect du SSDF garantit-il des logiciels sûrs ?

Aucun processus ne peut garantir un logiciel sûr à 100 %. Toutefois, l'application systématique des pratiques SSDF du NIST réduit considérablement la probabilité de vulnérabilités, atténue l'impact des failles et favorise une culture de développement plus sûre, ce qui conduit à des produits logiciels manifestement plus sûrs.