NIS2 en un paragraphe
La directive NIS2 (UE 2022/2555) étend les obligations de cybersécurité européennes à environ 160 000 organisations réparties sur 18 secteurs — énergie, transport, banque, santé, infrastructure numérique, fabrication de produits critiques, et plus — classées en entités « essentielles » et « importantes » selon le secteur et la taille (globalement : 250+ salariés ou 50 M€+ de chiffre d'affaires dans les secteurs de l'Annexe I pour le statut essentiel ; 50–249 salariés ou 10–50 M€ de chiffre d'affaires pour le statut important, avec quelques exceptions sous seuil pour les fournisseurs DNS, registres de TLD et similaires). Chaque État membre la transpose en droit national, donc les délais d'application et les autorités de contrôle exactes varient par pays — cette page décrit la directive elle-même, pas une transposition nationale particulière.
Article 21(2) : les 10 catégories de mesures
L'article 21(2) impose aux entités de mettre en œuvre des mesures couvrant au moins ces dix catégories — citées directement depuis le texte de la directive :
| § | Mesure |
|---|---|
| (a) | Politiques d'analyse des risques et de sécurité des systèmes d'information |
| (b) | Gestion des incidents |
| (c) | Continuité d'activité, telle que la gestion des sauvegardes et la reprise après sinistre, et gestion de crise |
| (d) | Sécurité de la chaîne d'approvisionnement, y compris les aspects sécurité concernant les relations avec les fournisseurs ou prestataires directs |
| (e) | Sécurité de l'acquisition, du développement et de la maintenance des réseaux et systèmes d'information, y compris la gestion et la divulgation des vulnérabilités |
| (f) | Politiques et procédures pour évaluer l'efficacité des mesures de gestion des risques de cybersécurité |
| (g) | Pratiques de base en matière d'hygiène informatique et formation à la cybersécurité |
| (h) | Politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement |
| (i) | Sécurité des ressources humaines, politiques de contrôle d'accès et gestion des actifs |
| (j) | Authentification multifacteur ou continue, communications vocales, vidéo et textuelles sécurisées et systèmes de communication d'urgence sécurisés |
Les lignes en surbrillance sont les deux catégories pour lesquelles un scan de code source peut réellement produire des preuves. Les huit autres sont des mesures organisationnelles, procédurales ou d'infrastructure — aucun outil d'analyse statique n'y touche.
Où StaticCodeAudit se situe réellement
(e) Gestion et divulgation des vulnérabilités
Un export SARIF 2.1.0 est exactement le type d'enregistrement de vulnérabilités structuré et exploitable par machine que demande cette catégorie : un scan lancé sur un commit donné, avec pour chaque finding sa règle, sa sévérité, son fichier et sa ligne — la preuve qu'une gestion des vulnérabilités a eu lieu à un moment précis du cycle de développement, pas juste une affirmation qu'elle a lieu.
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-high(d) Sécurité de la chaîne d'approvisionnement
Un SBOM CycloneDX 1.5 liste chaque dépendance embarquée par un code — nom, version, Package URL. Combiné aux findings SARIF du même scan, c'est le type d'artefact qu'un relecteur procurement ou un auditeur peut utiliser pour évaluer « la qualité globale des produits et pratiques de cybersécurité » d'un fournisseur, l'une des sous-considérations que NIS2 rattache à cette catégorie.
./staticcodeaudit-linux-x86_64 /path/to/project --sbomUn point secondaire qui mérite d'être explicite
L'article 21(2)(d) demande aussi aux entités de peser les pratiques de cybersécurité de leurs propres fournisseurs — y compris si les outils de ces fournisseurs introduisent de nouveaux flux de données. Un scanner hors-ligne qui n'envoie jamais le code source où que ce soit n'ajoute pas de nouvelle dépendance SaaS à l'empreinte de risque chaîne d'approvisionnement du code lui-même, contrairement à un éditeur SAST cloud qu'une équipe sécurité devrait ensuite aussi évaluer.
Ce que cela ne couvre pas — la liste honnête
Huit des dix catégories sont hors de portée d'un scanner de code source, et aucun volume de scan ne change cela :
- (a) Analyse des risques et politiques de sécurité — un processus organisationnel, pas un artefact de code.
- (b) Gestion des incidents — demande un processus de réponse et une équipe, pas un scan.
- (c) Continuité d'activité et reprise après sinistre — infrastructure et processus, sans rapport avec le code source.
- (f) Politiques d'évaluation de l'efficacité — une activité de gouvernance.
- (g) Formation à l'hygiène informatique — une activité humaine.
- (h) Politique de cryptographie — une politique écrite ; un scan peut signaler un algorithme faible dans le code (contribuant au chapitre V11 de l'ASVS) mais ne peut ni rédiger ni approuver la politique elle-même.
- (i) Sécurité RH et politique de contrôle d'accès — organisationnel, pas au niveau du code.
- (j) MFA et communications sécurisées — une décision d'infrastructure/déploiement, pas une propriété du code source.
Questions fréquentes
Utiliser StaticCodeAudit rend-il mon organisation conforme à NIS2 ?
Aucun outil seul ne le fait. La conformité NIS2 est une obligation organisationnelle couvrant les dix catégories de l'article 21(2), dont la plupart relèvent de politiques et de processus, pas de logiciels. StaticCodeAudit produit des preuves utilisables pour deux d'entre elles — (d) et (e) — dans le cadre d'un programme de conformité plus large, pas en remplacement de celui-ci.
Suis-je même dans le périmètre de NIS2 ?
Le périmètre dépend de votre secteur (l'un des 18 listés en Annexe I ou II de la directive) et de votre taille (globalement 50+ salariés ou 10 M€+ de chiffre d'affaires, avec des seuils précis et quelques exceptions sous seuil). C'est une détermination juridique à faire par le conseil ou le responsable conformité de votre organisation, pas quelque chose qu'une sortie de scanner peut trancher.
La sortie SARIF/SBOM référence-t-elle NIS2 directement ?
Non — les exports sont des formats standards (OASIS SARIF 2.1.0, OWASP CycloneDX 1.5) sans champ spécifique à NIS2. Le lien avec l'article 21(2) réside dans la façon dont la preuve est utilisée par votre processus de conformité, pas dans un encodage du fichier lui-même.
Quel est le rapport avec les matrices ISO 27001 et ASVS de la page standards ?
NIS2 n'impose pas de norme technique spécifique, mais les États membres et autorités de contrôle référencent couramment l'ISO/IEC 27001 et des référentiels similaires comme preuve de mesures « à l'état de l'art ». Les matrices de conformité générées par chaque scan (ISO 27001 Annexe A, ASVS, NIST CSF) peuvent servir de matériel de soutien dans cette conversation plus large, aux mêmes conditions honnêtes : une couverture partielle, visible dans le code uniquement.
Voir les preuves réelles que produit un scan
Ouvrez le rapport de démonstration en ligne — sans installation, sans inscription — et regardez directement les exports SARIF/SBOM et les matrices de conformité.
Ouvrir le rapport en ligne En savoir plus sur la page secteurs réglementés