Dmitrii CreedResponsable DevOps, SRE et sécurité · Tbilissi
Ouvert aux postes de Head of DevOps, SRE & Security

Head of DevOps, SRE & Security (DevSecOps)

Group CTO de 145 personnes dans six pays, et toujours les mains dans le technique. Infrastructure de paiement pour une banque centrale, une plateforme d'agents IA sur trois clouds, dix A100 en bare metal et deux certifications validées en audit.

  • 99,999 %sur Bakong, le système de paiement de la Banque nationale du Cambodge
  • 0 constatlors de l'audit de surveillance ISO 27001 ; SOC 2 Type II réussi deux fois
  • 145 personnesdans six pays, rattaché au directeur général
Parcours

Parcours

2013 à 2019Réseaux, parcs Linux, recherche en sécurité
2019 à 2025Soramitsu : Head of SRE & Security, puis Group CTO
Depuis 2025Everworker : Head of DevOps, SRE & Security

Ce que j'ai piloté

Huit domaines, une même exigence de preuve

Leadership

145 personnes · 6 pays
Group CTO · Head of DevOps, SRE & Security
  • Toute l'organisation m'était rattachée, avec des bureaux au Japon, en Russie, en Suisse, au Monténégro, en Thaïlande et à Dubaï. Je rendais compte au directeur général.
  • J'ai d'abord construit l'organisation technique : 37 reports directs au plus fort, dont 12 en DevOps, 6 en sécurité et 19 en QA.
  • Chez Everworker : terrain vierge, sans outils, sans processus, sans effectifs. J'ai constitué une équipe sécurité de 4 personnes.

Paiements et CBDC

99,999 %
Bakong · pilotes CBDC
  • Fiabilité et sécurité de Bakong, le système de paiement de la Banque nationale du Cambodge, écrit en Java sur Hyperledger Iroha.
  • Plus de 150 milliards de dollars réglés en 2024, soit environ 330 % du PIB du Cambodge, et 1,3 milliard de paiements en 2025, selon les chiffres publiés par la NBC.
  • Pilotes CBDC dans l'ensemble du groupe. J'ai contribué au prix « CBDC Partner of the Year » de Central Banking, 2020.

Plateforme et IA

300+ apps · 99 % IaC
AWS · Azure · GCP · bare metal
  • Une plateforme d'agents IA sur trois clouds, livrée en SaaS et auto-hébergée dans les comptes mêmes des clients.
  • Référencement sur AWS Marketplace avec des Helm charts pour trois clouds, livré seul après qu'on m'a dit qu'il fallait des partenaires payants. AWS Marketplace
  • 10 × NVIDIA A100 en bare metal chez Moro Hub, à Dubaï (Tier III), après qu'une seule instance GPU oubliée a brûlé des milliers de dollars en deux jours.
  • Plus de 300 applications, plus de 700 dépôts, 6 organisations GitHub. Temps de build réduits de 40 %, coûts réduits de plus de 30 %.

Fiabilité

MTTR −60 %
Pratique SRE créée de zéro
  • SRE intégré à plus de 20 équipes stream-aligned dans 4 régions : SLI, SLO, budgets d'erreur, commandement des incidents, revues sans blâme.
  • SLA passé de 99 % à 99,99 %. Sauvegarde et DR automatisés pour 5 systèmes critiques, avec des restaurations réellement exécutées.
  • Une astreinte avec laquelle on peut vivre : rotation quotidienne, un suppléant à chaque tour de garde, un runbook et une métrique pour chaque alerte.

Sécurité et conformité

0 constat en audit de surveillance
ISO 27001 · SOC 2 Type II · NIST CSF
  • ISO/IEC 27001:2022 : 5 non-conformités mineures de l'audit initial levées, puis première année de surveillance validée sans aucun constat. Trust Center
  • SOC 2 Type II réussi deux années de suite, périmètre étendu à la vie privée et à la disponibilité. J'ai piloté le programme NIST CSF à la demande de clients.
  • SDLC sécurisé pour plus de 100 développeurs : modèles de menaces STRIDE et VAST, scoring CVSS et EPSS, Security Champions. Fenêtres d'exposition réduites de 70 %.
  • Pentest indépendant : 12 constats (1 élevé, 6 moyens, 5 faibles) triés ; les principaux sont devenus des régressions DAST, pour qu'ils restent testés.

