Cette liste de contrôle de sécurité SDLC met en correspondance les contrôles de développement logiciel clause par clause avec l'Annexe A d'ISO/IEC 27001:2022, en particulier le groupe A.8.25–A.8.34 et les contrôles associés, afin que les responsables conformité, les directeurs informatiques et les responsables sécurité puissent spécifier les contrôles applicables dans leur Déclaration d'Applicabilité, collecter des preuves auditables et planifier les travaux de mise en œuvre avec confiance. Découvrez ci-dessous les tâches par clause, des exemples de preuves et des liens vers les outils de planification d'Ismscalculator.
Ce que vous obtenez avec cette liste de contrôle :
- Correspondance clause par clause des contrôles SDLC avec l'Annexe A d'ISO 27001 (A.8.25–A.8.34, A.5.23, A.8.8, A.8.9)
- Tâches concrètes avec les exigences minimales en matière de preuves et les rôles responsables
- Signaux d'alarme pour les auditeurs et vérifications internes rapides avant l'audit de Phase 2
- Estimations d'effort et exemple de découpage Gantt pour la budgétisation
- Liens vers les outils Ismscalculator pour des estimations de coûts et de délais personnalisées
Table des matières
- Que couvre la liste de contrôle de sécurité SDLC dans le cadre d'ISO 27001 ?
- Comment collecter et présenter les preuves pour chaque point de la liste de contrôle ?
- Qui est responsable de quoi ? Gouvernance des contrôles SDLC dans le cadre du SMSI
- Combien de temps prend la mise en œuvre des contrôles SDLC et quel en est le coût ?
- Où trouver un modèle de liste de contrôle et l'adapter à votre organisation ?
- Points clés à retenir
- Ce que la plupart des équipes font mal concernant les contrôles SDLC
- Ismscalculator transforme cette liste de contrôle en budget et en plan de projet
- Sources utiles et lectures complémentaires
Que couvre la liste de contrôle de sécurité SDLC dans le cadre d'ISO 27001 ?
ISO/IEC 27001:2022 a réorganisé l'Annexe A et a rendu explicite la sécurité des applications. La révision 2022 a consolidé les contrôles et en a introduit de nouveaux couvrant l'ensemble du cycle de vie du développement logiciel, la transition vers la référence 2022 ayant été achevée le 31 octobre 2025. Dix contrôles du domaine technologique (A.8.25 à A.8.34), auxquels s'ajoutent A.5.23, A.8.9 et A.8.16, forment un groupe de 13 contrôles de sécurité applicative que les auditeurs examinent généralement lors des audits de Phase 2.
Le tableau ci-dessous met en correspondance chaque clause principale avec les tâches de la liste de contrôle, les preuves minimales requises et un responsable suggéré.
| Clause ISO | Tâche de la liste de contrôle | Preuves minimales | Responsable |
|---|---|---|---|
| Cycle de vie de développement sécurisé | Documenter et appliquer des règles pour la planification, la conception, le codage, les tests, le déploiement et la maintenance | Politique de développement sécurisé, signée par le responsable du SMSI ; document de procédure avec historique des versions | Responsable SMSI / Product Owner |
| Exigences de sécurité des applications | Définir et documenter les exigences de sécurité avant le début du développement | Spécification des exigences avec critères d'acceptation de sécurité ; modèle de menaces ou entrée dans le registre des risques | Product Owner / Ingénieur sécurité |
| Architecture et ingénierie système sécurisées | Appliquer des principes de conception sécurisée (moindre privilège, défense en profondeur, sécurité par défaut) | Compte rendu de revue d'architecture ; validation de conception avec approbation de l'ingénieur sécurité | Ingénieur sécurité / Responsable développement |
| Codage sécurisé | Adopter et appliquer un standard de codage sécurisé (ex. : OWASP ASVS, SEI CERT) | Document de standard de codage sécurisé ; résultats d'analyse SAST liés aux commits ; comptes rendus de revue de code | Responsable développement |
| Tests de sécurité lors du développement | Intégrer les tests de sécurité dans le pipeline de développement | Rapports d'analyse SAST/DAST liés aux identifiants de build ; plan de tests avec cas de tests de sécurité ; résultats pass/fail | Responsable QA / Responsable DevOps |
| Développement externalisé | Appliquer les exigences de sécurité au code tiers et externalisé | Clauses de sécurité fournisseur dans les contrats ; preuves de revue de code fournisseur ou résultats SAST | Responsable fournisseur / Responsable SMSI |
| Séparation des environnements de développement, de test et de production | Assurer l'isolation des environnements ; interdire les données de production dans les environnements de test | Schéma de topologie des environnements ; journaux de contrôle d'accès ; enregistrements d'anonymisation des données de test | Responsable DevOps |
| Gestion des changements | Contrôler les modifications des systèmes via un processus formel | Enregistrements de demandes de changement avec approbations ; journaux des portes d'approbation du pipeline ; procédures de retour arrière | Responsable développement / Gestionnaire des changements |
| Informations de test | Protéger les données de test ; éviter l'utilisation de données personnelles réelles lors des tests | Politique de données de test ; enregistrements d'anonymisation ou de génération de données synthétiques | Responsable QA / Délégué à la Protection des Données |
| Protection des systèmes d'information lors des tests d'audit | Restreindre et journaliser les accès lors des audits ou des tests d'intrusion | Accord de périmètre de test d'intrusion ; journaux d'accès pendant la fenêtre de test ; rapport de résultats avec remédiation | Responsable SMSI / Ingénieur sécurité |
| Sécurité de l'information pour les services cloud | Appliquer les exigences de sécurité aux environnements de développement hébergés dans le cloud | Contrat de service cloud avec clauses de sécurité ; matrice de responsabilité partagée | Responsable SMSI / Responsable fournisseur |
| Gestion des vulnérabilités techniques | Maintenir un processus de gestion des vulnérabilités couvrant les livrables SDLC | Journal de triage des vulnérabilités avec dates et niveaux de criticité ; enregistrements SBOM ; tickets de remédiation avec suivi des SLA | Ingénieur sécurité |
| Gestion des configurations | Gérer les configurations sécurisées des outils de développement et de l'infrastructure | Documents de référence de configuration ; modèles IaC sous contrôle de version ; journaux de détection de dérive | Responsable DevOps |
Le groupe de contrôles de sécurité applicative requiert une procédure documentée, un responsable nommé et un échantillon de preuves couvrant au moins une période d'audit (généralement 3 à 12 mois). Les contrôles A.8.25, A.8.26, A.8.27 et A.8.28 ont des finalités différentes et doivent être explicitement traités, même s'ils sont mis en œuvre via un seul document de procédure.
Preuves minimales généralement acceptées par les auditeurs :
- Résultats SAST liés à Git indiquant le constat, le hash de commit et la date de remédiation
- Enregistrements SBOM générés par version avec horodatage
- Journaux des portes d'approbation du pipeline attestant de la complétion des étapes de sécurité obligatoires
- Journaux d'isolation des environnements ou enregistrements de contrôle d'accès
- Tickets de triage des vulnérabilités avec criticité, date d'ouverture et date de clôture
Comment collecter et présenter les preuves pour chaque point de la liste de contrôle ?
Les auditeurs se concentrent sur la traçabilité : un contrôle nommé, une preuve et une date. Les descriptions de processus abstraites ne suffisent pas. Chaque point de la liste de contrôle doit produire 3 à 5 artefacts reproductibles.
Politique de développement sécurisé : Le document de politique doit comporter un nom de responsable, une date d'approbation, un numéro de version et une date de révision. Conservez-le dans votre système de gestion documentaire avec un historique des versions. La convention de nommage SDev-Policy-v1.2-2025-09-01.pdf permet à un auditeur d'identifier la date et la version en un coup d'œil.
Séparation des environnements : Un schéma de topologie seul ne suffit pas. Associez-le à des journaux de contrôle d'accès attestant qu'aucun compte développeur n'existe en production, ainsi qu'à un enregistrement daté de toute exception avec validation formelle d'acceptation du risque. Les pipelines CI/CD doivent imposer des étapes de tests de sécurité obligatoires, des portes d'approbation et des pistes d'audit immuables pour satisfaire aux sous-contrôles A.14, et ces journaux de pipeline constituent l'enregistrement immuable.
Enregistrements de triage des vulnérabilités (A.8.8) : Un tableur sans dates est un signal d'alarme. Utilisez votre système de ticketing (Jira, Linear ou équivalent) afin que chaque constat dispose d'un horodatage de création, d'un niveau de criticité, d'un responsable et d'une date de clôture. Exportez une vue filtrée couvrant la période d'audit comme artefact de preuve.
| Artefact | Métadonnées requises | Emplacement de stockage | Méthode de vérification par l'auditeur |
|---|---|---|---|
| Politique de développement sécurisé | Responsable, version, date d'approbation, date de révision | Système de gestion documentaire (sous contrôle de version) | Vérifier l'historique des versions ; confirmer l'autorité du signataire |
| Rapport d'analyse SAST | Identifiant de build, hash de commit, nom de l'outil, date d'analyse, nombre de constats | Dépôt d'artefacts CI/CD (immuable) | Recouper le hash de commit dans le contrôle de sources |
| Fichier SBOM | Version de la release, date de génération, nom de l'outil, liste des composants | Registre d'artefacts ou stockage de fichiers sécurisé | Vérifier que la date de génération correspond à la date de release |
| Journal de triage des vulnérabilités | Identifiant du constat, criticité, date d'ouverture, responsable, date de clôture | Système de ticketing (Jira, Linear, etc.) | Filtrer par période d'audit ; vérifier le respect des SLA |
| Journal d'accès aux environnements | Utilisateur, action, horodatage, nom de l'environnement | SIEM ou service de journalisation des accès cloud | Confirmer l'absence d'accès inter-environnements sans approbation |
Conseil pratique : Les auditeurs demandent de plus en plus des preuves liées à Git plutôt que des rapports périodiques. Configurez votre pipeline CI/CD pour joindre le rapport SAST en tant qu'artefact de build avec le SHA de commit intégré dans le nom de fichier. Cette seule étape élimine la contestation d'authenticité des preuves la plus fréquente.
Qui est responsable de quoi ? Gouvernance des contrôles SDLC dans le cadre du SMSI
Une responsabilité claire est ce qui distingue un SMSI opérationnel d'un simple exercice de conformité. Le modèle de gouvernance ci-dessous attribue les rôles aux six fonctions que les auditeurs s'attendent à trouver.
| Domaine de contrôle | Responsable SMSI | Propriétaire du contrôle | Responsable développement | Ingénieur sécurité | Responsable QA | Responsable fournisseur |
|---|---|---|---|---|---|---|
| Politique de développement sécurisé | A (Approbateur) | R (Responsable) | C (Consulté) | C | I (Informé) | I |
| Exigences de sécurité | I | C | R | C | C | C |
| Architecture sécurisée | I | C | C | R | I | I |
| Standard de codage sécurisé | I | C | R | R | C | C |
| Tests de sécurité | I | C | C | C | R | I |
| Développement externalisé | A | R | I | C | I | R |
| Séparation des environnements | I | C | R | C | I | I |
| Gestion des vulnérabilités | I | R | C | R | C | C |
Les validations exécutives requises comprennent : l'approbation initiale de la politique par le responsable SMSI, la validation de la Déclaration d'Applicabilité confirmant l'applicabilité et la justification de chaque contrôle, et une revue de direction annuelle portant sur des échantillons de preuves de la période précédente. La fréquence d'échantillonnage des preuves doit être au moins trimestrielle pour les contrôles à risque élevé (A.8.28, A.8.29, A.8.8) et semestrielle pour ceux à risque plus faible.
Combien de temps prend la mise en œuvre des contrôles SDLC et quel en est le coût ?
L'effort varie selon la maturité. Le tableau ci-dessous présente des fourchettes réalistes pour une organisation mettant en œuvre des contrôles SDLC dans le cadre d'un projet ISO 27001 plus large.
| Niveau de maturité | Phase | Durée typique | Profil de ressources |
|---|---|---|---|
| Minimal (processus ad hoc, aucune politique SDLC formelle) | Rédaction de la politique et cartographie de la Déclaration d'Applicabilité | 3–4 semaines | — |
| Minimal | Mise en place des outils (SAST, SBOM, portes de pipeline) | 4–6 semaines | 1 ETP DevOps + — |
| Modéré (certaines politiques existent, preuves incohérentes) | Remédiation des écarts et collecte des preuves | 4–6 semaines | — |
| Modéré | Audit interne et revue pré-audit | 2–3 semaines | 0,5 ETP Responsable SMSI |
| Complet (DevSecOps mature, contrôles documentés) | Constitution du dossier de preuves et finalisation de la Déclaration d'Applicabilité | 2–3 semaines | 0,25 ETP Responsable SMSI + 0,25 ETP Responsable développement |
Exemple de découpage Gantt pour le chantier SDLC dans une organisation de maturité intermédiaire : semaines 1 à 3 pour la rédaction des politiques et procédures ; semaines 4 à 8 pour l'intégration des outils et la configuration des portes de pipeline ; semaines 9 à 12 pour la collecte des preuves sur un échantillon de période d'audit ; semaines 13 à 14 pour l'audit interne des preuves et la clôture des écarts ; semaine 15 pour la mise à jour de la Déclaration d'Applicabilité et la préparation à l'audit.
Conseil pratique : Effectuez le diagnostic de préparation en 2 minutes d'Ismscalculator avant de vous engager sur un calendrier. Il évalue votre maturité actuelle sur les quatre domaines de contrôle d'ISO/IEC 27001:2022 et identifie les contrôles SDLC qui nécessiteront le plus d'effort, afin que vous puissiez prioriser les bons travaux.
L'évaluation complète de préparation convertit ces fourchettes d'effort en une estimation de coût personnalisée et un diagramme de Gantt téléchargeable, exactement ce dont vous avez besoin pour une demande d'approbation budgétaire.
Où trouver un modèle de liste de contrôle et l'adapter à votre organisation ?
Un modèle de liste de contrôle pratique pour cet ensemble de contrôles doit contenir les colonnes suivantes : clause ISO, tâche de la liste de contrôle, type d'artefact de preuve, convention de nommage des fichiers, rôle responsable, statut actuel (Non démarré / En cours / Terminé) et lien vers l'artefact exemple.
Étapes d'adaptation selon le type d'organisation :
- Éditeurs SaaS et entreprises technologiques : Ajoutez une colonne indiquant l'étape du pipeline CI/CD où chaque contrôle est appliqué. Le guide ISO 27001 pour les éditeurs SaaS et entreprises technologiques couvre des modèles et des notes de mise en œuvre spécifiques au SDLC directement applicables ici.
- Secteurs réglementés (finance, santé) : Recoupez chaque contrôle SDLC avec les exigences spécifiques à votre secteur (SOC 2, HIPAA, PCI DSS). La comparaison des standards de sécurité des données financières met en correspondance les contrôles ISO 27001 avec les réglementations financières.
Conseil pratique : Conservez votre liste de contrôle dans un document sous contrôle de version (Confluence, Notion ou un fichier markdown hébergé sur Git). Chaque changement de statut devient automatiquement une piste d'audit datée, et vous pouvez exporter un instantané pour l'auditeur sans créer de dossier de preuves séparé.
Des squelettes de politiques, des modèles SBOM exemples et des extraits de plans de tests sont disponibles via le guide des contrôles de l'Annexe A d'ISO 27001 d'Ismscalculator, qui met en correspondance chaque contrôle avec des éléments de preuve concrets.
Points clés à retenir
Une liste de contrôle de sécurité SDLC auditable exige un responsable nommé, un artefact daté et un lien traçable entre chaque contrôle de l'Annexe A d'ISO 27001 et sa preuve avant le début de la Phase 2.
| Point | Détails |
|---|---|
| Cartographier explicitement chaque contrôle SDLC | Lister individuellement A.8.25–A.8.34, A.5.23, A.8.8 et A.8.9 dans votre Déclaration d'Applicabilité avec une procédure et une preuve pour chacun. |
| Lier les preuves aux builds et aux commits | Joindre les rapports SAST et les SBOM aux identifiants de build et aux hashes de commit afin que les auditeurs puissent vérifier leur authenticité. |
| Désigner des responsables nominatifs, pas des équipes | Chaque procédure et chaque point de la liste de contrôle doit avoir un intitulé de rôle précis comme responsable, et non « l'équipe de développement ». |
| Effectuer un test de traçabilité interne en amont | Sélectionner un build aléatoire et le tracer à travers les résultats SAST, la porte d'approbation, le SBOM et les enregistrements de triage avant la Phase 2. |
| Utiliser Ismscalculator pour la planification des efforts | Le diagnostic de préparation et l'évaluation complète convertissent les écarts sur les contrôles SDLC en un plan de projet budgétisé avec export Gantt. |
Ce que la plupart des équipes font mal concernant les contrôles SDLC
La plupart des organisations passent leurs deux premiers mois à rédiger des politiques et presque rien à construire l'infrastructure de preuves. C'est le mauvais ordre. Une politique de développement sécurisé soignée, sans résultats SAST liés au pipeline ni SBOM datés, générera une non-conformité majeure lors de la Phase 2, quelle que soit la qualité rédactionnelle du document.
Les contrôles qui piègent le plus souvent les équipes ne sont pas les plus complexes. A.8.31 (séparation des environnements) et A.8.8 (gestion des vulnérabilités) font échouer les audits en permanence, non pas parce que ces contrôles sont difficiles à mettre en œuvre, mais parce que les preuves sont éparpillées ou non datées. Corrigez la chaîne de preuves avant d'affiner la rédaction des politiques.
Une priorité pratique : automatisez la génération des SBOM au moment de la release, et non sous la forme d'une tâche manuelle trimestrielle. Un SBOM daté par release, stocké avec l'artefact de release, satisfait aux exigences de preuves d'A.8.8 et vous fournit une piste d'audit des dépendances couvrant plusieurs contrôles simultanément. Cette seule étape dans le pipeline est rentabilisée sur au moins quatre points de la liste de contrôle.
Ismscalculator transforme cette liste de contrôle en budget et en plan de projet
Cartographier les contrôles SDLC sur ISO 27001 est une chose. Savoir ce que cela coûtera à votre organisation et combien de temps cela prendra est ce qui permet d'obtenir l'approbation d'un projet.
Ismscalculator prend en compte la taille de votre entreprise, votre secteur d'activité et votre maturité sécurité actuelle pour produire une estimation de coût et d'effort personnalisée pour l'ensemble de votre mise en œuvre ISO 27001, y compris le chantier des contrôles SDLC. La plateforme couvre les quatre domaines de contrôle d'ISO/IEC 27001:2022, génère un diagramme de Gantt personnalisable que vous pouvez partager avec les parties prenantes, et exporte un rapport PDF conçu pour les discussions d'approbation budgétaire. Le diagnostic de préparation en 2 minutes vous donne un instantané de maturité immédiat et gratuit. Lorsque vous êtes prêt à approfondir l'analyse, l'évaluation complète de préparation ISO 27001 convertit vos écarts de liste de contrôle en un plan de projet phasé avec des comparaisons par rapport à un référentiel modèle, afin que vous sachiez exactement où vous en êtes.
Sources utiles et lectures complémentaires
Les sources ci-dessous étayent des sections spécifiques de cette liste de contrôle. Utilisez-les pour vérifier le texte des clauses, passer en revue les attentes des auditeurs et adapter la liste de contrôle à votre environnement.
- ISO 27001 Application Security : Guide des contrôles de l'Annexe A (2022)
- ISO 27001 Application Security : Cartographie complète des contrôles
- ISO 27001 Secure SDLC : Exigences clés, étapes et modèles (2026) | Konfirmity
- ISO 27001 A.14 en profondeur — Développement et maintenance des systèmes en CI/CD - Regulated DevSecOps
- ICT Institute | Contrôles technologiques ISO 27001 pour le développement logiciel
- Diagnostic de préparation ISO 27001 gratuit — Auto-évaluation en 2 minutes | ISMS Calculator
- ISO 27001 pour les éditeurs SaaS et entreprises technologiques : un guide pratique | ISMS Calculator
Recommandé
- Les contrôles de l'Annexe A d'ISO 27001 expliqués | ISMS Calculator
- Liste de contrôle pour la certification ISO 27001 : 80 étapes vers la certification | ISMS Calculator
- Analyse d'écarts ISO 27001 : guide pas à pas | ISMS Calculator
- Inventaire des actifs informatiques ISO 27001 : conseils pour la préparation à l'audit | ISMS Calculator