Le Secure SDLC du point de vue de l’auditeur — Que vérifier à chaque phase

Le SDLC sécurisé du point de vue de l’auditeur — ce qu’il faut vérifier à chaque phase

par

Fondamentaux du SDLC sécurisé

Avant d’examiner ce que les auditeurs doivent vérifier à chaque phase, il convient d’établir ce qu’est réellement un cycle de vie de développement logiciel sécurisé (Secure SDLC), pourquoi il compte dans les environnements réglementés et en quoi il diffère des concepts voisins. Cette introduction pose ces bases.

Pourquoi il compte dans les environnements réglementés

Les applications d’entreprise modernes évoluent dans des environnements où les défaillances de sécurité ne se limitent plus à des incidents techniques. Elles se traduisent directement par des constats réglementaires, des perturbations opérationnelles, des sanctions financières et des atteintes à la réputation.

Dans les secteurs réglementés tels que la banque, l’assurance, la santé et les infrastructures critiques, la sécurité applicative n’est pas facultative. Elle doit être systématique, démontrable et auditable tout au long du cycle de vie de développement logiciel. C’est là que le SDLC sécurisé devient un concept fondateur — non pas un outil, une liste de contrôle ou un simple scan de sécurité, mais une approche structurée visant à intégrer des contrôles de sécurité, une gouvernance et la production de preuves tout au long de la vie d’une application, de la conception à la production et au-delà.

Qu’est-ce qu’un SDLC sécurisé ?

Un SDLC sécurisé est une extension du cycle de vie de développement logiciel traditionnel qui intègre des exigences, des contrôles et des activités de vérification de sécurité à chaque étape de la livraison. Plutôt que de traiter la sécurité comme un ultime point de contrôle ou une activité postérieure à la mise en production, il garantit que la sécurité est :

  • Conçue dès l’origine, et non ajoutée après coup
  • Appliquée en continu, et non revue périodiquement
  • Mesurable et auditable, et non implicite

Dans les environnements réglementés, le SDLC sécurisé sert également de socle pour démontrer la conformité à des référentiels tels qu’ISO 27001, SOC 2, DORA, NIS2 et PCI DSS.

Principes fondamentaux

Trois principes sous-tendent un SDLC sécurisé mature :

  • La sécurité dès la conception. Les objectifs de sécurité sont définis en même temps que les exigences fonctionnelles lors de la planification et de la conception — par la modélisation des menaces, l’évaluation des risques, la définition des exigences de sécurité et la mise en correspondance des contrôles avec les attentes réglementaires. Les décisions prises ici façonnent tout ce qui suit ; ajouter la sécurité plus tard est coûteux, fragile et rarement prêt pour un audit.
  • Des contrôles au plus tôt (shift-left). La détection et la prévention interviennent aussi tôt que possible, généralement dès le développement et la revue de code. Des contrôles tels que le test statique de sécurité applicative, la détection de secrets, les normes de codage sécurisé et les vérifications de politique sur les dépendances visent non seulement à trouver les vulnérabilités tôt, mais aussi à empêcher les schémas non sécurisés de se propager en aval.
  • Une application continue via la CI/CD. Dans les environnements d’entreprise, le pipeline de livraison devient le moteur d’application des contrôles. Grâce à la politique-as-code, aux points de contrôle d’approbation automatisés et aux vérifications de sécurité obligatoires, les contrôles sont appliqués de manière cohérente, uniforme entre les équipes et non contournables. Dans les contextes réglementés, les pipelines doivent être traités comme des systèmes réglementés, et non comme de simples outils d’automatisation.

SDLC sécurisé, DevSecOps et sécurité CI/CD

Ces termes sont souvent employés de manière interchangeable, mais ils répondent à des finalités différentes :

  • Le SDLC sécurisé définit quels contrôles de sécurité doivent exister tout au long du cycle de vie.
  • DevSecOps définit comment les équipes collaborent et opèrent pour mettre en œuvre ces contrôles.
  • La sécurité CI/CD définit comment les contrôles sont techniquement appliqués à travers les pipelines.

Le SDLC sécurisé fournit le socle structurel sur lequel reposent les pratiques DevSecOps et les mécanismes de sécurité CI/CD.

Un système de gouvernance, pas un produit

Dans les environnements réglementés, le SDLC sécurisé s’accompagne de contraintes supplémentaires : les contrôles doivent être documentés et traçables, les décisions doivent être justifiables auprès des auditeurs, les exceptions doivent être explicites, approuvées et enregistrées, et les preuves doivent être conservées et exportables. Cela transforme le SDLC sécurisé, d’une pratique purement technique, en un système de gouvernance et de gestion des risques.

