nis2-pro.frTrouvez un prestataire →
5Mesure n° 5 · Article 21 §2

Sécurité de l'acquisition, du développement et de la maintenance (Article 21 NIS2) — Guide opérationnel pour entités régulées

L'article 21 §2 alinéa (e) de la directive NIS2 impose aux entités essentielles et importantes de garantir « la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités ». Cette mesure inscrit la sécurité dans le cycle de vie complet du système d'information — depuis l'expression de besoin et l'achat jusqu'au décommissionnement, en passant par le développement interne, l'intégration de composants tiers, la mise en production et la correction de vulnérabilités. L'enjeu : éviter que des failles ne s'enracinent dès la conception ou ne se propagent via la chaîne d'approvisionnement logicielle.

La mesure ne se limite pas à une exigence ponctuelle lors d'un audit de code ; elle demande une démarche structurée de secure development lifecycle (SDLC) articulée avec la gestion de la chaîne d'approvisionnement (mesure n°4), l'analyse de risques (mesure n°1) et l'évaluation de l'efficacité (mesure n°6). Selon le rapport Verizon 2025, 30 % des violations impliquent désormais un tiers, et Sonatype a recensé 512 847 paquets malveillants en 2024, soit une hausse de 156 % en un an. Dans ce contexte, sécuriser le développement et les achats de logiciels devient un levier structurant de conformité NIS2.

Ce que dit l'article 21 §2 — texte de la mesure et intention du législateur

L'article 21 §2 (e) exige « la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités ». Le texte européen distingue trois phases critiques :

  1. Acquisition : achat ou intégration de logiciels tiers, composants open source, services SaaS, infrastructures cloud — avec évaluation de la sécurité du fournisseur et traçabilité des dépendances (SBOM).
  2. Développement : création, modification ou extension de code applicatif, en interne ou par prestataire, avec intégration de contrôles de sécurité à chaque étape (requirements, design, build, test).
  3. Maintenance : gestion des correctifs de sécurité (patch management), déploiement de mises à jour, gestion du cycle de vie des versions, décommissionnement sécurisé.

L'alinéa « traitement et divulgation des vulnérabilités » impose un processus formalisé de vulnerability management et de coordinated disclosure : détection, qualification, remédiation, communication responsable — en ligne avec les pratiques du CERT-FR. MonEspaceNIS2 rappelle que cette mesure garantit « un niveau de sécurité adapté et proportionné au risque existant en tenant compte de l'état des connaissances et, s'il y a lieu, des normes européennes et internationales applicables ».

Référentiels et standards qui s'articulent avec cette mesure

La mesure n°5 NIS2 s'inscrit dans un paysage normatif mature. Les référentiels suivants fournissent des lignes directrices opérationnelles :

ISO/IEC 27001:2022 – Contrôle 8.25 (Secure Development Life Cycle) L'ISO 27001:2022 Annexe A 8.25 exige que des règles de sécurité soient définies et appliquées tout au long du cycle de vie de développement logiciel. Le contrôle couvre la séparation des environnements (dev/test/prod), la revue de code, les tests de sécurité (SAST/DAST), la formation des développeurs (Annexe A 8.28) et la gestion des secrets. Les organisations doivent démontrer un scanning de vulnérabilités à plusieurs points : développement, tests et post-déploiement.

NIST SSDF (SP 800-218) Le Secure Software Development Framework du NIST est un ensemble de pratiques de haut niveau intégrables dans chaque implémentation SDLC. La version 1.1 (février 2022) structure les pratiques en quatre groupes : Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) et Respond to Vulnerabilities (RV). Le SSDF s'appuie sur les documents de BSA, OWASP et SAFECode et doit être ajouté à chaque modèle SDLC pour adresser la sécurité logicielle en détail. Une révision 1.2 a été publiée en décembre 2025.

OWASP Top 10 et OWASP SAMM L'OWASP Top 10 liste les 10 risques applicatifs les plus critiques (injection, broken authentication, XSS, etc.). Le Top 10:2025 classe les « Software Supply Chain Failures » comme risque n°3, avec 50 % des répondants du sondage communautaire le plaçant en première position. L'OWASP Software Assurance Maturity Model (SAMM) propose un cadre pour évaluer et améliorer la maturité du SDLC sécurisé sur cinq domaines (Governance, Design, Implementation, Verification, Operations).

