NIS2 : la cybersécurité passe au niveau du code

Temps de lecture : 9 minutes - Mai 2026

La norme NIS2 étend la responsabilité en matière de cybersécurité aux chaînes d'approvisionnement logicielles et aux pratiques de chiffrement. Bien qu'elle n'impose pas de documents spécifiques tels que les nomenclatures logicielles (SBOM) ou les nomenclatures de composants (CBOM), les organisations doivent démontrer leur maîtrise des composants et de la cryptographie au sein de leurs systèmes. La visibilité au niveau du code devient essentielle pour répondre à ces exigences, réduire les risques opérationnels et garantir la conformité réglementaire. L'ENISA a publié un guide technique de mise en œuvre afin d'aider les organisations à traduire ces obligations en pratiques opérationnelles ; ce guide constitue un point de référence pour toute équipe travaillant à définir concrètement les exigences de conformité à la norme NIS2.

La directive NIS2, dont les obligations fondamentales en matière de gestion des risques et de notification des incidents sont définies à l'article 21, est souvent présentée comme un prolongement des cadres de cybersécurité existants, mais son impact opérationnel est plus large. Elle étend les obligations au-delà des opérateurs d'infrastructures critiques à un plus grand nombre de secteurs et introduit des mécanismes de contrôle renforcés, notamment des amendes et une responsabilisation accrue des dirigeants.
 
Plus important encore, cela met l'accent sur le risque systémique. Par conséquent, les organisations doivent gérer non seulement leur propre infrastructure, mais aussi les risques introduits par leurs fournisseurs , prestataires de services et dépendances logicielles. Cette approche est en parfaite adéquation avec les principes énoncés dans le CRA ( Cyber Resilience Act) , qui considère les produits comportant des éléments numériques :matériels, logiciels, sous-systèmes et systèmes, comme un élément fondamental de la sécurité, et non comme un simple composant de soutien.

Concrètement, cela signifie que les organisations doivent comprendre quels logiciels elles utilisent, d'où ils proviennent et comment ils fonctionnent. Les inventaires généraux ne suffisent plus. Sans visibilité sur le code source lui-même, les évaluations des risques restent incomplètes.

La norme NIS2 n'impose pas de normes cryptographiques spécifiques, mais elle érige le chiffrement en priorité stratégique. En vertu de son article 7, les États membres sont tenus de définir des stratégies nationales de cybersécurité incluant des politiques relatives au chiffrement. Ces politiques font explicitement référence à deux domaines.

Le premier point concerne les marchés publics. Les gouvernements devraient inclure des exigences de cybersécurité pour les produits et services TIC, le chiffrement étant présenté comme un élément clé. Cela exerce une pression indirecte sur les fournisseurs et les éditeurs de logiciels et de matériels afin qu'ils fassent preuve de pratiques cryptographiques robustes.

Le second volet concerne la gestion des risques. NIS2 encourage l'adoption de mesures de cybersécurité de pointe, où le chiffrement joue un rôle central. Cela ne se limite pas à la protection des données ; cela inclut également la manière dont les algorithmes cryptographiques sont sélectionnés, mis en œuvre et maintenus dans l'ensemble des systèmes.

La conclusion est sans appel : les organisations doivent être en mesure d’expliquer quels algorithmes elles utilisent, où ils sont utilisés et s’ils restent adaptés à leurs besoins. Cette question prend une importance particulière face à l’essor de l’informatique post-quantique et au renforcement du contrôle réglementaire.

Les nomenclatures logicielles sont devenues une réponse courante aux exigences de la chaîne d'approvisionnement. Elles fournissent une liste structurée de composants, aidant les organisations à identifier les dépendances et à suivre les vulnérabilités.

Cependant, les SBOM présentent des limites. Nombre d'entre elles s'appuient sur les dépendances déclarées, telles que celles figurant dans les manifestes des paquets, plutôt que sur une analyse de code proprement dite. Elles omettent souvent du code copié, des bibliothèques modifiées ou des composants intégrés qui ne font pas l'objet d'un suivi formel. De plus, elles ne prennent pas en compte les fonctions cryptographiques qu'elles implémentent.

Pour NIS2, cela crée une lacune. Les organisations peuvent disposer d'une nomenclature des systèmes de sécurité (SBOM) sans pour autant avoir de visibilité sur les risques critiques tels que les failles de sécurité cryptographiques. Une bibliothèque vulnérable peut être identifiée, mais l'utilisation précise des algorithmes au sein de cette bibliothèque demeure inconnue. Dans un contexte réglementaire, cela compromet la capacité à démontrer le contrôle.

Les CBOM ne sont pas exigées par NIS2, mais elles comblent une lacune que la directive met indirectement en lumière. En se concentrant sur les éléments cryptographiques plutôt que sur les seuls composants, les CBOM permettent de mieux comprendre les algorithmes intégrés aux logiciels.

Le risque cryptographique est souvent hérité plutôt que conçu intentionnellement. Les algorithmes s'intègrent aux systèmes par le biais de dépendances, de logiciels tiers ou de code réutilisé. Au fil du temps, les organisations perdent la trace de l'emplacement et du mode de mise en œuvre du chiffrement.