Il s’ensuit qu’un SDLC sécurisé ne peut pas simplement s’acheter. Les outils le soutiennent mais ne le définissent pas ; sans objectifs de contrôle clairs, sans flux de travail appliqués, sans modèles de gouvernance et sans stratégies de conservation des preuves, même les outils les plus avancés ne parviennent pas à produire de véritables résultats en matière de sécurité ou de conformité. Le SDLC sécurisé est un modèle opérationnel, pas un produit. Les organisations qui le mettent en œuvre correctement gagnent en rapidité d’audit, subissent moins d’incidents en production, réduisent les frictions entre les fonctions sécurité, développement et conformité, et accroissent leur confiance dans la livraison logicielle. L’objectif n’est pas d’ajouter davantage de sécurité, mais de rendre la sécurité incontournable, vérifiable et pérenne.

Ces bases étant posées, le reste de ce guide examine le SDLC sécurisé en tant que cadre de contrôle et détaille ce que les auditeurs doivent vérifier à chaque phase.

Le SDLC sécurisé en tant que cadre de contrôle

Le cycle de vie de développement logiciel sécurisé (Secure SDLC) est souvent présenté comme une méthodologie de développement — une séquence de pratiques que les équipes d’ingénierie suivent pour concevoir des logiciels plus sûrs. Pour les auditeurs et les responsables conformité, toutefois, il devrait être évalué comme quelque chose de plus fondamental : un cadre de contrôle.

Chaque phase du SDLC représente un point de contrôle où des activités de sécurité spécifiques doivent se dérouler, des preuves spécifiques doivent être générées et des résultats spécifiques doivent être vérifiables. Lorsqu’une organisation affirme opérer un SDLC sécurisé, les auditeurs doivent regarder au-delà de la documentation de processus et évaluer si les contrôles fonctionnent réellement à chaque phase.

Ce guide parcourt chaque phase du SDLC du point de vue de l’auditeur, en précisant ce qui devrait se passer, quelles preuves demander, à quoi ressemble une bonne pratique et ce qui devrait susciter des inquiétudes.

Phase PLAN

Ce qui devrait se passer

Les considérations de sécurité sont intégrées à la planification du projet avant le début de tout développement. Cela inclut la modélisation des menaces pour identifier les vecteurs d’attaque potentiels, la définition des exigences de sécurité en parallèle des exigences fonctionnelles, et la classification de l’application selon le cadre de classification des risques de l’organisation.

Preuves à demander

  • Documentation du modèle de menaces (diagrammes de flux de données, identification des menaces, décisions de mitigation)
  • Exigences de sécurité documentées dans le backlog du projet ou le référentiel d’exigences
  • Enregistrement de la classification de risque de l’application, avec approbation
  • Traces de l’implication de la sécurité dans les sessions de planification

À quoi ressemble une bonne pratique

  • Des modèles de menaces sont créés pour toutes les applications de niveau 1 (Tier 1) et de niveau 2 (Tier 2), et mis à jour lorsque l’architecture évolue
  • Les exigences de sécurité sont traçables — chaque menace identifiée dans le modèle correspond à une exigence ou à un risque accepté
  • La classification détermine les exigences de contrôle en aval (fréquence des tests, flux d’approbation)
  • Le personnel de sécurité participe aux activités de planification, comme en attestent les comptes rendus de réunion

À quoi ressemble une mauvaise pratique

  • Aucun modèle de menaces n’existe, ou il a été créé une fois et jamais mis à jour
  • Les exigences de sécurité sont génériques (« l’application doit être sécurisée ») plutôt que spécifiques et testables
  • La classification de l’application est absente ou a été réalisée sans contribution de la sécurité ou de la conformité
  • La sécurité n’intervient qu’au moment des tests ou du déploiement

Phase CODE

Ce qui devrait se passer

Les développeurs suivent des normes de codage sécurisé documentées. Les modifications de code sont revues au regard des enjeux de sécurité — soit par revue par les pairs avec des relecteurs sensibilisés à la sécurité, soit par test statique de sécurité applicative (SAST) automatisé. La détection de secrets empêche que des identifiants, des clés d’API et des jetons soient enregistrés dans les dépôts.

Preuves à demander

  • Document des normes de codage sécurisé, approuvé et sous gestion de versions
  • Enregistrements de revue de code montrant les commentaires liés à la sécurité et leurs résolutions
  • Résultats de scans SAST intégrés au flux de développement
  • Configuration de la détection de secrets et enregistrements d’alertes
  • Registres de formation des développeurs aux pratiques de codage sécurisé