IEC 62443 (pour systèmes OT/industriels) Le standard IEC 62443-4-1 définit les exigences de développement de produits de contrôle-commande sécurisés, avec un cycle de développement sécurisé (SDL) adapté aux environnements industriels (énergie, eau, transports). Pertinent pour les secteurs énergie, transports et gestion de l'eau.

ANSSI – Guides techniques et recommandations L'ANSSI publie des guides de configuration permettant d'obtenir un système raisonnablement sûr par le respect de principes fondamentaux. Le guide « Sécuriser un système GNU/Linux », les recommandations TLS, les guides sur la journalisation et l'authentification fournissent un socle technique. L'ANSSI sélectionne chaque année des logiciels open source pour des audits CSPN ou « à façon » afin de renforcer le niveau de cybersécurité de ses bénéficiaires et de soutenir l'écosystème open source.

Référentiel Général de Sécurité (RGS) v2.0 Pour les administrations et organismes publics, le RGS fixe les règles de sécurité applicables aux systèmes d'information. Il couvre notamment l'homologation de sécurité, la gestion des risques et les exigences de sécurisation du développement.

Mise en œuvre opérationnelle — étapes concrètes pour une entité régulée

1. Cartographier le patrimoine applicatif et les flux de développement

  • Inventaire complet des applications (internes, SaaS, on-premise) et identification du mode de développement (interne, prestataire, éditeur).
  • Diagramme de flux : qui développe quoi, quelles plateformes CI/CD, quels dépôts de code (GitLab, GitHub, Azure DevOps), quels registres d'artefacts (container registry, npm, PyPI).
  • Identifier les environnements : développement, intégration, staging, pré-production, production, DMZ.

2. Définir une politique de développement sécurisé (Secure SDLC Policy)

  • Document formel validé par la direction (article 20 NIS2 : gouvernance).
  • Définir les rôles : Security Champion, Architecte sécurité, Responsable Qualité, développeurs, QA.
  • Intégrer les exigences de sécurité dès la phase de spécification fonctionnelle (security requirements).
  • Clauses contractuelles : pour tout développement externalisé, exiger du prestataire un SDLC sécurisé équivalent (références ISO 27001 Annexe A 8.25, NIST SSDF).

3. Intégrer la sécurité dans chaque phase du cycle de vie

Phase Requirements (Expression de besoin)

  • Analyse de risques applicative : identifier les données sensibles traitées, les fonctions critiques, les menaces spécifiques (STRIDE, OWASP ASVS).
  • Rédaction de security user stories : « En tant que RSSI, je veux que l'application chiffre les données au repos (AES-256) pour protéger la confidentialité. »

Phase Design (Conception)

  • Threat modeling (modélisation des menaces) : STRIDE, PASTA ou LINDDUN selon le contexte.
  • Architecture sécurisée : principe du moindre privilège, segmentation réseau, chiffrement bout-en-bout, gestion des secrets (coffre-fort type HashiCorp Vault, Azure Key Vault).
  • Revue d'architecture par un Security Architect.

Phase Development (Développement)

  • Formation développeurs : sensibilisation OWASP Top 10, secure coding (éviter les injections SQL, XSS, CSRF, gestion sécurisée des sessions).
  • Standards de codage sécurisé documentés (référence OWASP Secure Coding Practices, CERT Secure Coding Standards).
  • SAST (Static Application Security Testing) intégré dans la CI/CD : SonarQube, Checkmarx, Fortify, Semgrep.
  • SCA (Software Composition Analysis) pour dépendances open source : Snyk, Dependabot, OWASP Dependency-Check. Génération et maintien d'un SBOM (Software Bill of Materials) au format CycloneDX ou SPDX.
  • Gestion des secrets : pas de clés API, mots de passe ou certificats en dur dans le code, utilisation de secret scanning (GitGuardian, TruffleHog).

Phase Testing (Tests)

  • DAST (Dynamic Application Security Testing) : OWASP ZAP, Burp Suite, Acunetix, tests en environnement de pré-production.
  • IAST (Interactive Application Security Testing) si applicable.
  • Pentest applicatif (annuel ou avant chaque mise en production majeure) : faire appel à un PASSI qualifié ANSSI.
  • Fuzzing pour identifier les crashs et comportements anormaux.

