Fintech
Pipeline DevSecOps fintech PCI-DSS v4
Une fintech européenne réglementée traitait 11 millions de transactions par mois avec une pipeline de livraison entièrement manuelle. Son auditeur QSA avait posé un ultimatum : conformité PCI-DSS v4 sous six mois, ou suspension de la certification — et la perte des contrats Visa et Mastercard.
Contexte
Fintech européenne réglementée opérant une plateforme de paiement : environ 11 millions de transactions par mois pour une centaine de marchands. La pipeline de livraison était entièrement manuelle — un release manager exécutait les builds à la main, scannait via un Jenkins legacy, signait les déploiements sur un wiki interne et coordonnait par téléphone avec les ops.
01 — Le défi
Le défi
Lead time moyen de 6 heures par release, un incident production toutes les deux semaines, et surtout une non-conformité PCI-DSS v4 critique. PCI-DSS v4 (en vigueur depuis octobre 2024) impose un changement de modèle : de l'audit annuel ponctuel à la conformité continue intégrée au cycle de développement. Il fallait répondre par des mécanismes automatisés — pas par de la documentation rétroactive — sans ralentir la vélocité produit.
02 — L'approche
L'approche
Nous avons cartographié cinq exigences clés de PCI-DSS v4 (6.4.3, 8.4.2, 11.6.1, A3.2.5, 12.10) et répondu à chacune par un mécanisme automatisé. La pipeline GitHub Actions exécute quatre scans en parallèle à chaque commit ; les artefacts sont signés cosign et vérifiés à l'admission Kubernetes ; les secrets passent par Vault avec rotation 90 jours ; l'infrastructure est Terraformée avec contrôle de drift ; et le déploiement canary Argo CD se rollback automatiquement sous 90 secondes.
Cartographie PCI-DSS v4
Cadrage des cinq exigences structurantes (6.4.3, 8.4.2, 11.6.1, A3.2.5, 12.10) et définition d'un mécanisme automatisé par exigence.
Pipeline CI sécurisée
GitHub Actions avec quatre scans parallèles (Semgrep, Snyk, Gitleaks, Trivy), artefacts signés cosign et vérifiés par Kyverno à l'admission.
Secrets & infrastructure
HashiCorp Vault avec rotation 90 jours, Terraform via OIDC, checkov + tfsec et détection quotidienne de drift à SLA 48 h.
Déploiement canary & rollback
Argo CD en canary progressif (5 → 25 → 50 → 100 %), comparaison automatique des SLI et rollback sous 90 secondes sans intervention humaine.
03 — Résultats
Résultats
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.
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.
Détails techniques
Exigences PCI-DSS v4 visées
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 par un mécanisme automatisé plutôt que par de la documentation rétroactive.
Pipeline CI & scans de sécurité
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.
Chaîne d'approvisionnement signée
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.
Gestion des secrets
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.
Infrastructure as Code & contrôle de drift
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 ».
Déploiement canary & rollback automatique
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.
Livrables
- Matrice de conformité PCI-DSS v4 (exigence → mécanisme)
- Pipeline GitHub Actions avec SAST/SCA/secret-scan/image-scan
- Signature cosign + policy d'admission Kyverno
- Gestion des secrets Vault avec rotation automatique
- Infrastructure Terraform avec checkov/tfsec et contrôle de drift
- Déploiement canary Argo CD avec rollback SLI automatique