À quoi ressemble une bonne pratique

  • Le SAST s’exécute automatiquement à chaque pull request ou commit de code, avec des résultats visibles pour les développeurs
  • Les enregistrements de revue de code montrent que des constats de sécurité sont identifiés et traités — et pas seulement une revue fonctionnelle
  • La détection de secrets bloque les commits contenant des identifiants, avec un processus documenté de rotation de tout secret exposé
  • Les développeurs suivent une formation au codage sécurisé au moins annuelle, adaptée à leur pile technologique

À quoi ressemble une mauvaise pratique

  • Le SAST est exécuté manuellement ou seulement avant les mises en production, si bien que les vulnérabilités s’accumulent
  • Des revues de code existent mais n’incluent jamais de retours liés à la sécurité
  • Aucune détection de secrets n’est en place, ou les alertes sont ignorées
  • Les normes de codage sécurisé sont obsolètes ou non alignées avec les technologies utilisées

Phase BUILD

Ce qui devrait se passer

Le processus de build inclut l’analyse de composition logicielle (SCA) pour identifier les vulnérabilités des dépendances tierces et open source. Une nomenclature logicielle (SBOM) est générée pour chaque build afin de tenir à jour un inventaire de tous les composants. Les artefacts de build sont signés pour garantir leur intégrité et prévenir toute altération.

Preuves à demander

  • Résultats de scans SCA pour des builds récents, indiquant les vulnérabilités identifiées et leur traitement
  • Enregistrements de SBOM pour les mises en production
  • Configuration de la signature d’artefacts et enregistrements de vérification
  • Politique définissant les seuils de vulnérabilité acceptables dans les dépendances

À quoi ressemble une bonne pratique

  • Le SCA s’exécute à chaque build, avec des politiques définies pour bloquer les builds contenant des vulnérabilités critiques ou élevées
  • Les SBOM sont générés automatiquement et conservés avec les enregistrements de mise en production
  • La signature d’artefacts est imposée — les artefacts non signés ne peuvent pas être déployés en production
  • Un processus existe pour le correctif d’urgence des vulnérabilités critiques de dépendances

À quoi ressemble une mauvaise pratique

  • Le SCA n’est pas intégré au processus de build ou ne s’exécute que périodiquement
  • Aucune génération de SBOM — l’organisation ne peut pas identifier quels composants sont en production
  • Aucune signature d’artefacts — il n’existe aucun moyen de vérifier que les artefacts déployés correspondent aux builds approuvés
  • Des vulnérabilités critiques connues dans les dépendances sont présentes en production sans acceptation documentée

Phase TEST

Ce qui devrait se passer

Le test dynamique de sécurité applicative (DAST) est réalisé sur des applications en cours d’exécution afin d’identifier des vulnérabilités que l’analyse statique ne peut détecter (failles d’authentification, problèmes de configuration, vulnérabilités d’injection à l’exécution). Les tests d’intrusion menés par du personnel qualifié apportent une perspective adverse. Les environnements de test sont isolés de la production afin de prévenir toute fuite de données.

Preuves à demander

  • Résultats de scans DAST et enregistrements de remédiation
  • Rapports de tests d’intrusion précisant le périmètre, la méthodologie, les constats et l’état de remédiation
  • Preuves d’isolation des environnements (schémas réseau, contrôles d’accès)
  • Enregistrements montrant que la fréquence des tests est alignée sur le niveau de risque de l’application

À quoi ressemble une bonne pratique

  • Le DAST est automatisé et s’exécute à la fréquence spécifiée par la classification de risque de l’application
  • Les tests d’intrusion sont menés par des testeurs qualifiés et indépendants (internes ou externes), avec un périmètre défini
  • Les environnements de test ne contiennent pas de données de production, ou celles-ci sont anonymisées de manière appropriée
  • Les constats issus des tests sont suivis jusqu’à une remédiation vérifiée

À quoi ressemble une mauvaise pratique

  • Le DAST n’est pas réalisé, ou les résultats sont ignorés
  • Les tests d’intrusion sont réalisés par l’équipe même qui a construit l’application, sans aucune indépendance
  • Les environnements de test contiennent des données de production non anonymisées
  • Les constats de test restent ouverts indéfiniment, sans escalade

Phase RELEASE

Ce qui devrait se passer