Produits

2 produits · 2 × 12 personnes
pris en charge de bout en bout
  • Un système de paiement pour des îles des Caraïbes, avec sa propre équipe de 12 personnes.
  • Un système de points de fidélité pour un grand écosystème, avec sa propre équipe de 12 personnes.

Web3

mêmes garde-fous que les paiements
Polkadot · Klaytn · SORA
  • Subventions de la Web3 Foundation, développement dans l'écosystème Polkadot, Klaytn et l'écosystème SORA, sur les mêmes pipelines et garde-fous de sécurité que les systèmes de paiement.
  • Intervenant à Next-Generation Payments 2023 et à des conférences fintech à Bangkok.

Open source

Scorecard 10
Simple Container
  • Simple Container, outil de déploiement en Go. GitHub
  • OpenSSF Best Practices Gold et un Scorecard vérifié de 10, sans aucun contrôle en dessous de 10. Scorecard

Retours d'incidents

Issus de la réponse à incident, d'audits et de travaux sur des plateformes clientes. Chacun s'est conclu par un contrôle, pas par une rustine.

Sécurité · Réponse à incidentCas clos

Exfiltration de code source et tentative d'extorsion

87 000 événements analysés
  1. Détection

    Activité anormale sur les dépôts.

  2. Investigation

    Analyse forensique d'un export d'audit de 87 000 événements. La portée de l'identifiant a été retestée, non présumée.

  3. Correction

    Confinement et réinitialisation de l'identifiant, puis accès de toute l'organisation reconstruits en IaC Pulumi pour que les droits accordés manuellement ne puissent pas revenir.

Disponibilité · Plateforme clienteCas clos

Une rotation d'identifiants que la supervision ne pouvait pas voir

0 donnée perdue · corrigé le jour même
  1. Détection

    Sur une plateforme cliente, la base de données managée a fait tourner son mot de passe maître comme prévu et l'application a perdu sa connexion à la base pendant la nuit. Aucune alerte ne s'est déclenchée.

  2. Investigation

    L'application ne lisait le mot de passe qu'une fois, au déploiement. Une revue de l'alerting a montré que chaque règle était aveugle à sa façon : le processus restait up, les seuils d'erreur étaient au-dessus de ce que ce trafic peut atteindre même en panne totale, et l'alerte du pool incriminait des requêtes lentes.

  3. Correction

    Le jour même : l'application est passée sur un rôle à moindre privilège avec un mot de passe que l'équipe maîtrise, et un déploiement échoue désormais si cet identifiant ne peut pas se connecter. Nouvelles alertes sur pool vide, endpoint de health, plancher de connexions et sauvegarde manquante. Aucune donnée n'a été perdue.

Disponibilité · Plateforme clienteCas clos

Des webhooks en échec une requête sur quatre

corrigé en amont pour tous les utilisateurs
  1. Détection

    Sur une plateforme cliente, des 500 sur les webhooks, des signatures non concordantes et des erreurs CSRF ont touché environ un quart des requêtes POST après qu'une image en amont a changé sous la release épinglée.

  2. Investigation

    Les corps de requête chunked arrivaient vides dans l'application : elle lit le corps via Content-Length, qu'une requête chunked n'a pas. Les 500 n'étaient journalisées nulle part, car le logging par défaut du framework les avalait avec debug désactivé.

  3. Correction

    Le buffering des requêtes est devenu le comportement par défaut de l'outil de déploiement open source, l'application reconstitue les chunks au niveau WSGI, les webhooks ne répondent jamais en 5xx et les erreurs vont dans des logs structurés.

Disponibilité · Plateforme clienteCas clos

Connexions refusées, 14 secondes à la fois

