Un analyseur de code est-il obligatoire selon NIS2 ?
Réponse courte : non. Ni NIS2 ni la loi allemande de transposition ne prescrivent un produit d'analyse. Elles exigent la sécurité lors du développement et de la maintenance, gestion des vulnérabilités comprise (article 30, paragraphe 2, numéro 5 du BSIG), et la documentation du respect de cette obligation. Ce que cela signifie pour qui exploite ses propres logiciels, en cinq réponses.

La réponse courte
Non. Il n'existe dans la directive NIS2 ni dans la loi allemande sur le BSI aucune disposition exigeant un analyseur de code, un produit d'analyse ou une méthode de vérification particulière. Qui entend le contraire devrait demander la référence. Elle n'existe pas.
Ce qui est exigé à la place
L'article 21, paragraphe 2, point e de la directive exige des entités concernées la sécurité lors de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris la gestion et la divulgation des vulnérabilités. L'Allemagne l'a transposé presque mot pour mot à l'article 30, paragraphe 2, numéro 5 du BSIG. Le paragraphe 1 du même article ajoute que le respect de l'obligation doit être documenté, et le numéro 6 exige des procédures pour évaluer l'efficacité des mesures.
C'est toute l'obligation : connaître les vulnérabilités, les traiter, les divulguer, documenter, évaluer. Comment une entité y parvient, la loi le lui laisse. Pour votre propre code, les vulnérabilités sont essentiellement les identifiants codés en dur, les dépendances vulnérables et les schémas non sécurisés ; comment une analyse continue les prouve est expliqué dans notre article sur la constitution des preuves NIS2 au fil de l'eau et sur notre page consacrée à la sécurité du code et à la conformité.
Pourquoi nous recommandons quand même l'analyse
Parce que l'obligation de documentation du paragraphe 1 est, en pratique, le goulot d'étranglement. On peut aussi gérer les vulnérabilités par une revue manuelle annuelle. Ce qui manque alors, c'est la preuve pour le temps entre deux. Une analyse à chaque commit laisse derrière chaque résultat une qualification, une mesure et une date, et ce dossier se constitue en travaillant plutôt qu'avant la date d'audit. C'est la raison de la recommandation, pas une obligation qui n'existe pas.
Ce que l'analyse ne peut pas faire, et ce que cela signifie pour l'obligation
Un analyseur trouve ce qui a un schéma. Les erreurs de logique métier, par exemple une logique d'autorisation fausse sur le plan métier, il ne les trouve pas, et il ne juge pas les décisions de conception. Mais l'obligation du numéro 5 ne s'arrête pas à la limite de l'outil. Qui veut la remplir entièrement a besoin, en plus de l'analyse, d'une vérification périodique de ce qui n'a pas de schéma, en général un test d'intrusion. Lui non plus n'est pas prescrit. Lui aussi est un chemin vers le résultat exigé.
À qui la question s'applique seulement
L'article 30 du BSIG s'adresse aux entités essentielles et importantes. Qu'une entreprise en fasse partie dépend du secteur et de la taille ; notre vérification rapide NIS2 le règle en quelques minutes. Et indépendamment de NIS2 : qui n'écrit aucun logiciel et n'exploite aucun logiciel acheté en interne n'a rien à analyser. Qui a l'un ou l'autre a des vulnérabilités à gérer, que la directive le vise ou non. Si cela en vaut la peine, l'analyse de code gratuite le montre, sans engagement.
Questions fréquentes
Le mot analyseur figure-t-il quelque part dans la loi ?
Non. Ni à l'article 21 de la directive ni à l'article 30 du BSIG. Ce qui est exigé, c'est la gestion des vulnérabilités lors du développement et de la maintenance et sa documentation, pas un produit.
Un test d'intrusion annuel suffit-il alors à remplir l'obligation ?
Il prouve le jour du test. L'obligation vise le traitement continu des vulnérabilités et sa documentation. Le temps entre deux tests a aussi besoin d'une preuve, et une analyse continue est le moyen le plus simple d'en produire une.
Nous ne relevons pas de NIS2. La question est-elle réglée pour nous ?
L'obligation, oui ; le risque, non. Une clé codée en dur dans un dépôt est un mot de passe ouvert, loi ou pas. Si cela vaut la peine de regarder, le constat de l'analyse gratuite vous le dira.