Développement sécurisé : relier CI/CD et preuves d’audit

Publié et mis à jour le 1 octobre 2026 · Rédaction : Scope & Evidence

Les preuves de développement sécurisé doivent décrire comment votre équipe maîtrise les changements du SaaS. Une politique de revue de code n’explique pas seule les déploiements urgents, les dépendances et les droits dans la chaîne CI/CD. Pour préparer un audit, reliez les règles aux événements réels dans vos outils. Le SSDF du NIST constitue une ressource de travail ; il ne certifie pas votre produit et ne remplace pas les exigences du référentiel retenu.

Cadre de référence : source primaire du sujet. Les recommandations opérationnelles ci-dessous sont à adapter à votre organisation.

Décrire le chemin du changement

Cartographiez le parcours entre la demande, le code, les tests et la production. Identifiez les validations humaines et les contrôles automatisés. La description doit inclure les changements d’infrastructure et de configuration, pas uniquement les modifications applicatives. Définissez les exceptions, notamment les interventions urgentes. Un contrôle pertinent s’adapte à votre organisation tout en laissant des traces. Évitez une procédure qui promet une approbation systématique alors que votre outil permet des déploiements directs non suivis.

Utiliser les traces natives

Les demandes de fusion, les résultats de tests et les historiques de déploiement peuvent soutenir l’examen des changements. Préservez les liens entre ces éléments et les versions mises en production. Les contrôles doivent rester explicables lorsqu’un outil change. Une capture d’un pipeline vert ne permet pas de retrouver le changement ni les validations associées. Demandez aux responsables de montrer un parcours complet, puis examinez aussi une exception. L’objectif est de comprendre le fonctionnement, pas de sélectionner seulement les cas favorables.

Examiner les dépendances et vulnérabilités

Identifiez qui suit les dépendances et comment les alertes sont traitées. Un outil d’analyse peut détecter des sujets, mais il faut encore décider la priorité et vérifier la correction. Conservez la raison d’un report et les mesures temporaires lorsqu’elles existent. Les règles doivent tenir compte du contexte d’exploitation et des risques du SaaS. N’annoncez pas de délai universel de correction sans une politique validée et des engagements précis. Le client doit recevoir une formulation compatible avec vos pratiques réelles.

Protéger les accès de la chaîne de livraison

Les comptes de service, les jetons et les droits d’administration de CI/CD méritent une revue dédiée. Décrivez leurs propriétaires, leur usage et les possibilités de retrait. Ne copiez jamais les valeurs de secrets dans un dossier de preuve. Un inventaire peut utiliser des références neutres et des métadonnées suffisantes. Examinez aussi la séparation entre test et production ainsi que les données utilisées en développement. Ces sujets doivent être reliés aux risques et aux responsabilités de votre équipe.

Contrôler les exceptions après coup

Une urgence peut suivre un circuit particulier, à condition que ce circuit soit décrit et examiné. Conservez la justification, les actions et la revue ultérieure prévue dans votre organisation. Les événements doivent rester datés selon leur réalisation réelle. Ne reconstruisez pas une approbation antérieure qui n’a pas eu lieu. Utilisez les exceptions pour adapter les règles si elles sont trop souvent contournées. La préparation peut inclure un atelier sur un changement réel, sans diffuser les informations sensibles du produit.

Vérifier un changement sans choisir le cas idéal

Sélectionnez aussi un changement qui a rencontré un problème ou utilisé un circuit d’exception. Comparez les décisions aux règles internes. La préparation peut alors révéler une ambiguïté sur les validations ou sur la conservation des résultats de test. Définissez une correction et sa vérification. Une série de déploiements réussis ne dispense pas de comprendre les exceptions ; celles-ci décrivent souvent les limites réelles du processus et les besoins d’amélioration.

Exemple de travail, fictif

Exemple fictif : un correctif urgent est déployé par un responsable habilité selon une procédure d’exception. Le dossier relie l’incident au changement, aux tests possibles et à la revue effectuée ensuite. Le CTO compare ce cas aux règles internes et identifie une amélioration du contrôle des accès CI/CD. Cet exemple ne signifie pas que tous les déploiements urgents sont acceptables ; l’examen dépend des critères et du fonctionnement observé par l’auditeur.

Ce que votre dossier doit permettre de vérifier

Un parcours du changement incluant infrastructure et configuration.
Des traces reliant demande, validation, tests et déploiement.
Un traitement documenté des alertes et dépendances.
Un inventaire des comptes et droits de la chaîne CI/CD.
Des exceptions datées avec justification et revue.

Questions avant de décider

Un scanner suffit-il à démontrer le développement sécurisé ?

Non. Le résultat doit être relié au traitement des alertes, aux changements et aux responsabilités. L’outil soutient le travail ; il ne prend pas les décisions à votre place.

Faut-il une validation humaine pour tout changement ?

Les règles se définissent selon le contexte et les risques, puis se vérifient dans le cadre choisi. Ce guide ne prescrit pas un circuit universel pour tous les SaaS.

Peut-on transmettre des secrets à l’auditeur ?

Les valeurs de secrets ne doivent pas être copiées dans le dossier. Préparez des preuves de gestion et des références neutres, puis convenez des modalités d’examen nécessaires.

Préparer la suite du travail

Sources et portée de lecture

Les sources ci-dessous documentent le cadre ou le fait cité. Les propositions d’organisation sont des conseils de préparation à adapter à votre situation. Elles ne reproduisent pas le texte des normes et ne constituent pas une décision d’audit ni un avis juridique.