0 échec sur 7 254 sondes
  1. Détection

    Les utilisateurs finaux d'une plateforme cliente ont signalé des connexions refusées sur le port 443. L'autoscaler du cloud avait évincé le proxy de bordure 37 fois dans la journée, contre 0 à 8 par jour auparavant.

  2. Investigation

    Le proxy se vidait en 10 secondes ; le load balancer en mettait environ 24 pour retirer le nœud. Reproduit avec une sonde toutes les demi-secondes : une fenêtre de 14 secondes où environ la moitié des nouvelles connexions échouaient.

  3. Correction

    Un drain plus long que le health check, des proxys répartis strictement entre les hôtes, et les deux réglages ajoutés à l'outil open source. 0 échec sur 7 254 sondes au fil des déploiements.

Disponibilité · Plateforme clienteCas clos

Un processus de release avec une étape contournable

les déploiements sont désormais tout ou rien
  1. Détection

    Sur une plateforme cliente, la production a tourné 20 à 30 minutes sans son processeur de tâches de fond alors que l'uptime restait au vert : le worker n'avait pas été déployé, donc rien ne pouvait alerter.

  2. Investigation

    La release reposait sur deux étapes manuelles distinctes, web puis worker, et rien ne vérifiait que les deux avaient été exécutées. Les contrôles avant merge et l'admission control ont été écartés : git était correct, et le worker n'avait jamais été soumis.

  3. Correction

    Les services scindés se déploient désormais dans un seul workflow ordonné, qui passe au rouge si les deux moitiés ne réussissent pas, et le déploiement autonome du worker a été supprimé. Les alertes de parité restent en filet de sécurité.

Détection · Existant héritéCas clos

Des alertes auxquelles personne ne se fiait

89 % de faux → 0
  1. Détection

    232 déclenchements d'alarmes CloudTrail en 14 jours, environ 89 % de faux positifs.

  2. Correction

    8 détecteurs au-delà de la baseline CIS, avec exclusions par détecteur : un seul chiffre de déclenchements par jour, zéro faux positif sur la première fenêtre, un runbook pour chaque alerte.

Détection · Plateforme clienteCas clos

Le chien de garde qui ne gardait plus

les exécutions bloquées se libèrent seules
  1. Détection

    Le dead-man's switch d'un client s'était arrêté en silence : pendant 4,5 jours, chaque exécution planifiée s'est terminée annulée.

  2. Investigation

    Une exécution que la plateforme de CI avait laissée en file a gardé son concurrency group indéfiniment. Les timeouts ne s'appliquent pas avant le démarrage d'un job, donc chaque exécution suivante attendait puis était annulée. Récidive en moins d'un jour.

  3. Correction

    Les workflows planifiés courts annulent désormais l'exécution en cours, de sorte qu'une exécution bloquée est remplacée par la suivante au lieu de la bloquer.

Coût · Plateforme clienteCas clos

Une facture en hausse de 52 % pour 4 % de CPU

11 nœuds épinglés → 5-9 à la demande
  1. Détection

    Revue des coûts sur une plateforme cliente : la prévision a bondi de 52 % en un mois, avec 18 nœuds tournant à environ 4 % de CPU.

  2. Investigation

    Le disruption budget par défaut de l'outil de déploiement laissait zéro éviction autorisée aux services à réplique unique, donc l'autoscaler ne pouvait jamais drainer un nœud. Chaque nouveau white-label en épinglait un de plus.

  3. Correction

    Un budget autorisant une éviction, déployé sur 13 dépôts. La production est passée de 11 nœuds épinglés à 5-9 à la demande, le staging de 7 à 3. Le changement du défaut en amont a été retenu : trop de changements accumulés pour une production de paiements.

Gouvernance · Existant héritéCas clos

Un ISMS qui déclarait des outils que l'entreprise n'avait pas

29 politiques vérifiées
  1. Détection

    29 politiques héritées, rédigées par IA, citant du MDM, de l'EDR et des services d'annuaire qui n'existaient pas.

  2. Correction

    Vérification de chaque outil et rôle cité rendue obligatoire avant approbation. L'IA rédige, la preuve tranche.

Comment un changement arrive en production

