ISO 27001 apparaît de plus en plus comme une exigence obligatoire dans les cadres de marchés publics de logiciels de défense à travers l'Europe. Ce qui était autrefois un différenciateur apprécié est devenu une attente de base : les fournisseurs sans certification ISO 27001:2022 en vigueur sont exclus des listes de présélection avant même le début de l'évaluation technique. Comprendre ce que la norme exige réellement — et pas seulement à quoi ressemble le certificat — est essentiel pour les fournisseurs qui cherchent à se certifier et pour les responsables des achats qui évaluent les offres.

Cet article examine ce qu'ISO 27001:2022 exige dans le contexte des organisations de développement logiciel, les changements significatifs introduits par la révision de 2022, et ce que la certification signifie concrètement pour les processus de développement, la composition des équipes et la livraison des projets.

Ce qu'est ISO 27001:2022 — et ce qui a changé

ISO 27001 est une norme internationale spécifiant les exigences relatives à un Système de Management de la Sécurité de l'Information (SMSI). Contrairement aux normes de sécurité techniques qui prescrivent des contrôles spécifiques, ISO 27001 exige que les organisations identifient leurs risques de sécurité de l'information, mettent en œuvre des contrôles appropriés et maintiennent un cycle d'amélioration continue.

La révision de 2022 a remplacé ISO 27001:2013 et a introduit des changements substantiels à l'Annexe A, qui contient l'ensemble de référence des contrôles. La version 2013 comportait 114 contrôles répartis en 14 domaines. La version 2022 les a restructurés en 93 contrôles répartis en 4 thèmes : contrôles organisationnels, liés aux personnes, physiques et technologiques. De plus, 11 nouveaux contrôles ont été introduits, directement pertinents pour les organisations de développement logiciel :

  • Renseignements sur les menaces (5.7) — les organisations doivent collecter et analyser des informations sur les menaces pertinentes pour leur contexte
  • Sécurité de l'information pour l'utilisation des services en nuage (5.23) — exigences explicites en matière de gouvernance de l'utilisation du cloud
  • Disponibilité des TIC pour la continuité des activités (5.30) — la planification de la continuité doit prendre en compte les dépendances TIC
  • Filtrage web (8.23) — contrôles sur les ressources internet accessibles aux systèmes
  • Codage sécurisé (8.28) — exigences formelles pour les pratiques de développement sécurisé
  • Masquage des données (8.11) — exigences pour le masquage des données sensibles dans les environnements hors production

Pour les fournisseurs de logiciels de défense, le contrôle 8.28 (Codage sécurisé) est particulièrement significatif. La norme 2022 exige désormais explicitement que les organisations appliquent des principes de codage sécurisé dans le développement logiciel — les pratiques de développement sécurisé doivent être documentées, respectées et auditées.

Contrôles clés pertinents pour le développement logiciel

ISO 27001 ne prescrit pas de technologies spécifiques ni de méthodologies de développement. Il impose une approche structurée pour identifier et gérer les risques de sécurité de l'information tout au long du cycle de vie du développement logiciel. En pratique, cela se traduit par plusieurs catégories d'exigences qui affectent le fonctionnement d'une organisation de développement.

Contrôle d'accès (8.2–8.5). La norme exige que l'accès aux systèmes, aux dépôts de code et à l'infrastructure de déploiement soit géré selon le principe du moindre privilège. Pour le développement de logiciels de défense, cela signifie que les développeurs ne doivent pas avoir accès à la production, que la révision du code doit contrôler les fusions vers les branches protégées, et que l'accès privilégié aux systèmes de déploiement doit être limité dans le temps et journalisé.

Cryptographie (8.24). Les organisations doivent disposer d'une politique régissant les contrôles cryptographiques : quels algorithmes sont approuvés, comment les clés sont gérées et qui est responsable des décisions cryptographiques. Pour les logiciels de défense, cela implique généralement l'alignement sur les normes cryptographiques nationales.