Phase Deployment (Déploiement)

  • Pipeline CI/CD sécurisé : signature des artefacts (cosign, GPG), vérification d'intégrité, déploiement automatisé avec validation de sécurité (policy-as-code : OPA, Kyverno).
  • Environnements séparés : pas d'accès développeur en production sauf break-glass procédure auditée.
  • Rollback plan documenté et testé.

Phase Maintenance (Exploitation continue)

  • Patch management : processus de veille sur CVE (NVD, CERT-FR, éditeurs), classification par criticité (CVSS), délais de correction formalisés (critique < 7j, haute < 30j, etc.).
  • Gestion des end-of-life : décommissionnement sécurisé des versions obsolètes, migration planifiée.
  • Divulgation coordonnée : canal de signalement de vulnérabilité (« security.txt », adresse email dédiée), processus interne de triage, correction, communication au CERT-FR si applicable.

4. Formaliser le processus de gestion des vulnérabilités

  • Détection : veille CVE, scans automatisés (Nessus, Qualys, Rapid7), bug bounty ou VDP (Vulnerability Disclosure Program).
  • Qualification : score CVSS, exploitabilité (EPSS), impact métier.
  • Remédiation : correctif, workaround, désactivation de fonctionnalité.
  • Communication : notification CERT-FR si système d'importance nationale, divulgation publique après correction (délai raisonnable : 90 jours selon Google Project Zero).

5. Documenter et tracer

  • Registre des projets de développement avec niveau de risque, périmètre, responsable sécurité.
  • Traçabilité des revues de sécurité (design review, code review, pentest reports).
  • RACI clair : qui valide quoi à quelle étape.

Prestataires ANSSI à mobiliser pour cette mesure

PASSI (Prestataire d'Audit de la Sécurité des Systèmes d'Information) Intervention en phase de test et validation : audit de code (SAST/DAST), pentest applicatif, revue d'architecture. Le PASSI produit un rapport de vulnérabilités avec recommandations de correction. Pour les OIV, le PASSI-LPM est requis.

