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

Le Secure SDLC comme cadre de contrôle

Le Secure Software Development Lifecycle (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 construire des logiciels plus sûrs. Pour les auditeurs et les responsables conformité, cependant, 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 devraient avoir lieu, des preuves spécifiques devraient être générées et des résultats spécifiques devraient être vérifiables. Lorsqu’une organisation prétend exploiter un Secure SDLC, les auditeurs doivent aller au-delà de la documentation des 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 ressemblent les bonnes pratiques 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 dans la planification du projet avant tout début de développement. Cela inclut la modélisation des menaces pour identifier les vecteurs d’attaque potentiels, la définition des exigences de sécurité parallèlement aux exigences fonctionnelles et la classification de l’application selon le cadre de classification des risques de l’organisation.

Preuves à demander

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

Ce à quoi ressemblent les bonnes pratiques

Les modèles de menaces sont créés pour toutes les applications de Tier 1 et Tier 2 et mis à jour lors de changements d’architecture
Les exigences de sécurité sont traçables — chaque menace identifiée dans le modèle a une exigence correspondante ou un risque accepté
La classification détermine les exigences de contrôle en aval (fréquence des tests, workflows d’approbation)
Le personnel de sécurité participe aux activités de planification, attesté par les comptes rendus de réunion

Ce à quoi ressemblent les mauvaises pratiques

Aucun modèle de menaces n’existe, ou ils ont été créés 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 manquante ou a été effectuée sans l’apport de la sécurité ou de la conformité
La sécurité n’est impliquée qu’au moment des tests ou du déploiement

Phase CODE

Ce qui devrait se passer

Les développeurs suivent des standards de codage sécurisé documentés. Les modifications de code sont revues pour les problèmes de sécurité — soit par revue par les pairs avec des réviseurs sensibilisés à la sécurité, soit par des tests automatisés SAST (Static Application Security Testing). Le scanning de secrets empêche les identifiants, clés API et tokens d’être commités dans les dépôts.

Preuves à demander

Document de standards de codage sécurisé, approuvé et versionné
Enregistrements de revue de code montrant des commentaires liés à la sécurité et leurs résolutions
Résultats de scan SAST intégrés dans le workflow de développement
Configuration du scanning de secrets et enregistrements d’alertes
Registres de formation des développeurs aux pratiques de codage sécurisé

Ce à quoi ressemblent les bonnes pratiques

SAST s’exécute automatiquement sur chaque pull request ou commit, avec des résultats visibles pour les développeurs
Les enregistrements de revue de code montrent des constats de sécurité identifiés et traités — pas seulement une revue fonctionnelle
Le scanning de secrets bloque les commits contenant des identifiants, avec un processus documenté pour la rotation de tout secret exposé
Les développeurs reçoivent une formation annuelle (minimum) de codage sécurisé pertinente pour leur stack technologique

Ce à quoi ressemblent les mauvaises pratiques

SAST est exécuté manuellement ou uniquement avant les releases, ce qui signifie que les vulnérabilités s’accumulent
Les revues de code existent mais n’incluent jamais de retour lié à la sécurité
Aucun scanning de secrets n’est en place, ou les alertes sont ignorées
Les standards de codage sécurisé sont obsolètes ou non alignés avec les technologies utilisées

Phase BUILD

Ce qui devrait se passer

Le processus de build inclut une analyse de composition logicielle (SCA) pour identifier les vulnérabilités dans les dépendances tierces et open-source. Un SBOM (Software Bill of Materials) est généré pour chaque build afin de maintenir un inventaire de tous les composants. Les artefacts de build sont signés pour garantir l’intégrité et prévenir la falsification.

Preuves à demander

Résultats de scan SCA pour les builds récents, montrant les vulnérabilités identifiées et leur traitement
Enregistrements SBOM pour les releases en production
Configuration de signature des artefacts et enregistrements de vérification
Politique pour les seuils de vulnérabilités acceptables dans les dépendances

Ce à quoi ressemblent les bonnes pratiques

SCA s’exécute sur chaque build avec des politiques définies pour bloquer les builds contenant des vulnérabilités critiques ou de haute sévérité
Les SBOM sont générés automatiquement et stockés avec les enregistrements de release
La signature des artefacts est imposée — les artefacts non signés ne peuvent pas être déployés en production
Un processus existe pour le patching d’urgence des vulnérabilités critiques de dépendances

Ce à quoi ressemblent les mauvaises pratiques

SCA n’est pas intégré dans le processus de build ou ne s’exécute que périodiquement
Pas de génération de SBOM — l’organisation ne peut pas identifier quels composants sont en production
Pas de signature d’artefacts — il n’y a 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

Des tests DAST (Dynamic Application Security Testing) sont effectués sur les applications en cours d’exécution pour identifier les vulnérabilités que l’analyse statique ne peut pas détecter (failles d’authentification, problèmes de configuration, vulnérabilités d’injection en runtime). Les tests de pénétration par du personnel qualifié apportent une perspective adversariale. Les environnements de test sont isolés de la production pour prévenir les fuites de données.

Preuves à demander

Résultats de scan DAST et enregistrements de remédiation
Rapports de tests de pénétration avec périmètre, méthodologie, constats et état de remédiation
Preuves d’isolation des environnements (diagrammes réseau, contrôles d’accès)
Enregistrements montrant que la fréquence des tests est alignée avec le niveau de risque de l’application

Ce à quoi ressemblent les bonnes pratiques

DAST est automatisé et s’exécute à la fréquence spécifiée par la classification de risque de l’application
Les tests de pénétration sont menés par des testeurs indépendants qualifiés (internes ou externes) avec un périmètre défini
Les environnements de test ne contiennent pas de données de production, ou les données de production sont correctement masquées
Les constats des tests sont suivis jusqu’à la remédiation vérifiée

Ce à quoi ressemblent les mauvaises pratiques

DAST n’est pas effectué, ou les résultats sont ignorés
Les tests de pénétration sont effectués par la même équipe qui a construit l’application, sans indépendance
Les environnements de test contiennent des données de production non masquées
Les constats de tests restent ouverts indéfiniment sans escalade

Phase RELEASE

Ce qui devrait se passer

Les releases sont soumises à des workflows d’approbation qui vérifient que toutes les activités de sécurité requises ont été complétées. Les portes de politique dans le pipeline de livraison imposent que les exigences de sécurité soient satisfaites avant que le code puisse passer en production. Les décisions de release sont documentées dans le cadre de la gestion des changements.

Preuves à demander

Enregistrements d’approbation de release montrant la validation sécurité lorsque requise
Résultats des portes de politique du pipeline de livraison (enregistrements pass/fail avec horodatages)
Enregistrements de gestion des changements liant les releases aux résultats des tests de sécurité
Enregistrements d’exception pour toute release ayant contourné les portes de politique

Ce à quoi ressemblent les bonnes pratiques

Les portes de politique sont automatisées et imposées — le pipeline empêche la release si les critères de sécurité ne sont pas satisfaits
La validation sécurité est requise pour les applications de Tier 1 et Tier 2, avec une approbation documentée
Les contournements de portes nécessitent une approbation formelle d’exception et sont suivis
Les enregistrements de release sont liés à des résultats de scan et des résultats de tests spécifiques

Ce à quoi ressemblent les mauvaises pratiques

Aucune porte de politique n’existe — les tests de sécurité sont uniquement consultatifs
Les portes existent mais sont fréquemment contournées sans approbation formelle
Les approbations de release mentionnent les tests de sécurité mais ne renvoient pas à des résultats spécifiques
Les procédures de release d’urgence sont utilisées de manière routinière, contournant les contrôles normaux

Phase DEPLOY

Ce qui devrait se passer

Les déploiements sont journalisés avec suffisamment de détails pour établir ce qui a été déployé, quand, par qui et dans 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 horodatages, identifiants d’artefacts, identité du déployeur et environnement cible
Enregistrements de validation de configuration (vérifications du référentiel de sécurité)
Preuves de parité d’environnement entre test et production
Enregistrements de rollback lorsque des déploiements ont été annulés

Ce à quoi ressemblent les bonnes pratiques

Les déploiements sont automatisés, journalisés et auditables — les déploiements manuels en production sont interdits ou nécessitent une approbation exceptionnelle
La détection de dérive de configuration identifie et alerte sur les écarts par rapport aux référentiels de sécurité
L’Infrastructure-as-Code ou équivalent assure la parité des environnements
Les déploiements échoués et les rollbacks sont documentés avec l’analyse de cause racine

Ce à quoi ressemblent les mauvaises pratiques

Déploiements manuels sans piste d’audit
Pas de validation de configuration — les paramètres de sécurité sont supposés plutôt que vérifiés
Différences significatives entre les environnements de test et de production
L’accès au déploiement est largement accordé sans restrictions basées sur les rôles

Phase MONITOR

Ce qui devrait se passer

Les applications en production sont surveillées pour les événements de sécurité, les comportements anormaux et les nouvelles vulnérabilités. Les mécanismes de protection en runtime détectent et répondent aux menaces actives. 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 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 par les canaux de divulgation et leur résolution
Enregistrements de déploiement des outils de sécurité en runtime

Ce à quoi ressemblent les bonnes pratiques

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 (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 SCA

Ce à quoi ressemblent les mauvaises pratiques

Pas de surveillance au niveau applicatif — seule la surveillance d’infrastructure est en place
Pas de processus de divulgation de vulnérabilités — les signalements externes n’ont pas de canal d’entrée
Les incidents de sécurité impliquant des applications sont traités de manière ad-hoc sans procédures documentées
Pas de 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é	Artefact de preuve	Où le trouver	Signal d’alerte
PLAN	Modélisation des menaces	Document de modèle de menaces	Wiki, dépôt de conception, registre des risques	Pas de modèles de menaces ou modèles jamais mis à jour
CODE	SAST / revue de code	Résultats de scan, 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 scan des dépendances, fichiers SBOM	Système de build, dépôt d’artefacts	Pas d’inventaire des composants en production
TEST	DAST / tests de pénétration	Rapports de scan, rapports de pentest	Outils de tests de sécurité, archive de rapports	Pas de tests dynamiques ou pas d’indépendance
RELEASE	Portes de politique / approbation	Résultats des portes, enregistrements d’approbation	Journaux du pipeline, système de gestion des changements	Portes contournées sans approbation
DEPLOY	Journalisation des déploiements	Journaux de déploiement, vérifications de config	Plateforme de déploiement, outils de surveillance	Déploiements manuels sans piste d’audit
MONITOR	Surveillance en runtime	Journaux d’alertes, enregistrements d’incidents	SIEM, plateforme de surveillance, ticketing	Pas de surveillance au niveau applicatif

Constats d’audit courants à travers les phases du SDLC

Sur la base des résultats d’audit typiques dans les organisations réglementées, les constats les plus fréquents incluent :

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 dans les preuves : Les contrôles sont décrits dans les politiques mais les preuves d’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 n’est pas possible de remonter d’une release en production aux résultats de tests de sécurité spécifiques qui l’ont validée
Constats obsolètes : Les vulnérabilités identifiées lors des tests restent ouvertes pendant des mois ou des années sans remédiation, escalade ou acceptation formelle du risque
Processus sans application : L’organisation possède un document Secure SDLC mais pas de portes automatisées ni de vérification indépendante de son application
Phase MONITOR négligée : Investissement significatif dans la sécurité pré-production mais pas de surveillance en runtime ni de gestion des vulnérabilités pour les applications en production

Évaluation de la maturité du SDLC

Les auditeurs peuvent utiliser un modèle de maturité pour caractériser le niveau d’implémentation du Secure SDLC. Cela aide à cadrer 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 effectuées de manière incohérente, dépendent de l’initiative individuelle et ne sont pas documentées dans les politiques. Pas d’automatisation.	Lacunes fondamentales dans les contrôles. Les constats seront nombreux et significatifs. Recommander l’établissement d’une politique et d’une gouvernance de base.
Défini (Niveau 2)	Les politiques et procédures existent. Les activités de sécurité sont documentées et assignées. L’outillage est en place mais peut ne pas être appliqué de manière cohérente.	Les contrôles existent mais l’efficacité opérationnelle peut être faible. Se concentrer sur la vérification de l’exécution cohérente et 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 surveillés par des métriques. La gouvernance est active.	Les contrôles fonctionnent efficacement. L’audit se concentre sur les cas limites, les exceptions et l’amélioration continue.
Optimisé (Niveau 4)	Amélioration continue basée sur les métriques. Identification proactive des menaces. La sécurité est pleinement intégrée dans la culture de développement et l’outillage. Automatisation avancée.	Confiance élevée dans l’environnement de contrôle. L’audit se concentre sur la durabilité, l’adaptation aux nouvelles menaces et la gouvernance des capacités avancées.

Lectures complémentaires

Pour des conseils connexes, voir :

Ressources connexes pour les auditeurs

Glossaire — Définitions en langage clair des termes techniques
Comment les auditeurs examinent les pipelines CI/CD
Conformité continue via CI/CD
Contrôles de sécurité CI/CD essentiels

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