Une nomenclature de cryptographie (CBOM) met en évidence ces informations. Elle identifie les algorithmes présents dans le code source, y compris ceux dissimulés dans les dépendances ou intégrés sous forme de code copié, permettant ainsi aux équipes de vérifier leur conformité aux normes et exigences réglementaires en vigueur. Nous avons déjà abordé en détail les CBOM dans un autre article ; l’important ici est que, combinées aux données SBOM, elles offrent une vision plus complète des risques logiciels que chacune prise individuellement.

La directive NIS2 ne constitue pas un texte isolé. Elle s'inscrit dans un mouvement réglementaire européen plus vaste, comprenant notamment la loi sur la cyber-résilience et la loi DORA, ainsi que la loi sur l'intelligence artificielle et des cadres sectoriels spécifiques aux services financiers et aux infrastructures critiques.

Un schéma commun se dégage de ces réglementations : les organisations doivent désormais faire preuve d’un contrôle continu sur leurs environnements logiciels. Les documents statiques et les audits périodiques cèdent la place à une exigence de visibilité et de réactivité permanentes.

La CRA, par exemple, impose des obligations directes aux éditeurs de logiciels, notamment en matière de gestion des vulnérabilités et de gestion du cycle de vie. La norme NIS2 complète ce dispositif en se concentrant sur les opérateurs et les fournisseurs de services, garantissant ainsi une gestion des risques à l'échelle de l'écosystème.

Le chiffrement joue un rôle constant dans ces cadres réglementaires. Il est considéré non seulement comme une mesure de sécurité, mais aussi comme un enjeu de gouvernance. Les organisations doivent pouvoir justifier leurs choix, contrôler leur utilisation et s'adapter à l'évolution des normes.

Concrètement, les organisations qui se préparent à la mise en œuvre de NIS2 doivent se concentrer sur trois domaines. Le guide technique d'ENISA propose un cadre opérationnel détaillé pour chacun d'eux et il est judicieux de le consulter en complément de toute évaluation interne de la conformité.

• Visibilité.

Cela implique de comprendre tous les composants logiciels de leurs systèmes, y compris les logiciels libres et les logiciels tiers. Cela requiert également une connaissance approfondie des implémentations cryptographiques.

• Traçabilité.

Les organisations doivent pouvoir relier les composants logiciels à leur origine, à leurs fournisseurs et à leur contexte d'utilisation. Cela facilite l'évaluation des risques et la réponse aux incidents.

• Surveillance continue.

La directive NIS2 témoigne d'un changement fondamental de mentalité en matière de réglementation, une des principales différences entre la directive NIS initiale et sa version ultérieure. Au lieu de considérer la conformité comme un exercice périodique, la directive envisage la gestion des risques comme proactive et systémique, exigeant des inventaires permanents, une réévaluation continue et une réponse rapide aux nouvelles vulnérabilités ou aux évolutions réglementaires.

Ces capacités ne peuvent être obtenues par des processus manuels uniquement. Elles nécessitent une analyse automatisée et une intégration dans les flux de travail de développement et d'exploitation.

Il est facile de considérer NIS2 comme une simple exigence réglementaire supplémentaire. Cependant, elle offre également un cadre pour améliorer la gouvernance des logiciels.

Les organisations qui investissent dans une visibilité accrue bénéficient d'avantages concrets. Elles peuvent réagir plus rapidement aux vulnérabilités et autres risques, réduire l'incertitude liée aux décisions d'achat et concevoir des systèmes plus résilients. Elles sont également mieux préparées à s'adapter aux réglementations futures, notamment celles relatives à la cryptographie et à la préparation à l'informatique post-quantique. Il convient de noter que, NIS2 étant une directive et non un règlement, elle est transposée en droit national par chaque État membre individuellement, ce qui signifie que les modalités de mise en œuvre varient selon les juridictions.

D'un point de vue commercial, cela se traduit par une réduction des risques et une confiance accrue. Clients, partenaires et organismes de réglementation accordent une importance croissante à la transparence. La capacité à démontrer la maîtrise des logiciels et du chiffrement devient un avantage concurrentiel.

La norme NIS2 ne prescrit pas d'outils ou de solutions spécifiques, mais elle énonce une exigence claire : les organisations doivent comprendre et gérer en permanence les risques de cybersécurité inhérents à leurs logiciels et à leurs actifs, et par conséquent, les risques liés aux applications logicielles qui en dépendent.

Pour y parvenir, il faut aller au-delà des inventaires superficiels et obtenir une visibilité permanente au niveau du code.

La priorité n'est pas de produire davantage de documentation, mais d'améliorer la qualité des informations sur lesquelles vous vous appuyez. Cela implique de construire une vue continue et vérifiable des composants logiciels, des algorithmes et de leur provenance.

Si vous cherchez à vous conformer à la norme NIS2 tout en vous préparant à des changements réglementaires plus importants, comme la loi sur la cyber-résilience, il est judicieux d'étudier comment l'analyse du code peut favoriser à la fois la conformité et la résilience opérationnelle. Contactez-nous pour découvrir comment nous pouvons vous aider.