PACS (Prestataire d'Accompagnement et de Conseil en Sécurité) Aide à la définition de la politique SDLC sécurisé, formation des équipes (DevSecOps, secure coding), mise en place de pipelines CI/CD avec contrôles de sécurité intégrés.

PDIS (Prestataire de Détection des Incidents de Sécurité) Surveillance continue en production (SIEM, EDR applicatif) pour détecter exploitation de vulnérabilités, comportements anormaux post-déploiement, signes de compromission via une faille logicielle.

PRIS (Prestataire de Réponse aux Incidents de Sécurité) Intervention en cas d'exploitation avérée d'une vulnérabilité (incident 0-day, attaque par supply chain compromise). Le PRIS mène l'analyse forensique, identifie le vecteur d'attaque, aide à la remédiation et au durcissement post-incident.

Hébergeurs SecNumCloud Pour les applications critiques hébergées en cloud, retenir un prestataire SecNumCloud garantit un niveau de confiance élevé sur l'infrastructure sous-jacente (conformité RGS, ANSSI).

Outils techniques recommandés pour la sécurité du développement

Analyse statique de code (SAST)

  • SonarQube (open source / édition entreprise) : détection de code smell, bugs, vulnérabilités (OWASP Top 10, CWE).
  • Semgrep : règles personnalisables, rapide, open source.
  • Checkmarx / Fortify / Veracode : solutions commerciales robustes pour environnements d'entreprise.

Analyse de composition logicielle (SCA)

  • Snyk : scans des dépendances npm, Maven, pip, Docker images ; intégration CI/CD.
  • Dependabot (GitHub) : alertes automatiques sur CVE dans les dépendances.
  • OWASP Dependency-Check : gratuit, génération de rapports SBOM CycloneDX.
  • Syft / Grype (Anchore) : génération SBOM et scan de vulnérabilités containers.

Analyse dynamique (DAST)

  • OWASP ZAP : scanner open source, proxy d'interception, idéal pour tests automatisés.
  • Burp Suite Pro : référence pour pentest manuel et automatisé.
  • Acunetix / Qualys WAS : solutions commerciales avec couverture large.

Gestion des secrets

  • HashiCorp Vault : coffre-fort de secrets, rotation automatique, audit trail.
  • Azure Key Vault / AWS Secrets Manager / GCP Secret Manager : services cloud natifs.
  • GitGuardian / TruffleHog : détection de secrets exposés dans le code.

Pipeline CI/CD sécurisé

  • GitLab CI / GitHub Actions / Azure Pipelines : intégration native SAST/SCA.
  • Trivy (Aqua Security) : scan de vulnérabilités containers, IaC (Terraform, Kubernetes manifests).
  • Cosign / Sigstore : signature et vérification cryptographique des artefacts.

Gestion de vulnérabilités et patch management

  • Nessus / Qualys / Rapid7 InsightVM : scan infrastructure et applicatif.
  • Nuclei (ProjectDiscovery) : détection de CVE via templates, rapide, open source.
  • Patch management OS : WSUS (Windows), Landscape (Ubuntu), Ansible Automation Platform.

Cas d'incidents documentés où l'absence de sécurité du développement a aggravé l'impact

SolarWinds (2020, révélé déc. 2020) SolarWinds est le plus grand exemple connu d'attaque supply chain logicielle : plus de 18 000 organisations affectées, avec un coût estimé à 11 % du chiffre d'affaires en moyenne. Les attaquants ont compromis la plateforme de build pour insérer un backdoor (SUNBURST) dans la mise à jour Orion signée. Défaillance : absence de sécurisation de l'environnement de build, pas de revue de code de sécurité avant release, pas de détection d'anomalie binaire.

3CX (mars 2023) L'attaque 3CX a débuté par la compromission d'un logiciel Trading Technologies téléchargé par un employé 3CX, permettant aux attaquants de pivoter vers le processus de build 3CX et d'infecter les mises à jour poussées à tous les clients. Une cascade : fournisseur → développeur → clients. Leçon : même un éditeur de logiciel de sécurité (VoIP) peut être vecteur d'attaque si son SDLC n'est pas durci.

MOVEit Transfer (mai 2023) L'exploitation d'une faille 0-day dans MOVEit Transfer par le groupe Cl0p a affecté plus de 1000 clients, exposant les données personnelles d'environ 60 millions d'individus. Vulnérabilité SQL injection non détectée en amont ; absence de SAST/DAST efficace lors du développement. Impact financier : gains estimés pour Cl0p à plus de 100 millions de dollars.

Attaque Snowflake via vol de credentials (avril 2024) Une plateforme cloud de données a subi une intrusion via des credentials volés par infostealer malware, compromettant 165 clients représentant plus de 500 millions d'individus. Bien qu'il s'agisse d'un incident credential-based, l'absence de MFA obligatoire en phase de design et la gestion insuffisante des secrets (mot de passe stocké côté client) ont amplifié l'impact.

Failles massives sur équipements de sécurité (2023-2024) Le CERT-FR a traité en 2023-2024 plusieurs vulnérabilités critiques dans pare-feux et passerelles VPN, d'abord exploitées en 0-day à des fins d'espionnage puis massivement par des groupes cybercriminels pour du ransomware. L'absence de mise à jour rapide et de procédure de patch emergency a conduit à des compromissions prolongées.

Sanctions et risques en cas de non-conformité

Sanctions administratives (Loi Résilience / NIS2)

  • Entités essentielles : jusqu'à 2 % du chiffre d'affaires annuel mondial ou 10 M€.
  • Entités importantes : jusqu'à 1,4 % du CA mondial ou 7 M€.
  • Les manquements couverts incluent : absence de mesures techniques de sécurité du développement, non-application de correctifs critiques dans un délai raisonnable, absence de processus de divulgation coordonnée.

Risques opérationnels et financiers

Risque de cumul réglementaire

Une entité régulée NIS2 peut également être soumise au RGPD (notification CNIL sous 72 h en cas de violation de données personnelles), à DORA (secteur financier), CRA (Cyber Resilience Act pour produits avec éléments numériques), voire à la LPM pour les OIV. Un défaut de patch management peut ainsi déclencher plusieurs procédures de contrôle et sanctions en parallèle.

Ressources officielles

← 4. Sécurité de la chaîne d'approvisionnementToutes les mesures6. Évaluation de l'efficacité des mesures →