Les mises en production sont soumises à des flux d’approbation qui vérifient que toutes les activités de sécurité requises ont été menées à bien. Des points de contrôle de politique (policy gates) dans le pipeline de livraison imposent que les exigences de sécurité soient satisfaites avant que le code ne puisse progresser vers la production. Les décisions de mise en production sont documentées dans le cadre de la gestion des changements.

Preuves à demander

  • Enregistrements d’approbation de mise en production montrant la validation de la sécurité lorsqu’elle est requise
  • Résultats des points de contrôle de politique du pipeline de livraison (enregistrements réussite/échec horodatés)
  • Enregistrements de gestion des changements reliant les mises en production aux résultats des tests de sécurité
  • Enregistrements d’exception pour toute mise en production ayant contourné les points de contrôle de politique

À quoi ressemble une bonne pratique

  • Les points de contrôle de politique sont automatisés et imposés — le pipeline empêche la mise en production si les critères de sécurité ne sont pas satisfaits
  • La validation de la sécurité est requise pour les applications de niveau 1 et de niveau 2, avec une approbation documentée
  • Les contournements de points de contrôle nécessitent une approbation formelle d’exception et sont tracés
  • Les enregistrements de mise en production sont reliés à des résultats de scans et de tests spécifiques

À quoi ressemble une mauvaise pratique

  • Aucun point de contrôle de politique n’existe — les tests de sécurité ne sont qu’indicatifs
  • Des points de contrôle existent mais sont fréquemment contournés sans approbation formelle
  • Les approbations de mise en production font référence aux tests de sécurité mais ne renvoient pas à des résultats spécifiques
  • Les procédures de mise en production d’urgence sont utilisées de façon routinière, contournant les contrôles normaux

Phase DEPLOY

Ce qui devrait se passer

Les déploiements sont journalisés avec un niveau de détail suffisant pour établir ce qui a été déployé, quand, par qui et vers quel environnement. La configuration est validée par rapport aux référentiels de sécurité. Les environnements de production correspondent aux configurations qui ont été testées.

Preuves à demander

  • Journaux de déploiement avec horodatage, identifiants d’artefacts, identité de l’opérateur et environnement cible
  • Enregistrements de validation de configuration (vérifications par rapport aux référentiels de sécurité)
  • Preuves de parité d’environnement entre les tests et la production
  • Enregistrements de rollback lorsque des déploiements ont été annulés

À quoi ressemble une bonne pratique

  • Les déploiements sont automatisés, journalisés et auditables — les déploiements manuels en production sont interdits ou requièrent une approbation exceptionnelle
  • La détection de dérive de configuration identifie et signale les écarts par rapport aux référentiels de sécurité
  • L’infrastructure-as-code ou un équivalent assure la parité des environnements
  • Les déploiements en échec et les rollbacks sont documentés avec leur cause racine

À quoi ressemble une mauvaise pratique

  • Des déploiements manuels sans piste d’audit
  • Aucune validation de configuration — les paramètres de sécurité sont présumés plutôt que vérifiés
  • Des différences significatives entre les environnements de test et de production
  • L’accès au déploiement est largement accordé sans restrictions fondées sur les rôles

Phase MONITOR

Ce qui devrait se passer

Les applications en production sont surveillées pour détecter les événements de sécurité, les comportements anormaux et les nouvelles vulnérabilités. Des mécanismes de protection à l’exécution détectent les menaces actives et y répondent. Un processus de divulgation de vulnérabilités permet aux chercheurs externes de signaler les problèmes de manière responsable.

Preuves à demander

  • Configuration de la surveillance de sécurité et enregistrements d’alertes
  • Enregistrements de détection et de réponse aux incidents liés aux applications
  • Politique de divulgation de vulnérabilités (accessible publiquement)
  • Enregistrements des vulnérabilités signalées via les canaux de divulgation et de leur résolution
  • Enregistrements de déploiement des outils de sécurité à l’exécution

À quoi ressemble une bonne pratique

  • La surveillance de sécurité au niveau applicatif est active, avec des alertes acheminées vers l’équipe des opérations de sécurité
  • Les procédures de réponse aux incidents traitent spécifiquement les incidents au niveau applicatif (et pas seulement l’infrastructure)
  • Une politique de divulgation de vulnérabilités est publiée, et les signalements sont triés et suivis
  • Les vulnérabilités nouvellement divulguées dans les dépendances déclenchent une réévaluation via le SCA

À quoi ressemble une mauvaise pratique

  • Aucune surveillance au niveau applicatif — seule la surveillance de l’infrastructure est en place
  • Aucun processus de divulgation de vulnérabilités — les signalements externes n’ont aucun canal de réception
  • Les incidents de sécurité impliquant des applications sont traités au cas par cas, sans procédures documentées
  • Aucun processus pour répondre aux vulnérabilités de dépendances nouvellement divulguées