Cycle de vie du développement sécurisé (8.25–8.31). La norme exige que la sécurité soit intégrée tout au long du processus de développement : les exigences de sécurité doivent être spécifiées à la phase de conception, les tests de sécurité doivent être effectués avant la mise en production, et les dépendances doivent être évaluées pour les vulnérabilités. Cela nécessite directement des pratiques telles que la modélisation des menaces, l'analyse statique, la détection de vulnérabilités des dépendances et les tests de pénétration.

Gestion des incidents (5.24–5.28). Les organisations doivent disposer de procédures documentées pour détecter, signaler et répondre aux incidents de sécurité. Pour les environnements de développement, cela implique la surveillance des accès anormaux aux dépôts de code et des modifications non autorisées des configurations de déploiement.

Note pour les acheteurs : Lors de l'évaluation des certificats ISO 27001, vérifiez toujours le périmètre de certification. Un certificat couvrant uniquement le « siège social » ou les « fonctions administratives » n'offre aucune garantie concernant l'environnement de développement où le code est réellement écrit. Le périmètre doit explicitement inclure les activités de développement logiciel et l'infrastructure les soutenant.

Ce qui change réellement dans les processus de développement

Les organisations qui obtiennent pour la première fois une certification ISO 27001 découvrent généralement que l'impact de la norme sur leurs processus de développement est plus substantiel qu'anticipé. Les changements suivants sont systématiquement requis et systématiquement sous-estimés.

L'évaluation des risques devient un artefact documenté. ISO 27001 exige que les risques de sécurité de l'information soient identifiés, évalués et suivis. Pour le développement logiciel, cela signifie la tenue d'un registre des risques couvrant les risques liés à l'environnement de développement, à la chaîne d'approvisionnement et aux opérations. Le registre des risques n'est pas un document ponctuel — il doit être revu et mis à jour à des intervalles définis.

Les jalons du SDLC deviennent des points de contrôle obligatoires. Les exigences de sécurité doivent être capturées au début de chaque cycle de développement. Les tests de sécurité doivent être effectués avant la mise en production. Les auditeurs demanderont des résultats de tests de sécurité, pas seulement des assurances que des tests ont été effectués.

La gestion des fournisseurs et des dépendances requiert un traitement formel. La norme exige que les exigences de sécurité de l'information soient communiquées aux fournisseurs et que les relations fournisseurs soient surveillées. Pour le développement logiciel, cela englobe les bibliothèques open source et les composants tiers.

Les exigences de sécurité du personnel affectent le recrutement et l'intégration. ISO 27001 exige une vérification des antécédents du personnel dont les rôles impliquent l'accès à des informations sensibles. Pour les fournisseurs de logiciels de défense, cela peut nécessiter l'alignement sur les exigences nationales de sécurité.

Pourquoi les responsables des achats exigent ISO 27001

Du point de vue d'un responsable des achats de défense, la certification ISO 27001 remplit plusieurs fonctions qui vont au-delà des contrôles de sécurité eux-mêmes.

Premièrement, elle fournit une vérification indépendante. Le certificat est délivré par un organisme tiers accrédité après un audit du SMSI de l'organisation. Contrairement aux cadres de conformité auto-évalués, ISO 27001 exige qu'un auditeur qualifié examine les preuves de mise en œuvre des contrôles. Les audits de surveillance ont lieu annuellement ; les audits de recertification tous les trois ans.

Deuxièmement, elle crée une obligation de rendre compte. La certification ISO 27001 exige que la direction générale soit visiblement engagée dans le SMSI. Cela signifie que l'organisation ne peut pas crédiblement prétendre que des défaillances de sécurité étaient des incidents isolés sans lien avec la direction.

Troisièmement, elle simplifie la diligence raisonnable. Plutôt que d'effectuer une évaluation de sécurité détaillée de chaque fournisseur potentiel, les cadres d'achats qui exigent ISO 27001 peuvent utiliser le certificat comme filtre de base. Les fournisseurs doivent également savoir que les certificats faisant référence à la norme de 2013 sont considérés comme caducs après octobre 2025 pour les besoins des marchés publics.