ISO 27001 A.8.8 : gérer les vulnérabilités techniques de vos logiciels
Par l'équipe Lysbor · publié le · 4 min de lecture
Dans la version 2022 de la norme ISO/IEC 27001, l'annexe A regroupe 93 mesures de sécurité en quatre thèmes. La mesure A.8.8, « Gestion des vulnérabilités techniques », est l'une des plus concrètes et l'une des plus examinées en audit. Elle s'applique aux systèmes, aux serveurs, mais aussi aux logiciels que vous développez et à leurs composants tiers.
Ce guide explique ce que l'auditeur attend et comment le démontrer pour la partie dépendances logicielles.
Ce que dit la mesure
L'intitulé de la mesure A.8.8 demande en substance que les informations sur les vulnérabilités techniques des systèmes d'information utilisés soient obtenues, que l'exposition de l'organisation à ces vulnérabilités soit évaluée et que des mesures appropriées soient prises.
La norme d'accompagnement ISO/IEC 27002:2022 détaille les bonnes pratiques associées, que l'on peut résumer en quatre verbes :
- Inventorier : disposer d'un inventaire des actifs, y compris des logiciels et de leurs versions, qui permet de savoir ce qui est exposé (en lien avec la mesure A.5.9 sur l'inventaire des actifs).
- S'informer : identifier les sources d'information fiables sur les vulnérabilités et les suivre.
- Évaluer : estimer le risque de chaque vulnérabilité dans le contexte de l'organisation et décider d'une priorité.
- Traiter : corriger dans des délais définis, ou appliquer des mesures compensatoires, et vérifier l'efficacité.
L'auditeur se comporte comme un contrôleur technique automobile. Il ne vous demande pas si la voiture roule. Il vous demande le carnet d'entretien : quand les pièces ont été vérifiées, ce qui a été remplacé, et pourquoi tel défaut signalé n'a pas été réparé.
Appliqué aux dépendances logicielles
| Attendu | Pour vos dépendances | Preuve |
|---|---|---|
| Inventaire des actifs logiciels | SBOM de chaque application, à jour | SBOM datés, liste des projets suivis |
| Sources d'information identifiées | Base OSV, GitHub Advisories, catalogue KEV, scores EPSS | Mention des sources dans la procédure |
| Surveillance régulière | Confrontation quotidienne automatique | Historique des analyses |
| Évaluation du risque | Priorisation par sévérité, exploitation réelle et exposition | Règle de priorisation écrite |
| Délais de traitement | Délais par sévérité | Politique, taux de respect des délais |
| Décisions documentées | Risques acceptés justifiés, avec échéance | Registre des décisions, VEX |
| Vérification de l'efficacité | Indicateurs suivis dans le temps | Tendance, délai moyen de correction |
Les mesures voisines sont souvent examinées en même temps : A.5.21 (sécurité de l'information dans la chaîne d'approvisionnement TIC), A.8.25 (cycle de développement sécurisé), A.8.28 (codage sécurisé) et A.8.32 (gestion des changements).
Les questions typiques de l'auditeur
- « Comment savez-vous qu'une nouvelle vulnérabilité touche l'une de vos applications ? »
- « Montrez-moi la dernière vulnérabilité critique détectée : quand, qui a été prévenu, quand a-t-elle été corrigée ? »
- « Quels sont vos délais de correction, et les respectez-vous ? »
- « Cette vulnérabilité est ouverte depuis quatre mois : pourquoi ? Qui a accepté ce risque ? »
- « Comment vous assurez-vous qu'une bibliothèque ajoutée par un développeur est contrôlée ? »
Chacune appelle une preuve datée, pas une déclaration. Les organisations qui passent sereinement cette partie de l'audit sont celles qui peuvent ouvrir un historique en direct.
Les erreurs fréquentes
- Un scan ponctuel avant l'audit. L'auditeur demande l'historique sur la période, pas l'état de la veille.
- Une politique sans mesure. Des délais écrits mais jamais mesurés sont une non-conformité en puissance.
- Des exceptions orales. « On sait que celle-là ne nous concerne pas » doit devenir une décision écrite, justifiée, avec une date de revue.
- Oublier les images de conteneur. Les paquets système d'une image Docker sont des actifs logiciels comme les autres.
- Un périmètre flou. Le périmètre du système de management doit dire quelles applications sont couvertes, et chacune doit apparaître dans l'inventaire.
Comment Lysbor aide pour A.8.8
Lysbor produit un rapport PDF de posture qui réunit : inventaire des projets et composants, vulnérabilités ouvertes par sévérité, tendance dans le temps, délais de correction et respect des engagements, risques acceptés avec leur justification, et une correspondance explicite avec ISO 27001 A.8.8 et l'article 21 de NIS2. Le journal d'activité, chaîné par empreinte, montre qu'aucune décision n'a été modifiée après coup.
L'outil ne remplace ni votre politique, ni votre appréciation des risques, ni le reste du système de management. Il rend la partie dépendances logicielles vérifiable en quelques minutes.
Questions fréquentes
Quelle est la différence entre A.12.6.1 et A.8.8 ?
A.12.6.1 est le numéro de la mesure « Gestion des vulnérabilités techniques » dans l'ancienne version ISO 27001:2013. Elle est devenue A.8.8 dans la version 2022, avec un contenu très proche. Les certifications selon la version 2013 ont dû migrer vers la version 2022.
Faut-il un outil payant pour satisfaire A.8.8 ?
Non. La norme n'impose aucun outil. Mais la surveillance continue, la priorisation et la conservation des preuves sont très difficiles à tenir à la main au-delà de quelques applications. Un outil automatise surtout la collecte de preuves.
Les dépendances open source entrent-elles dans le périmètre ?
Oui, dès lors que les applications qui les embarquent sont dans le périmètre du système de management. Une bibliothèque vulnérable dans une application en production est une vulnérabilité technique de cette application.