Comprendre comment les pipelines CI\/CD sont attaqu\u00e9s ne repr\u00e9sente que la moiti\u00e9 du tableau. La mod\u00e9lisation des menaces et la taxonomie des attaques nous fournissent une carte du champ de bataille, mais sans patterns d\u00e9fensifs concrets et att\u00e9nuations techniques, ces connaissances restent th\u00e9oriques. Ce guide comble le foss\u00e9 entre la sensibilisation et l’action.<\/p>\n
L’objectif n’est pas de construire une forteresse imprenable \u2014 cela n’existe pas. Au lieu de cela, nous nous concentrons sur la r\u00e9duction de la surface d’attaque, la limitation du rayon d’impact lorsque quelque chose tourne mal, et la r\u00e9silience des pipelines pour une reprise rapide. Chaque contr\u00f4le d\u00e9crit ici correspond \u00e0 des patterns d’attaques r\u00e9els : pipelines empoisonn\u00e9s, vol d’identifiants, d\u00e9tournement de d\u00e9pendances et falsification d’artefacts.<\/p>\n
Nous parcourrons les d\u00e9fenses couche par couche \u2014 du code source jusqu’\u00e0 l’ex\u00e9cution \u2014 puis nous couvrirons les capacit\u00e9s de d\u00e9tection et de r\u00e9ponse aux incidents qui bouclent la boucle. Que vous s\u00e9curisiez GitHub Actions, GitLab CI, Jenkins ou toute autre plateforme CI\/CD, les principes restent les m\u00eames.<\/p>\n
Aucun contr\u00f4le de s\u00e9curit\u00e9 unique n’est suffisant pour prot\u00e9ger un pipeline CI\/CD. Les attaquants sont cr\u00e9atifs et trouveront la faille dans toute d\u00e9fense \u00e0 couche unique. La seule strat\u00e9gie viable est la d\u00e9fense en profondeur : des contr\u00f4les superpos\u00e9s \u00e0 chaque \u00e9tape du cycle de livraison logicielle.<\/p>\n
Le Top 10 OWASP des risques de s\u00e9curit\u00e9 CI\/CD<\/a> fournit un cadre structur\u00e9 pour comprendre ce qui peut mal tourner. Chaque risque \u2014 de CICD-SEC-1 (M\u00e9canismes de contr\u00f4le de flux insuffisants) \u00e0 CICD-SEC-10 (Journalisation et visibilit\u00e9 insuffisantes) \u2014 exige des att\u00e9nuations sp\u00e9cifiques. Les d\u00e9fenses de ce guide sont organis\u00e9es pour traiter ces risques de mani\u00e8re syst\u00e9matique.<\/p>\n Consid\u00e9rez le pipeline CI\/CD comme une cha\u00eene de fronti\u00e8res de confiance :<\/p>\n Chaque couche a des menaces distinctes et n\u00e9cessite des d\u00e9fenses distinctes. La compromission d’une couche ne devrait pas automatiquement se propager \u00e0 la suivante.<\/p>\n La couche source est l\u00e0 o\u00f9 la plupart des attaques CI\/CD commencent. Un attaquant capable de modifier le code, les d\u00e9finitions de pipeline ou les fichiers de configuration contr\u00f4le ce que le pipeline ex\u00e9cute. Les d\u00e9fenses de la couche source garantissent que seules les modifications autoris\u00e9es, r\u00e9vis\u00e9es et v\u00e9rifi\u00e9es entrent dans le pipeline.<\/p>\n La protection des branches est la premi\u00e8re ligne de d\u00e9fense. Au minimum, les branches main et release doivent imposer :<\/p>\n Tous les fichiers d’un d\u00e9p\u00f4t ne comportent pas le m\u00eame risque. Les d\u00e9finitions de pipeline, les templates d’infrastructure as code et les configurations de conteneurs sont des cibles \u00e0 haute valeur. Utilisez CODEOWNERS pour exiger la revue par des \u00e9quipes sp\u00e9cifiques pour les chemins sensibles :<\/p>\n La signature des commits fournit une preuve cryptographique de paternit\u00e9. Sans cela, un attaquant qui compromet le jeton d’acc\u00e8s d’un d\u00e9veloppeur peut pousser des commits qui semblent provenir de n’importe qui. Activez la v\u00e9rification de signature des commits sur les branches prot\u00e9g\u00e9es pour vous assurer que chaque commit est sign\u00e9 avec une cl\u00e9 GPG ou SSH v\u00e9rifi\u00e9e.<\/p>\n La revue de code est un contr\u00f4le humain, et elle a besoin de garde-fous :<\/p>\n Chaque \u00e9v\u00e9nement ne devrait pas d\u00e9clencher une ex\u00e9cution compl\u00e8te du pipeline, surtout une qui a acc\u00e8s aux secrets :<\/p>\n La couche build est l\u00e0 o\u00f9 le code devient ex\u00e9cutable. Une compromission ici signifie qu’un attaquant peut injecter une logique malveillante dans vos artefacts sans modifier le code source. Les d\u00e9fenses de la couche build se concentrent sur l’isolation, l’\u00e9ph\u00e9m\u00e9rit\u00e9 et le moindre privil\u00e8ge.<\/p>\n Les runners CI persistants accumulent un \u00e9tat : identifiants mis en cache, fichiers r\u00e9siduels des builds pr\u00e9c\u00e9dents, variables d’environnement qui fuient entre les jobs. Les runners \u00e9ph\u00e9m\u00e8res \u00e9liminent enti\u00e8rement cette classe de risque en provisionnant une VM ou un conteneur neuf pour chaque job et en le d\u00e9truisant imm\u00e9diatement apr\u00e8s.<\/p>\n M\u00eame avec des runners \u00e9ph\u00e9m\u00e8res, les builds qui partagent des caches ou des espaces de noms r\u00e9seau peuvent faire fuiter des informations entre les jobs. Assurez-vous :<\/p>\n Une \u00e9tape de build compromise avec un acc\u00e8s r\u00e9seau non restreint peut exfiltrer des secrets vers une infrastructure contr\u00f4l\u00e9e par l’attaquant. Restreignez l’acc\u00e8s r\u00e9seau sortant :<\/p>\n Chaque outil install\u00e9 dans une image de build est une surface d’attaque potentielle. R\u00e9duisez les images de build au strict minimum :<\/p>\n La journalisation de debug et la sortie verbeuse sont inestimables pendant le d\u00e9veloppement mais dangereuses dans les pipelines de production. Elles peuvent faire fuiter des secrets, des chemins internes et des d\u00e9tails d’infrastructure. Assurez-vous que Les identifiants sont la cible la plus pr\u00e9cieuse dans tout pipeline CI\/CD. Un attaquant qui obtient une cl\u00e9 d’acc\u00e8s cloud, un token de d\u00e9ploiement ou un secret d’API peut pivoter bien au-del\u00e0 du pipeline lui-m\u00eame. Les d\u00e9fenses des identifiants se concentrent sur la minimisation de ce qui existe, de ce qui peut \u00eatre acc\u00e9d\u00e9 et de la dur\u00e9e d’acc\u00e8s.<\/p>\n Le Les secrets \u00e0 longue dur\u00e9e de vie stock\u00e9s dans les syst\u00e8mes CI\/CD sont des bombes \u00e0 retardement. Remplacez-les par la f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail bas\u00e9e sur OIDC partout o\u00f9 c’est possible :<\/p>\n Avec OIDC, la plateforme CI\/CD \u00e9met un JWT \u00e0 courte dur\u00e9e de vie, et le fournisseur cloud l’\u00e9change contre des identifiants temporaires. Aucun secret statique n’est stock\u00e9 nulle part.<\/p>\n Un seul jeu d’identifiants partag\u00e9 entre tous les environnements repr\u00e9sente un rayon d’impact catastrophique. Segmentez les identifiants :<\/p>\n Les pull requests provenant de forks ne devraient jamais avoir acc\u00e8s aux secrets du d\u00e9p\u00f4t. C’est une mauvaise configuration courante qui permet aux attaquants d’exfiltrer des secrets en soumettant une PR malveillante. Dans GitHub Actions, utilisez Pour les identifiants qui ne peuvent pas utiliser OIDC (mots de passe de base de donn\u00e9es, cl\u00e9s API pour des services tiers), utilisez un gestionnaire de secrets comme HashiCorp Vault avec des secrets dynamiques \u00e0 courte dur\u00e9e de vie :<\/p>\n Les secrets dynamiques sont g\u00e9n\u00e9r\u00e9s \u00e0 la demande, limit\u00e9s \u00e0 l’identit\u00e9 demandeuse et automatiquement r\u00e9voqu\u00e9s \u00e0 leur expiration. M\u00eame en cas de fuite, la fen\u00eatre d’exposition se mesure en minutes, pas en mois.<\/p>\n Chaque r\u00e9cup\u00e9ration de secret devrait g\u00e9n\u00e9rer une entr\u00e9e de journal d’audit. Si votre gestionnaire de secrets ne journalise pas les acc\u00e8s, vous n’avez aucun moyen d’investiguer une compromission. Assurez-vous que les journaux capturent : qui a acc\u00e9d\u00e9 \u00e0 quoi, quand, depuis quelle ex\u00e9cution de pipeline et depuis quelle adresse IP.<\/p>\n Les artefacts de build \u2014 images de conteneurs, binaires, paquets \u2014 sont le pont entre votre pipeline et la production. Si un attaquant peut falsifier les artefacts apr\u00e8s leur construction, toutes les d\u00e9fenses en amont deviennent sans objet. Les d\u00e9fenses de la couche artefact garantissent l’int\u00e9grit\u00e9, la provenance et l’immuabilit\u00e9.<\/p>\n La signature d’artefacts fournit une preuve cryptographique qu’un artefact a \u00e9t\u00e9 produit par votre pipeline et n’a pas \u00e9t\u00e9 modifi\u00e9 depuis. Cosign de Sigstore rend la signature sans cl\u00e9 pratique :<\/p>\n Avec la signature sans cl\u00e9, la cl\u00e9 de signature est \u00e9ph\u00e9m\u00e8re et li\u00e9e \u00e0 l’identit\u00e9 OIDC du workflow CI\/CD. Il n’y a pas de cl\u00e9 de signature \u00e0 longue dur\u00e9e de vie \u00e0 voler.<\/p>\n La provenance SLSA (Supply-chain Levels for Software Artifacts) enregistre comment, o\u00f9 et par qui un artefact a \u00e9t\u00e9 construit. Au niveau SLSA 3, la provenance est g\u00e9n\u00e9r\u00e9e par la plateforme de build elle-m\u00eame et ne peut pas \u00eatre falsifi\u00e9e par le processus de build :<\/p>\n Les artefacts publi\u00e9s ne devraient jamais \u00eatre \u00e9cras\u00e9s. Si un attaquant peut remplacer une version publi\u00e9e, il peut injecter du code malveillant dans chaque d\u00e9ploiement qui r\u00e9f\u00e9rence cette version. Configurez vos registres pour l’immuabilit\u00e9 :<\/p>\n Un Software Bill of Materials (SBOM) liste chaque composant de votre artefact. G\u00e9n\u00e9rer un SBOM au moment du build et l’attester aux c\u00f4t\u00e9s de l’artefact cr\u00e9e un inventaire v\u00e9rifiable pour la gestion des vuln\u00e9rabilit\u00e9s :<\/p>\n Signer les artefacts n’est utile que si vous v\u00e9rifiez les signatures avant le d\u00e9ploiement. Utilisez les contr\u00f4leurs d’admission Kubernetes pour imposer cela automatiquement :<\/p>\n Avec cette politique en place, toute image de conteneur d\u00e9pourvue d’une signature Cosign valide provenant de vos workflows GitHub Actions sera rejet\u00e9e au moment de l’admission \u2014 avant m\u00eame de s’ex\u00e9cuter dans votre cluster.<\/p>\n La couche de d\u00e9ploiement est la derni\u00e8re porte avant que les modifications n’atteignent la production. Les d\u00e9fenses ici garantissent que seuls les artefacts v\u00e9rifi\u00e9s et approuv\u00e9s sont d\u00e9ploy\u00e9s, et que le processus de d\u00e9ploiement lui-m\u00eame est contr\u00f4l\u00e9 et auditable.<\/p>\n Pour les d\u00e9ploiements en production, les pipelines automatis\u00e9s doivent se mettre en pause et exiger une approbation humaine explicite. Cela fournit un point de contr\u00f4le final o\u00f9 un humain peut v\u00e9rifier que la modification est attendue, test\u00e9e et autoris\u00e9e.<\/p>\n Dans les param\u00e8tres du d\u00e9p\u00f4t GitHub, configurez l’environnement \u00ab production \u00bb pour exiger l’approbation de r\u00e9viseurs d\u00e9sign\u00e9s avant que le job ne se poursuive.<\/p>\n Les pipelines CI\/CD traditionnels poussent vers la production : le pipeline a des identifiants pour modifier l’infrastructure de production. Le GitOps avec d\u00e9ploiement en mode pull inverse le mod\u00e8le :<\/p>\n M\u00eame avec toutes les d\u00e9fenses en amont, un d\u00e9ploiement peut introduire des probl\u00e8mes. Les d\u00e9ploiements canary limitent l’exposition en d\u00e9ployant d’abord les modifications sur un petit pourcentage du trafic. Si les m\u00e9triques se d\u00e9gradent, le rollback automatis\u00e9 annule la modification avant qu’elle n’affecte tous les utilisateurs.<\/p>\n Pendant les incidents actifs, les fen\u00eatres de maintenance ou les p\u00e9riodes de fort trafic, les d\u00e9ploiements doivent \u00eatre gel\u00e9s. Impl\u00e9mentez des politiques de gel de d\u00e9ploiement qui emp\u00eachent les d\u00e9ploiements initi\u00e9s par le pipeline pendant des fen\u00eatres sp\u00e9cifi\u00e9es, et assurez-vous que seuls les commandants d’incident d\u00e9sign\u00e9s peuvent outrepasser le gel.<\/p>\n La pr\u00e9vention finira par \u00e9chouer. Les capacit\u00e9s de d\u00e9tection d\u00e9terminent si vous attrapez une compromission en minutes ou en mois. La surveillance CI\/CD est un angle mort pour de nombreuses organisations \u2014 leur SIEM ing\u00e8re les journaux d’application et d’infrastructure mais ignore compl\u00e8tement la t\u00e9l\u00e9m\u00e9trie des pipelines.<\/p>\n \u00c9tablissez des r\u00e9f\u00e9rences pour le comportement normal du pipeline et alertez sur les d\u00e9viations :<\/p>\n Les nouvelles d\u00e9pendances ajout\u00e9es dans les PR devraient d\u00e9clencher une revue automatis\u00e9e et des alertes. Un outil de diff de d\u00e9pendances peut :<\/p>\n Les secrets fuient \u00e0 travers les commits, les journaux et les artefacts. Superposez plusieurs approches de scanning :<\/p>\n Les d\u00e9finitions de pipeline devraient changer via le processus normal de PR. Surveillez les modifications inattendues :<\/p>\n Transmettez les journaux d’audit CI\/CD \u00e0 votre SIEM aux c\u00f4t\u00e9s des journaux d’application et d’infrastructure. Les sources de journaux cl\u00e9s incluent :<\/p>\n Corr\u00e9lez l’activit\u00e9 du pipeline avec les modifications d’infrastructure cloud. Si une ex\u00e9cution de pipeline co\u00efncide avec des modifications de politique IAM inattendues ou la cr\u00e9ation de ressources, c’est une alerte de haute priorit\u00e9.<\/p>\n Lorsqu’une compromission CI\/CD est d\u00e9tect\u00e9e \u2014 ou suspect\u00e9e \u2014 la rapidit\u00e9 est essentielle. L’attaquant peut encore avoir un acc\u00e8s actif, et chaque minute de retard \u00e9largit le rayon d’impact. Un playbook de r\u00e9ponse aux incidents pr\u00e9par\u00e9 pour les sc\u00e9narios sp\u00e9cifiques au CI\/CD est indispensable.<\/p>\n D\u00e9terminez ce que l’attaquant aurait pu acc\u00e9der :<\/p>\n V\u00e9rifiez si les artefacts publi\u00e9s ont \u00e9t\u00e9 falsifi\u00e9s :<\/p>\n Rassemblez les preuves provenant de multiples sources :<\/p>\n Apr\u00e8s le confinement et l’investigation, restaurez les op\u00e9rations s\u00e9curis\u00e9es :<\/p>\n La s\u00e9curit\u00e9 CI\/CD n’est pas une checklist que l’on compl\u00e8te une fois pour l’oublier. C’est une pratique d’ing\u00e9nierie continue qui \u00e9volue avec vos pipelines, votre infrastructure et le paysage des menaces. Les attaquants continueront de cibler la supply chain logicielle parce qu’elle offre un levier \u00e9lev\u00e9 \u2014 un seul pipeline compromis peut affecter chaque d\u00e9ploiement, chaque environnement et chaque client.<\/p>\n Les d\u00e9fenses de ce guide sont organis\u00e9es par couche, mais les points de d\u00e9part les plus impactants traversent les couches :<\/p>\n Commencez par ces contr\u00f4les \u00e0 fort impact. Ajoutez des d\u00e9fenses suppl\u00e9mentaires \u00e0 mesure que votre programme de s\u00e9curit\u00e9 m\u00fbrit. Et supposez toujours que votre pipeline sera cibl\u00e9 \u2014 car il le sera.<\/p>\n Dans le prochain article de cette s\u00e9rie, nous parcourrons l’impl\u00e9mentation de ces d\u00e9fenses dans un pipeline GitHub Actions r\u00e9el, avec un exemple fonctionnel complet que vous pourrez adapter pour vos propres d\u00e9p\u00f4ts.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction Comprendre comment les pipelines CI\/CD sont attaqu\u00e9s ne repr\u00e9sente que la moiti\u00e9 du tableau. La mod\u00e9lisation des menaces et la taxonomie des attaques nous fournissent une carte du champ de bataille, mais sans patterns d\u00e9fensifs concrets et att\u00e9nuations techniques, ces connaissances restent th\u00e9oriques. Ce guide comble le foss\u00e9 entre la sensibilisation et l’action. L’objectif … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,54],"tags":[],"post_folder":[],"class_list":["post-505","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-threats-attacks"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/505","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=505"}],"version-history":[{"count":1,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/505\/revisions"}],"predecessor-version":[{"id":511,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/505\/revisions\/511"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=505"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=505"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=505"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=505"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Les trois piliers : Pr\u00e9vention, D\u00e9tection, R\u00e9ponse<\/h3>\n
\n
D\u00e9fense \u00e0 chaque couche<\/h3>\n
\n
D\u00e9fenses de la couche Source \u2014 Protection des entr\u00e9es du pipeline<\/h2>\n
R\u00e8gles de protection des branches<\/h3>\n
\n
CODEOWNERS pour les chemins sensibles<\/h3>\n
# .github\/CODEOWNERS\n\n# Les d\u00e9finitions de pipeline n\u00e9cessitent la revue de l'\u00e9quipe s\u00e9curit\u00e9\n.github\/workflows\/ @org\/security-team\n.gitlab-ci.yml @org\/security-team\nJenkinsfile @org\/security-team\n\n# Infrastructure as code\nterraform\/ @org\/platform-team @org\/security-team\npulumi\/ @org\/platform-team @org\/security-team\n\n# D\u00e9finitions de conteneurs\nDockerfile* @org\/security-team\ndocker-compose*.yml @org\/security-team\n\n# Manifestes de d\u00e9pendances\npackage.json @org\/security-team\nrequirements.txt @org\/security-team\ngo.sum @org\/security-team<\/code><\/pre>\nCommits sign\u00e9s et v\u00e9rification<\/h3>\n
# Configurer Git pour signer les commits avec une cl\u00e9 SSH\ngit config --global gpg.format ssh\ngit config --global user.signingkey ~\/.ssh\/id_ed25519.pub\ngit config --global commit.gpgsign true\n\n# V\u00e9rifier la signature d'un commit\ngit verify-commit HEAD<\/code><\/pre>\nPolitiques de revue des PR<\/h3>\n
\n
Limitation des d\u00e9clencheurs de pipeline<\/h3>\n
\n
D\u00e9fenses de la couche Build \u2014 S\u00e9curiser le processus de build<\/h2>\n
Runners \u00e9ph\u00e9m\u00e8res<\/h3>\n
# GitHub Actions : Runner \u00e9ph\u00e9m\u00e8re auto-h\u00e9berg\u00e9 avec actions-runner-controller\napiVersion: actions.summerwind.dev\/v1alpha1\nkind: RunnerDeployment\nmetadata:\n name: ephemeral-runners\nspec:\n replicas: 5\n template:\n spec:\n ephemeral: true\n repository: your-org\/your-repo\n labels:\n - self-hosted\n - ephemeral\n - linux\n dockerdWithinRunnerContainer: false\n image: ghcr.io\/actions\/actions-runner:latest\n resources:\n limits:\n cpu: \"2\"\n memory: \"4Gi\"<\/code><\/pre>\nEnvironnements de build isol\u00e9s<\/h3>\n
\n
Restrictions r\u00e9seau pendant les builds<\/h3>\n
\n
# Kubernetes NetworkPolicy pour les pods de runners CI\napiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n name: ci-runner-egress-restricted\n namespace: ci-runners\nspec:\n podSelector:\n matchLabels:\n role: ci-runner\n policyTypes:\n - Egress\n egress:\n - to:\n - ipBlock:\n cidr: 10.0.0.0\/8 # R\u00e9seau interne uniquement\n ports:\n - protocol: TCP\n port: 443 # HTTPS vers les registres internes\n - protocol: TCP\n port: 53 # DNS\n - protocol: UDP\n port: 53 # DNS<\/code><\/pre>\nImages de build minimales<\/h3>\n
\n
# \u00c9pingler par digest, pas par tag\nFROM golang:1.22@sha256:a3b21c5d8e... AS builder\nWORKDIR \/app\nCOPY . .\nRUN CGO_ENABLED=0 go build -o \/app\/binary\n\n# Utiliser distroless pour l'image finale\nFROM gcr.io\/distroless\/static-debian12@sha256:f4e8b1c2d9...\nCOPY --from=builder \/app\/binary \/binary\nENTRYPOINT [\"\/binary\"]<\/code><\/pre>\nD\u00e9sactiver les modes debug dans les pipelines de production<\/h3>\n
ACTIONS_STEP_DEBUG<\/code>, CI_DEBUG_TRACE<\/code> et les flags \u00e9quivalents sont d\u00e9sactiv\u00e9s dans les configurations de pipeline de production.<\/p>\nD\u00e9fenses des identifiants et de l’identit\u00e9 \u2014 Limiter ce que les pipelines peuvent acc\u00e9der<\/h2>\n
Permissions minimales des tokens<\/h3>\n
GITHUB_TOKEN<\/code> par d\u00e9faut dans GitHub Actions a des permissions larges. Restreignez-le toujours au minimum requis :<\/p>\n# GitHub Actions : Restreindre les permissions du token par d\u00e9faut\npermissions:\n contents: read\n packages: read\n id-token: write # Uniquement si vous utilisez OIDC\n\njobs:\n build:\n runs-on: ubuntu-latest\n permissions:\n contents: read\n steps:\n - uses: actions\/checkout@v4\n - run: make build\n\n deploy:\n runs-on: ubuntu-latest\n needs: build\n permissions:\n contents: read\n id-token: write # Pour l'authentification OIDC\n steps:\n - name: S'authentifier aupr\u00e8s du cloud\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/deploy-role\n aws-region: us-east-1<\/code><\/pre>\nOIDC et Workload Identity<\/h3>\n
\n
aws-actions\/configure-aws-credentials<\/code> avec l’assumption de r\u00f4le OIDC.<\/li>\ngoogle-github-actions\/auth<\/code> avec Workload Identity Federation.<\/li>\nazure\/login<\/code> avec les identifiants f\u00e9d\u00e9r\u00e9s.<\/li>\nCI_JOB_JWT_V2<\/code>) avec la f\u00e9d\u00e9ration du fournisseur cloud.<\/li>\n<\/ul>\nIdentifiants par environnement, par \u00e9tape<\/h3>\n
\n
Pas de secrets dans les workflows PR\/Fork<\/h3>\n
pull_request<\/code> (pas pull_request_target<\/code>) pour le code non fiable, et ne passez jamais de secrets aux \u00e9tapes qui ex\u00e9cutent du code de PR.<\/p>\nInt\u00e9gration Vault avec secrets dynamiques<\/h3>\n
# HashiCorp Vault : G\u00e9n\u00e9rer des identifiants de base de donn\u00e9es \u00e0 courte dur\u00e9e de vie\nvault read database\/creds\/ci-readonly\n# Retourne :\n# Key Value\n# --- -----\n# lease_id database\/creds\/ci-readonly\/abc123\n# lease_duration 1h\n# username v-ci-readonly-xyz789\n# password A1B2-C3D4-E5F6-G7H8<\/code><\/pre>\nJournalisation d’audit de tous les acc\u00e8s aux secrets<\/h3>\n
D\u00e9fenses de la couche Artefact \u2014 Assurer l’int\u00e9grit\u00e9 des r\u00e9sultats<\/h2>\n
Signer tous les artefacts avec Sigstore\/Cosign<\/h3>\n
# Signer une image de conteneur avec Cosign (sans cl\u00e9, bas\u00e9 sur OIDC)\ncosign sign --yes ghcr.io\/your-org\/your-app:v1.2.3@sha256:abc123...\n\n# V\u00e9rifier la signature\ncosign verify \\\n --certificate-identity=https:\/\/github.com\/your-org\/your-app\/.github\/workflows\/build.yml@refs\/heads\/main \\\n --certificate-oidc-issuer=https:\/\/token.actions.githubusercontent.com \\\n ghcr.io\/your-org\/your-app:v1.2.3@sha256:abc123...<\/code><\/pre>\nG\u00e9n\u00e9rer et stocker la provenance SLSA<\/h3>\n
# GitHub Actions : G\u00e9n\u00e9rer la provenance SLSA pour les images de conteneurs\n- uses: slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_container_slsa3.yml@v2.0.0\n with:\n image: ghcr.io\/your-org\/your-app\n digest: ${{ steps.build.outputs.digest }}\n secrets:\n registry-username: ${{ github.actor }}\n registry-password: ${{ secrets.GITHUB_TOKEN }}<\/code><\/pre>\nStockage d’artefacts immuable<\/h3>\n
\n
G\u00e9n\u00e9ration et attestation de SBOM<\/h3>\n
# G\u00e9n\u00e9rer un SBOM avec Syft et attester avec Cosign\nsyft ghcr.io\/your-org\/your-app:v1.2.3 -o spdx-json > sbom.spdx.json\ncosign attest --predicate sbom.spdx.json --type spdxjson \\\n ghcr.io\/your-org\/your-app:v1.2.3@sha256:abc123...<\/code><\/pre>\nContr\u00f4leurs d’admission pour la v\u00e9rification de signature<\/h3>\n
# Kyverno : Exiger des images sign\u00e9es\napiVersion: kyverno.io\/v1\nkind: ClusterPolicy\nmetadata:\n name: require-signed-images\nspec:\n validationFailureAction: Enforce\n background: false\n rules:\n - name: verify-cosign-signature\n match:\n any:\n - resources:\n kinds:\n - Pod\n verifyImages:\n - imageReferences:\n - \"ghcr.io\/your-org\/*\"\n attestors:\n - entries:\n - keyless:\n issuer: \"https:\/\/token.actions.githubusercontent.com\"\n subject: \"https:\/\/github.com\/your-org\/*\"<\/code><\/pre>\nD\u00e9fenses de la couche D\u00e9ploiement \u2014 Contr\u00f4ler ce qui atteint la production<\/h2>\n
Approbations manuelles requises<\/h3>\n
# GitHub Actions : Environnement avec r\u00e9viseurs requis\njobs:\n deploy-production:\n runs-on: ubuntu-latest\n environment:\n name: production\n url: https:\/\/your-app.example.com\n steps:\n - name: D\u00e9ployer en production\n run: .\/deploy.sh production<\/code><\/pre>\nGitOps avec d\u00e9ploiement en mode pull<\/h3>\n
\n
# Flux : GitRepository et Kustomization pour le d\u00e9ploiement en mode pull\napiVersion: source.toolkit.fluxcd.io\/v1\nkind: GitRepository\nmetadata:\n name: app-manifests\n namespace: flux-system\nspec:\n interval: 1m\n url: https:\/\/github.com\/your-org\/app-manifests\n ref:\n branch: main\n secretRef:\n name: git-credentials\n---\napiVersion: kustomize.toolkit.fluxcd.io\/v1\nkind: Kustomization\nmetadata:\n name: app-production\n namespace: flux-system\nspec:\n interval: 5m\n path: .\/environments\/production\n prune: true\n sourceRef:\n kind: GitRepository\n name: app-manifests\n healthChecks:\n - apiVersion: apps\/v1\n kind: Deployment\n name: your-app\n namespace: production<\/code><\/pre>\nD\u00e9ploiements canary et rollback automatis\u00e9<\/h3>\n
\n
Gels de d\u00e9ploiement<\/h3>\n
D\u00e9tection et surveillance \u2014 Savoir quand quelque chose ne va pas<\/h2>\n
D\u00e9tection d’anomalies d’ex\u00e9cution de pipeline<\/h3>\n
\n
Alertes sur les diff\u00e9rences de d\u00e9pendances<\/h3>\n
\n
Scanning de secrets<\/h3>\n
\n
gitleaks<\/code> ou trufflehog<\/code> attrapent les secrets avant qu’ils n’entrent dans le d\u00e9p\u00f4t.<\/li>\n# Hook pre-commit avec gitleaks\n# .pre-commit-config.yaml\nrepos:\n - repo: https:\/\/github.com\/gitleaks\/gitleaks\n rev: v8.18.0\n hooks:\n - id: gitleaks<\/code><\/pre>\nSurveillance de la d\u00e9rive de configuration<\/h3>\n
\n
Int\u00e9gration SIEM pour les journaux d’audit CI\/CD<\/h3>\n
\n
R\u00e9ponse aux incidents pour le CI\/CD \u2014 Quand les d\u00e9fenses \u00e9chouent<\/h2>\n
Actions imm\u00e9diates : Contenir la compromission<\/h3>\n
\n
Analyse du rayon d’impact<\/h3>\n
\n
V\u00e9rification de l’int\u00e9grit\u00e9 des artefacts<\/h3>\n
\n
Investigation forensique<\/h3>\n
\n
Reprise apr\u00e8s incident<\/h3>\n
\n
Mod\u00e8le de playbook de r\u00e9ponse aux incidents CI\/CD<\/h3>\n
## Playbook d'incident de s\u00e9curit\u00e9 CI\/CD\n\n### Phase 1 : D\u00e9tection et triage (0-15 minutes)\n- [ ] Confirmer que l'alerte est un vrai positif\n- [ ] Classifier la s\u00e9v\u00e9rit\u00e9 (P1 : compromission active, P2 : compromission suspect\u00e9e, P3 : violation de politique)\n- [ ] Notifier le commandant d'incident et l'\u00e9quipe s\u00e9curit\u00e9\n\n### Phase 2 : Confinement (15-60 minutes)\n- [ ] R\u00e9voquer les identifiants compromis\n- [ ] D\u00e9sactiver les pipelines affect\u00e9s\n- [ ] Isoler les runners affect\u00e9s\n- [ ] Bloquer l'acc\u00e8s de l'attaquant (r\u00e9voquer les tokens, d\u00e9sactiver les comptes)\n\n### Phase 3 : Investigation (1-24 heures)\n- [ ] Collecter les journaux des runners, les journaux d'audit, l'historique git\n- [ ] D\u00e9terminer le rayon d'impact (identifiants, artefacts, d\u00e9ploiements)\n- [ ] Identifier le vecteur d'attaque (comment l'attaquant est-il entr\u00e9 ?)\n- [ ] V\u00e9rifier l'int\u00e9grit\u00e9 des artefacts pour la p\u00e9riode compromise\n\n### Phase 4 : Reprise (24-72 heures)\n- [ ] Faire tourner tous les secrets potentiellement compromis\n- [ ] Reconstruire et republier les artefacts affect\u00e9s \u00e0 partir de sources connues comme fiables\n- [ ] Red\u00e9ployer les environnements affect\u00e9s \u00e0 partir d'artefacts v\u00e9rifi\u00e9s\n- [ ] Restaurer les op\u00e9rations de pipeline avec des contr\u00f4les renforc\u00e9s\n\n### Phase 5 : Post-incident (1-2 semaines)\n- [ ] Mener un post-mortem sans bl\u00e2me\n- [ ] Documenter les le\u00e7ons apprises et mettre \u00e0 jour ce playbook\n- [ ] Impl\u00e9menter les am\u00e9liorations syst\u00e9miques pour pr\u00e9venir la r\u00e9currence\n- [ ] Mettre \u00e0 jour les r\u00e8gles de d\u00e9tection en fonction des IOC d\u00e9couverts<\/code><\/pre>\nConclusion<\/h2>\n
\n