Article 30 du BSIG et votre propre code : les preuves datées qu'une analyse à chaque commit produit

Ce que l'article 30 du BSIG exige réellement

Le texte est plus court que ce que bien des fournisseurs en rapportent. Le paragraphe 1 oblige les entités essentielles et importantes à prendre des mesures techniques et organisationnelles appropriées, proportionnées et efficaces, et se termine par une phrase qui donne le ton de tout audit : le respect de cette obligation doit être documenté. Le paragraphe 2 énumère ensuite ce que ces mesures doivent au minimum couvrir. Le numéro 5 dit : mesures de sécurité lors de l'acquisition, du développement et de la maintenance des systèmes, composants et processus informatiques, y compris la gestion et la divulgation des vulnérabilités. Le numéro 6 ajoute des concepts et procédures pour évaluer l'efficacité de ces mesures.

Deux choses manquent dans ce texte, et elles manquent volontairement. Il n'y a pas de produit dedans, et il n'y a pas de procédure dedans. Le législateur décrit un résultat, à savoir pouvoir connaître, traiter et divulguer les vulnérabilités, et laisse le chemin à l'entité. Quiconque affirme une obligation d'achat pour un analyseur y lit quelque chose qui n'y est pas. Nous l'écrivons sur notre page consacrée à la sécurité du code et à la conformité, et nous l'écrivons ici.

Pourquoi votre propre code relève du numéro 5

Le numéro 5 parle de systèmes, de composants et de processus, pas de logiciel au sens strict. En pratique, pourtant, les vulnérabilités qu'un attaquant trouve en premier sont exactement là : dans une clé API validée il y a trois ans et toujours présente dans l'historique du dépôt, dans une bibliothèque open source dont une faille est publique depuis des mois, ou dans une entrée transmise sans vérification à une base de données. Les trois sont des vulnérabilités au sens de la loi. Les trois naissent lors du développement ou de la maintenance. Et les trois ne peuvent être gérées que si quelqu'un les cherche régulièrement.

C'est précisément là qu'un contrôle annuel échoue. Un résultat de mars ne dit rien du commit de juin. Le numéro 5 n'exige pas de date, mais l'obligation de documentation du paragraphe 1 en exige une, et l'auditeur qui lit le dossier demande d'abord à quel point il est à jour.

Ce qu'une analyse à chaque commit laisse comme preuve

Une analyse continue produit quatre données par résultat, et ce sont exactement les quatre qui ont leur place dans un dossier. D'abord le résultat lui-même : mot de passe codé en dur, dépendance vulnérable, schéma non sécurisé. Ensuite la qualification selon le risque réel, après qu'une personne a vérifié si le résultat est seulement exploitable dans le contexte de la base de code. Puis la mesure : secret renouvelé, bibliothèque mise à jour, schéma neutralisé. Enfin la date à laquelle la mesure a été mise en œuvre.

Au fil des semaines, ces quatre points deviennent une documentation qu'il n'est pas nécessaire de rassembler avant l'audit, parce qu'elle naît en travaillant. Comment cela fonctionne pour les autres obligations NIS2, nous l'expliquons dans notre article sur la constitution des preuves NIS2 au fil de l'eau. Pour le code, le principe est le même, seul l'outil change.

Ce qui a aussi sa place dans le dossier, c'est ce qui n'y figure pas : les faux positifs sont écartés avant d'atteindre le rapport. Un auditeur qui voit 400 résultats dont 380 n'étaient pas exploitables n'en apprend rien sur la sécurité, seulement quelque chose sur l'analyseur.

Ce qu'une preuve ne devrait pas être

Trois formes reviennent sans cesse dans les PME, et aucune ne résiste à une question de suivi. La liste brute d'un analyseur sans qualification : elle prouve qu'un outil a tourné, pas que quelqu'un a agi. La capture d'écran de fin d'année : elle prouve un jour, pas un processus. Et l'autodéclaration dans un questionnaire selon laquelle le développement est sécurisé : elle prouve que quelqu'un a coché une case.

Le numéro 6 du paragraphe 2 le rend encore plus clair. Qui doit évaluer l'efficacité de ses mesures a besoin de données montrant si la mesure a agi dans le temps, ce qu'un instantané unique ne peut pas montrer et qu'une série datée peut.

D'où vient la preuve, étape par étape

Le jour 0, les dépôts sont connectés et l'existant est parcouru une première fois à la recherche de secrets, de dépendances vulnérables et de schémas non sécurisés. Après 48 heures, le premier constat est là : ce qui est réel et critique, ce qui peut attendre, ce qui doit se faire en premier. Durant la première semaine, les secrets critiques sont renouvelés, les bibliothèques mises à jour, les schémas dangereux neutralisés, et chacune de ces mesures reçoit une date. Ensuite, la vérification se poursuit à chaque commit, et le dossier grandit avec le code plutôt qu'avant la date d'audit.

Le point d'entrée est l'analyse de code gratuite : connexion, analyse de l'existant et constat priorisé, sans engagement, dans votre propre environnement sur demande.

Questions fréquentes