Développement sécurisé selon NIS2, ISO 27001 et CRA. Ce qui est exigé, ce qu'une analyse continue prouve.
Quatre référentiels parlent de la sécurité de votre propre code. Aucun ne prescrit un produit d'analyse. Cette page montre où se trouve chaque exigence, dit ouvertement là où aucune obligation expresse n'existe, et précise quelle preuve une analyse à chaque commit apporte pour chacune.
Quiconque se voit demander en audit comment les vulnérabilités de son propre code sont traitées a besoin de deux choses : la bonne référence dans le texte et une preuve datée. Cette page fournit la première. La seconde naît de l'analyse continue, avec le résultat, la mesure et la date.
Où le développement sécurisé se trouve réellement.
Deux sont des catalogues d'obligations, un ne s'applique qu'aux fabricants, un n'est pas une loi du tout. La différence décide de ce que vous devez présenter en audit.
Sécurité lors de l'acquisition, du développement et de la maintenance
Le catalogue de mesures de la directive consacre un point propre au traitement des systèmes sur tout leur cycle de vie : acquérir, développer, maintenir, gérer et divulguer les vulnérabilités. L'Allemagne l'a transposé à l'article 30, paragraphe 2, numéro 5 du BSIG (loi allemande sur la sécurité informatique). Quiconque exploite son propre code relève de ce point avec chacune de ses failles. La manière de les trouver, le législateur la laisse ouverte.
Cycle de vie de développement sécurisé
Avec la révision de 2022, la norme a donné au développement sécurisé quatre numéros qui lui sont propres : le cycle de vie du développement (A.8.25), les exigences de sécurité applicative (A.8.26), le codage sécurisé lui-même (A.8.28) et, en transversal, la gestion technique des vulnérabilités (A.8.8). Un auditeur interroge chacun de ces numéros séparément.
Obligations pour les produits comportant des éléments numériques
À la différence de NIS2, le règlement ne vise pas les exploitants mais ceux qui mettent sur le marché des logiciels ou des appareils connectés. Pour eux, la responsabilité commence avec la mise sur le marché et ne s'arrête pas là. Échelonné dans le temps : en vigueur depuis le 10 décembre 2024, notification des vulnérabilités activement exploitées depuis le 11 septembre 2026, les autres obligations à partir du 11 décembre 2027. Une entreprise qui n'utilise des logiciels qu'en interne ne figure pas sur cette liste.
Le cadre de référence technique
Le Top 10 est un classement, pas une règle : les dix classes de risque qui conduisent le plus souvent à des incidents dans les applications, reclassées tous les quelques années. Dans l'édition 2025, le contrôle d'accès défaillant arrive en tête, et la chaîne d'approvisionnement logicielle entre pour la première fois dans les trois premiers. Nous utilisons la liste comme ordre d'évaluation des résultats. Qui la vend comme un certificat ne l'a pas lue.
Pour lever toute ambiguïté avant que quelqu'un n'y lise une obligation d'achat : aucun des quatre textes ne prescrit un analyseur. Ce qui est exigé est un résultat, à savoir connaître, évaluer et corriger les vulnérabilités, et non un produit. Et le CRA ne s'applique qu'aux fabricants. Ce qu'une analyse continue apporte, c'est la documentation de ce résultat avec une date. Nous n'affirmons rien de plus.
Quelle preuve correspond à quelle référence.
Un audit demande rarement l'outil. Il demande si une exigence est mise en œuvre et avec quoi vous le montrez. Voici la correspondance.
- Gestion des vulnérabilités
Article 30 du BSIG, ISO A.8.8
Toutes les dépendances sont vérifiées contre les vulnérabilités connues. Lorsqu'une bibliothèque est mise à jour, le résultat, la mesure et la date figurent dans la documentation.
- Codage sécurisé
ISO A.8.28
Les schémas non sécurisés tels que les entrées non validées, les appels système dangereux et les contrôles d'accès manquants sont détectés à chaque commit, et non une fois par an à la date de l'audit.
- Gestion des identifiants
Article 30 du BSIG, ISO A.8.28
Les mots de passe, clés et jetons codés en dur sont trouvés, y compris dans l'historique du dépôt, et les secrets critiques sont renouvelés plutôt que simplement signalés.
- Cycle de vie du développement
ISO A.8.25, A.8.26
Chaque modification est évaluée dans le contexte de la base de code avant que le code ne poursuive son chemin. C'est la preuve que la sécurité est dans le processus et pas seulement dans le rapport annuel.
Trois choses qu'une analyse ne fait pas. Et que nous n'affirmons pas.
Elle ne remplace pas un test d'intrusion.
L'analyse travaille à un seul endroit : dans le code, à chaque modification, contre des schémas connus. Un test d'intrusion part de l'extérieur et tente de franchir le système en fonctionnement dans son ensemble, réseau, configuration et personnes compris. Avoir l'un ne donne pas l'autre. Ce qu'un test doit fournir et ce qui se passe après le rapport figure sur notre page consacrée au test d'intrusion.
Elle ne trouve pas les erreurs de logique métier.
Savoir si un gestionnaire peut voir les factures d'un autre service n'est écrit dans aucun schéma, mais dans les règles du métier. Aucune analyse automatique ne détecte ces erreurs de logique d'autorisation, et une preuve qui prétendrait le contraire serait fausse. Nous ne l'écrivons pas.
Elle n'est pas un certificat.
L'analyse produit des preuves pour des contrôles individuels. Un système de management, une certification ou l'évaluation d'efficacité prévue à l'article 30 du BSIG restent des étapes distinctes qu'elle soutient sans les prendre en charge.
De la connexion au dossier daté.
Connexion
Nous raccordons vos dépôts, puis passons une première fois sur tout le code existant : secrets, dépendances vulnérables, schémas non sécurisés.
Premier constat
Un rapport clair : quels résultats sont réels et critiques, lesquels peuvent attendre et ce qui doit se passer en premier.
Nettoyage
Les secrets critiques sont renouvelés, les bibliothèques vulnérables mises à jour, les schémas dangereux désamorcés, et chaque mesure porte une date.
Prouver
À partir de maintenant, à chaque commit. Les nouveaux résultats critiques sont traités immédiatement, et la documentation grandit avec le travail au lieu d'être rassemblée avant l'audit.
Questions sur la sécurité du code et la conformité
Un analyseur de code est-il obligatoire selon NIS2 ?
Non. Ce qui est prescrit, c'est le résultat : pouvoir connaître, traiter et divulguer les vulnérabilités de ses propres systèmes, article 30 du BSIG. La manière dont une entreprise y parvient lui appartient. Si nous recommandons malgré tout l'analyse, c'est pour la preuve : elle laisse derrière chaque résultat une date et une mesure, et c'est exactement ce qu'une autorité de surveillance demande.
Le Cyber Resilience Act s'applique-t-il à notre entreprise ?
La question est de savoir si vous vendez quelque chose contenant du logiciel : une machine avec sa commande, un appareil avec une application, un produit logiciel. Vous êtes alors fabricant au sens du règlement, et les délais courent, depuis le 11 septembre 2026 pour la notification des vulnérabilités exploitées, à partir du 11 décembre 2027 pour le reste. Si vous n'utilisez des logiciels que pour vous-mêmes, le CRA ne vous concerne pas, NIS2 éventuellement si.
L'analyse suffit-elle comme preuve pour ISO 27001 ?
Elle étaye les contrôles A.8.25, A.8.26 et A.8.28 sur le développement sécurisé ainsi que A.8.8 sur la gestion des vulnérabilités avec des résultats et des mesures datés. Un système de management et la certification elle-même restent des étapes distinctes que l'analyse soutient sans les remplacer.
Que contient concrètement la preuve ?
Pour chaque résultat, l'évaluation selon le risque réel, la mesure mise en œuvre et la date : secret renouvelé, bibliothèque mise à jour, schéma neutralisé. Les faux positifs sont écartés avant d'atteindre le dossier.
Cela remplace-t-il un test d'intrusion ?
Non. Les deux vérifications répondent à des questions différentes : l'analyse, si des classes de failles connues se trouvent dans le code ; le test, si un attaquant passe depuis l'extérieur. Un auditeur qui veut voir un test d'intrusion n'accepte pas un rapport d'analyse à la place, et inversement.
Quelles preuves vous manquent aujourd'hui pour l'article 30 du BSIG ou A.8.28 ?
Analyse de code gratuite, résultat clair, sans engagement.