ISO 27001:2022, A.8.25 à A.8.28 : les quatre contrôles de développement et ce qui prouve chacun
Cycle de vie de développement sécurisé, exigences de sécurité applicative, architecture sécurisée, codage sécurisé : ce que demandent les quatre contrôles de l'annexe A, lesquels une analyse de code continue prouve avec une date, lesquels elle ne peut pas prouver, et où A.8.8 les traverse tous.
Pourquoi la version 2022 est plus précise ici
Dans la version précédente, les exigences de développement sécurisé étaient dispersées dans une section plus large. La révision 2022 les a regroupées dans l'annexe A sous le thème technologique et leur a donné des numéros propres. Pour une PME, la conséquence est concrète : l'auditeur parcourt les numéros un par un et attend une preuve distincte pour chacun. Une déclaration générale selon laquelle on développe de façon sécurisée n'en couvre aucun.
Notre page consacrée à la sécurité du code et à la conformité présente la correspondance en version courte. Voici la version longue, contrôle par contrôle, avec une indication honnête de ce qu'une analyse apporte et de ce qu'elle n'apporte pas.
A.8.25 : cycle de vie de développement sécurisé
Le contrôle demande que des règles de développement sécurisé des logiciels et des systèmes soient établies et appliquées. La seconde moitié est la plus difficile. Des règles se mettent vite dans un document ; qu'elles soient appliquées, il faut le montrer. Une analyse qui tourne à chaque commit et évalue chaque modification dans le contexte de la base de code avant que le code ne poursuive est une preuve de cette seconde moitié précisément : la règle agit dans le processus, pas seulement dans le rapport annuel.
Ce que l'analyse ne remplace pas, c'est la règle elle-même. Le document qui fixe comment on développe doit exister. L'analyse prouve son application, pas son existence.
A.8.26 : exigences de sécurité applicative
Il s'agit ici d'identifier, de spécifier et d'approuver les exigences de sécurité lors du développement ou de l'acquisition d'une application. Cela se passe avant la première ligne de code, dans les cahiers des charges, les tickets et les validations. Un analyseur n'en voit rien. Il peut vérifier qu'une entrée est validée, mais pas que quelqu'un a décidé auparavant qu'elle devait l'être.
La preuve pour A.8.26 est donc un document : les exigences spécifiées et leur approbation. Qui présente ici un rapport d'analyse prouve le mauvais contrôle.
A.8.27 : architecture système sécurisée et principes d'ingénierie
Ce contrôle exige que des principes d'architecture sécurisée soient établis, documentés et appliqués dans chaque développement. C'est aussi une question de conception. Comment les services sont séparés, où se situent les frontières de confiance, quelles données sont traitées où : cela figure dans les documents d'architecture et les revues, pas dans le code source. Un analyseur trouve un mot de passe codé en dur, mais il ne trouve pas qu'un composant n'aurait jamais dû, par conception, être exposé au réseau.
Pour A.8.27, les revues d'architecture sont la preuve. Un test d'intrusion peut les compléter, parce qu'il vérifie le système en fonctionnement dans son ensemble, du point de vue d'un attaquant.
A.8.28 : codage sécurisé
Le contrôle exige que des principes de codage sécurisé soient appliqués. C'est ici que l'analyse est chez elle. Entrées non validées, appels système dangereux, contrôles d'accès manquants, identifiants codés en dur : ce sont des manquements aux principes de codage qui ont un schéma, et une analyse à chaque commit les repère dès qu'ils apparaissent. Chaque résultat, sa qualification, la correction et la date forment ensemble la preuve que les principes ne sont pas seulement adoptés, mais imposés.
Deux réserves s'imposent. D'abord, aucun analyseur ne trouve tous les manquements ; les erreurs de logique métier n'ont pas de schéma. Ensuite, tout analyseur signale aussi des résultats qui ne sont pas exploitables dans le cas concret. C'est pourquoi, chez nous, une personne qualifie chaque résultat avant qu'il n'entre dans la documentation.
A.8.8 : gestion des vulnérabilités techniques, en transversal
A.8.8 n'est pas un contrôle de développement, mais il chapeaute les quatre : les informations sur les vulnérabilités techniques des systèmes utilisés doivent être obtenues, l'exposition évaluée et des mesures prises. Pour votre propre code, cela signifie avant tout les dépendances open source. L'analyse les compare en continu aux vulnérabilités connues, et lorsqu'une bibliothèque est mise à jour, le résultat, la mesure et la date vont dans le dossier. C'est la preuve la plus simple de toute la liste, et celle qui manque le plus souvent.
Le point d'entrée est l'analyse de code gratuite : connexion, analyse de l'existant sur les secrets, les dépendances et les schémas non sécurisés, constat priorisé.
Questions fréquentes
Une analyse de code prouve-t-elle les quatre contrôles de développement ?
Non. Elle prouve directement et avec des dates A.8.28 et la partie application de A.8.25. A.8.26 et A.8.27 concernent les exigences et l'architecture, donc des décisions prises avant le code, et il faut pour cela des documents et des revues.
L'analyse remplace-t-elle le SMSI ou la certification ?
Non, et l'ordre est inverse : le SMSI décide quels contrôles s'appliquent à vous, l'appréciation des risques jusqu'où, et la certification vérifie les deux. L'analyse ne fait que fournir les résultats datés pour deux de ces contrôles et pour A.8.8. Elle alimente le dossier ; elle n'est pas le dossier.
Nous n'avons pas encore adopté la norme. L'analyse vaut-elle quand même la peine ?
Oui, parce que les mêmes résultats comptent aussi au titre de l'article 30 du BSIG si vous relevez de NIS2, et parce que des preuves créées avec une date aujourd'hui n'auront pas à être rassemblées après coup. L'analyse est l'outil que vous avez en premier, pas en dernier.