L'enregistrement des incidents en développement logiciel concerne deux choses différentes qui sont souvent confondues : une vulnérabilité ou une défaillance dans le logiciel que vous développez et livrez, et un incident dans votre propre environnement de développement — l'environnement dans lequel vous créez ce logiciel. Ce que vous enregistrez, qui doit le savoir et quelle action de suivi s'ensuit, varie selon le type. Ceux qui ne font pas cette distinction manquent souvent l'incident qui compte le plus : une contamination dans le pipeline de construction qui se propage via le code à tous les clients qui en dépendent.
Une vulnérabilité dans le code livré affecte directement le client : il exécute le logiciel, il court donc le risque. Un incident dans l'environnement de développement — une clé d'accès volée, un compte de construction compromis, une fuite dans le référentiel de code source — vous affecte en première instance, mais peut s'étendre à chaque client qui travaille avec ce code. Pour les deux, un questionnaire de sécurité ou un auditeur ne demande pas s'il y a jamais eu un problème, mais si vous pouvez montrer ce que vous en avez enregistré et appris.
Ce que vous enregistrez en cas d'incident dans le code
Pour une vulnérabilité ou une défaillance dans un logiciel livré, il s'agit de : quand elle a été découverte, par qui ou quoi (test interne, signalement du client, balayage, chercheur externe), quelle partie du logiciel elle affecte, quel est l'effet possible, quelle action a été prise et à quelle date, et qui au sein de votre organisation est responsable du suivi. Un bon enregistrement montre également si un correctif a été déployé auprès de tous les clients qui utilisent la version concernée, ou seulement auprès de celui qui l'a signalée. Ce dernier est exactement ce qu'un utilisateur demande dans un questionnaire : non pas si vous aviez une vulnérabilité, mais si votre processus garantit que tous ceux qui en sont affectés en sont informés.
Ce que vous enregistrez en cas d'incident dans l'environnement de développement
Un incident dans votre propre environnement de développement — un compte compromis ayant accès au code source, un serveur de construction qui réagit différemment que prévu, une dépendance qui s'avère ultérieurement malveillante — nécessite un enregistrement légèrement différent. Il s'agit de : quel système ou compte était concerné, qui avait accès pendant la période en question, s'il y a des preuves que le code a été modifié ou consulté, et quels clients utilisent potentiellement un logiciel qui a été développé ou livré pendant cette période. C'est le type d'incident qui touche directement la gestion des accès dans l'environnement de développement : sans un aperçu à jour de qui peut faire quoi, cette question d'investigation devient considérablement plus difficile à résoudre.
Qui vous informez, et qui ne l'est pas
Que vous soyez vous-même assujetti à l'obligation de diligence raisonnable de la loi Cybersécurité ou non détermine qui vous informez d'un incident. Les entités désignées elles-mêmes comme critiques ou importantes ont une obligation de signalement envers leur autorité de contrôle ; ce qui doit précisément être fait et dans quel délai est décrit dans la directive et la loi nationale, et varie selon la situation. Une entreprise de logiciels affectée par la chaîne — c'est-à-dire non assujettie elle-même, mais livrant à un client qui l'est — n'a pas cette obligation de signalement auprès de l'autorité de contrôle, mais a généralement un accord contractuel pour informer le client. Cela ne rend pas l'enregistrement interne moins important : un client qui vous demande si vous avez jamais eu un incident veut voir une réponse concrète, pas une évaluation rétrospective.
Un registre vivant, pas une archive
L'enregistrement des incidents fonctionne mieux en tant que document vivant : une liste dans laquelle le statut, la preuve et le propriétaire de chaque incident sont retrouvables, au lieu d'un rapport isolé qui disparaît dans un classeur après sa clôture. Cela s'aligne sur la manière dont l'obligation de diligence plus large est structurée, avec dix mesures qui, chacune, exigent un statut et un propriétaire. Celui qui souhaite voir comment l'enregistrement des incidents se rapporte aux neuf autres mesures trouvera cet aperçu sur la page avec tous les sujets par situation.
Que votre organisation relève elle-même de l'obligation de diligence, soit affectée par la chaîne d'approvisionnement, ou ne relève d'aucun des deux, peut être déterminé en quelques questions via la vérification NIS2 qui fournit une indication en quelques questions. Celui qui souhaite savoir précisément d'où proviennent les informations sur secria.eu et comment elles sont maintenues à jour le lira sur la page sur le fonctionnement. Et celui qui, après la lecture, souhaite savoir ce qu'un abonnement ajoute à ce qui est disponible gratuitement ici trouvera cela de manière claire à l'aperçu de ce qui est inclus.
Ce texte est une explication générale et ne constitue pas un avis juridique sur votre situation particulière. Pour un avis sur votre processus d'incident spécifique ou sur vos obligations de signalement, vous pouvez consulter un juriste ou l'autorité de contrôle compétente pour votre secteur.