Synthèse : contrôles, preuves et signaux d’alerte par phase

Phase Contrôle clé Preuve produite Où la trouver Signal d’alerte
PLAN Modélisation des menaces Document de modèle de menaces Wiki, dépôt de conception, registre des risques Aucun modèle de menaces, ou modèles jamais mis à jour
CODE SAST / revue de code Résultats de scans, enregistrements de revue Journaux du pipeline CI/CD, outil de revue de code SAST non intégré ou résultats ignorés
BUILD SCA / SBOM Résultats de scans de dépendances, fichiers SBOM Système de build, dépôt d’artefacts Aucun inventaire de composants pour la production
TEST DAST / tests d’intrusion Rapports de scans, rapports de tests d’intrusion Outils de test de sécurité, archive de rapports Aucun test dynamique ou aucune indépendance
RELEASE Points de contrôle de politique / approbation Résultats des points de contrôle, enregistrements d’approbation Journaux du pipeline, système de gestion des changements Points de contrôle contournés sans approbation
DEPLOY Journalisation des déploiements Journaux de déploiement, vérifications de configuration Plateforme de déploiement, outils de surveillance Déploiements manuels sans piste d’audit
MONITOR Surveillance à l’exécution Journaux d’alertes, enregistrements d’incidents SIEM, plateforme de surveillance, gestion des tickets Aucune surveillance au niveau applicatif

Constats d’audit fréquents à travers les phases du SDLC

D’après les résultats d’audit typiques dans les organisations réglementées, les constats les plus fréquents comprennent :

  • Couverture incohérente : les contrôles de sécurité sont appliqués à certaines applications mais pas à d’autres, sans justification documentée de la différence
  • Lacunes de preuves : les contrôles sont décrits dans la politique mais les preuves de leur exécution sont incomplètes ou manquantes — en particulier pour la modélisation des menaces et la revue de code de sécurité
  • Traçabilité rompue : il est impossible de remonter d’une mise en production jusqu’aux résultats de tests de sécurité spécifiques qui l’ont validée
  • Constats non traités : les vulnérabilités identifiées lors des tests restent ouvertes pendant des mois ou des années, sans remédiation, escalade ni acceptation formelle du risque
  • Processus sans application : l’organisation dispose d’un document de SDLC sécurisé mais d’aucun point de contrôle automatisé ni vérification indépendante de son respect
  • Phase de surveillance négligée : un investissement important dans la sécurité en amont de la production, mais aucune surveillance à l’exécution ni gestion des vulnérabilités pour les applications en production

Évaluer la maturité du SDLC

Les auditeurs peuvent utiliser un modèle de maturité pour caractériser la qualité de mise en œuvre du SDLC sécurisé. Cela aide à formuler les constats et les recommandations de manière proportionnée.

Niveau de maturité Caractéristiques Implications pour l’audit
Ad hoc (niveau 1) Les activités de sécurité sont menées de manière incohérente, dépendent de l’initiative individuelle et ne sont pas documentées dans une politique. Aucune automatisation. Lacunes de contrôle fondamentales. Les constats seront nombreux et significatifs. Recommander l’établissement d’une politique et d’une gouvernance de base.
Défini (niveau 2) Des politiques et procédures existent. Les activités de sécurité sont documentées et attribuées. L’outillage est en place mais peut ne pas être appliqué de manière cohérente. Les contrôles existent mais leur efficacité opérationnelle peut être faible. Se concentrer sur la vérification d’une exécution cohérente et de la qualité des preuves.
Géré (niveau 3) Les contrôles de sécurité sont appliqués de manière cohérente, automatisés lorsque possible et suivis au moyen d’indicateurs. La gouvernance est active. Les contrôles fonctionnent efficacement. L’attention de l’audit se déplace vers les cas particuliers, les exceptions et l’amélioration continue.
Optimisé (niveau 4) Amélioration continue fondée sur des indicateurs. Identification proactive des menaces. La sécurité est pleinement intégrée à la culture et à l’outillage de développement. Automatisation avancée. Confiance élevée dans l’environnement de contrôle. L’audit se concentre sur la pérennité, l’adaptation aux nouvelles menaces et la gouvernance des capacités avancées.

Pour aller plus loin

Pour des ressources connexes, voir :

Ressources connexes pour les auditeurs

Nouveau dans l’audit CI/CD ? Commencez par notre guide de l’auditeur.