Pipeline DevSecOps fintech PCI-DSS v4

La fintech européenne réglementée qui nous a confié ce chantier opérait une plateforme de paiement traitant environ 11 millions de transactions par mois pour une centaine de marchands. Leur pipeline de livraison était entièrement manuelle : un release manager exécutait à la main les étapes de build, scannait les vulnérabilités via un Jenkins legacy, signait les déploiements sur un wiki interne et coordonnait par téléphone avec l'équipe ops. Lead time moyen de 6 heures par release, un incident production toutes les deux semaines, et — surtout — une non-conformité PCI-DSS v4 qui devenait critique : l'auditeur QSA avait posé un délai de 6 mois avant suspension de la certification, ce qui aurait équivalu à perdre les contrats Visa et Mastercard. PCI-DSS v4 (entrée en vigueur en octobre 2024) change radicalement le modèle de conformité par rapport à v3.2.1 : on passe d'un audit annuel ponctuel à une exigence de conformité continue intégrée au cycle de développement. Cinq exigences en particulier façonnent le travail DevSecOps : 6.4.3 demande un SAST exécuté à chaque changement de code applicatif, 8.4.2 impose une rotation effective des credentials avec preuve technique, 11.6.1 exige une infrastructure as code sécurisée et vérifiée, A3.2.5 régit la sécurité de la chaîne d'approvisionnement logicielle, et 12.10 impose des runbooks d'incident testés. Notre cible était de répondre à chacune d'elles par un mécanisme automatisé plutôt que par de la documentation rétroactive. La pipeline a été reconstruite sur GitHub Actions avec des reusable workflows partagés entre tous les services. À chaque commit, quatre scans tournent en parallèle : Semgrep SAST avec un set de règles custom fintech (interdiction de logger des PAN, détection d'usage de PRNG non cryptographique, vérification du masquage côté sortie), Snyk SCA sur les dépendances Node.js et Java, Gitleaks sur l'historique git complet pour la rétro-détection de secrets, et Trivy sur les images Docker produites en multi-stage build. Les findings critiques bloquent le merge ; les findings élevés exigent une justification explicite du tech lead, journalisée pour l'audit. Les artefacts sont signés cosign avec une clé hardware-backed (HSM AWS CloudHSM) et publiés dans un registry interne avec retention strictement append-only. À l'admission Kubernetes, une admission policy Kyverno vérifie la signature avant tout pull. Un artefact non signé ou signé avec une clé révoquée est refusé silencieusement par le cluster et un événement de sécurité est généré. Cela rend la chaîne d'approvisionnement traçable de bout en bout : du commit Git au pod en production, chaque maillon a une preuve cryptographique. La gestion des secrets est passée d'un fichier `.env` partagé par mail (oui) à HashiCorp Vault avec rotation automatique tous les 90 jours. L'intégration utilise External Secrets Operator côté Kubernetes : les secrets sont matérialisés en mémoire dans les pods, jamais sur disque, et la rotation Vault déclenche un rolling restart contrôlé via une annotation `reloader.stakater.com/auto`. Les credentials base de données et certificats TLS suivent le même cycle. Le résultat tangible : un Gitleaks fait à froid sur l'historique post-migration n'a remonté zéro secret réel. L'infrastructure est entièrement Terraformée, et les pipelines Terraform utilisent OIDC pour s'authentifier auprès d'AWS — fin des access keys longue durée stockées dans GitHub. Chaque plan Terraform passe par checkov + tfsec avant apply, et un job Terraform Drift détecte quotidiennement les divergences entre le code et l'état réel du cloud. Toute drift non justifiée déclenche un ticket de sécurité avec SLA de remédiation de 48 heures. Cette discipline a tué l'angle mort classique du « ça a été modifié à la main pour un debug urgent et personne ne l'a remis dans le code ». Le déploiement utilise Argo CD avec stratégie canary progressive : 5% du trafic pendant 10 minutes, puis 25% pendant 15 minutes, puis 50% pendant 15 minutes, puis 100%. À chaque palier, Argo Rollouts compare automatiquement les SLI du canary contre le baseline (latence p95, error rate, saturation CPU) ; un écart au-delà des seuils déclenche un rollback automatique en moins de 90 secondes, sans intervention humaine. Couplé au signal d'observabilité OpenTelemetry, ce mécanisme a transformé l'incident-management : une release problématique se rollback toute seule avant que l'équipe ait fini de lire l'alerte. Après cinq mois d'effort, l'auditeur QSA a validé la conformité PCI-DSS v4 sans réserve. Le lead time moyen est passé de 6 heures à 1 heure 50 ; les incidents production sont espacés tous les 3,5 mois en moyenne contre toutes les deux semaines auparavant ; le MTTR est descendu à 22 minutes contre 3 heures ; la couverture de tests automatisés est passée de 41% à 78% ; et zéro secret n'a été exposé sur la période. Plus durable que les chiffres : l'équipe ne parle plus de la conformité comme d'une contrainte annuelle mais comme d'une propriété d'infrastructure, ce qui est exactement le changement que PCI-DSS v4 cherchait à provoquer.