19 actions partagées, 8 workflows réutilisables, un seul point de contrôle

  1. 01 planIaC

    Terraform, Pulumi, politiques as code avec CrossGuard

  2. 02 lintSAST

    Semgrep, 107 règles personnalisées en 5 langages

  3. 03 scanDépendances et secrets

    Trivy, Grype, TruffleHog, zizmor, poutine

  4. 04 signProvenance

    Syft SBOM, Cosign sans clé, provenance SLSA

  5. 05 gateDefectDojo

    tout nouveau constat au-dessus d'informatif bloque la fusion

  6. 06 deploySans clé

    GitOps, GitHub OIDC, aucune clé cloud statique

  7. 07 verifyExécution

    admission Kyverno, alertes de burn rate sur les SLO

$ deploy --env production
✓ signature vérifiée en trois points : après la signature, avant le déploiement, à l'admission

La sécurité comme plateforme

Ce à quoi chaque dépôt se branche

Plateforme interne de sécurité

19 actions · 8 workflows
  • La sécurité fournie comme un service aux équipes produit : un dépôt se branche sur l'analyse des secrets, des dépendances, du SAST, des workflows et des SBOM avec un seul workflow réutilisable.
  • Les règles et les scanners sont publiés depuis un seul endroit, de sorte qu'un changement atteint tous les dépôts consommateurs.
  • Chaque résultat arrive dans DefectDojo, enrichi par 7 flux de threat intelligence dont CISA KEV, EPSS et ExploitDB, puis trié sur deux voies.
  • Le gate de fusion compare chaque pull request à la baseline et échoue en mode fermé quand le tracker ne répond pas.

SAST et Semgrep

107 règles personnalisées
  • Une bibliothèque de règles commune pour Go, Python, JavaScript et TypeScript, shell et workflows GitHub Actions.
  • Chaque règle est livrée avec des fixtures de ce qui doit se déclencher et de ce qui doit rester silencieux, et la CI les exécute : une règle bruyante ne peut pas être fusionnée.
  • Des packs du registre par-dessus, activés dépôt par dépôt, chaque exclusion étant justifiée dans la config.
  • Sur le projet Go open source : Semgrep, CodeQL, govulncheck, fuzzing et OpenSSF Scorecard en CI.

DAST et tests de sécurité

harness de 49 modules
  • Scans ZAP baseline et authentifiés, plus 15 templates Nuclei personnalisés pour SSRF, injection NoSQL, CORS, redirections OAuth et prototype pollution.
  • Un harness WebSocket maison de 49 modules qui découvre méthodes et publications depuis le code source et teste chaque rôle, couvrant 8 points de l'OWASP API Top 10.
  • DAST nocturne multi-rôles sur une plateforme de paiement : Schemathesis, ZAP, Nuclei, un harness d'IDOR inter-tenants et un manifeste d'accès par endpoint.

Tests d'intrusion

les constats deviennent des checks CI
  • J'ai commandé et piloté un test d'intrusion indépendant : 12 constats, dont les classes clés ont été transformées en checks de régression DAST et en assertions sur les règles de bordure.
  • Audit externe en black-box d'une plateforme de paiement : 24 constats, dont 14 prouvés par un exploit fonctionnel. J'ai livré les correctifs de bordure sous forme de règles WAF en code.
  • J'ai moi-même mené tests d'intrusion, exercices de red team et de blue team, et pas seulement commandé.

Durcissement CI/CD

pinned · signed · keyless
  • Actions tierces épinglées sur des SHA de commit, vérifié par zizmor ; la logique des workflows est analysée par poutine.
  • Images signées sans clé avec Cosign, SBOM et provenance SLSA attestés, signatures revérifiées avant le déploiement et à l'admission.
  • Déploiements via GitHub OIDC avec une confiance limitée à la branche et à l'environnement : aucune clé cloud de longue durée en CI.
  • L'egress réseau de la CI est enregistré par job, pour qu'un incident puisse être rejoué à partir de preuves.

Discutons d'un poste

Postes de Head of DevOps, SRE & Security. À distance, ou avec relocalisation lorsque le visa est sponsorisé.

creed.click · Page statique, sans traceur. Chaque chiffre provient d'une source publique ou du CV.