CI/CD sécurisée : définition et principes 2026

Une CI/CD sécurisée est une chaîne d'intégration et de déploiement continue dont chaque étape (source, build, test, deploy) intègre des contrôles de sécurité protégeant à la fois le code livré et le pipeline lui-même. Elle repose sur 7 piliers indissociables : identité forte via OIDC federation (plus de credentials long-lived), protection de branche et revue PR obligatoire, secrets management centralisé (Vault, AWS Secrets Manager), runners éphémères isolés, SAST/SCA/DAST/IaC scanning en pipeline avec seuils bloquants, signing et attestation Sigstore des artefacts, déploiement contrôlé via GitOps et policy as code. Les référentiels structurants 2026 sont SLSA v1.0 (Supply chain Levels for Software Artifacts, OpenSSF 2023), NIST SSDF SP 800-218 (Secure Software Development Framework), OWASP CI/CD Top 10 Security Risks (2022). La pression réglementaire UE est forte : Cyber Resilience Act applicable 2027, DORA applicable janvier 2025, NIS 2 transposition France octobre 2024 imposent traçabilité supply chain, SBOM et gestion vulnérabilités vérifiable. Les 3 menaces dominantes sur les pipelines sont Poisoned Pipeline Execution (PPE), Insufficient Credential Hygiene et Dependency Chain Abuse, qui concentrent plus de 70 % des incidents documentés 2020-2024 (SolarWinds, Codecov, xz-utils). Cet article détaille la définition précise, les menaces classées OWASP, les 7 piliers techniques, les frameworks SLSA et SSDF, un pipeline GitHub Actions de référence, et la checklist d'implémentation.

1. Définition et positionnement dans le SDLC

CI/CD sécurisée désigne une chaîne de livraison logicielle où la sécurité est intégrée à chaque étape, pas ajoutée en fin de cycle. Elle couvre deux dimensions orthogonales.

1.1 Sécurité du code livré (shift-left classique)

Intègre dans le pipeline les outils de détection de vulnérabilités appliqués au code sous build :

• SAST (cf. Qu'est-ce qu'un SAST) : scan du code source à chaque PR.
• SCA (Software Composition Analysis) : scan des dépendances tierces vs CVE.
• DAST (Dynamic Application Security Testing) : test d'application en exécution en staging.
• IaC scanning : Terraform, Kubernetes manifests, CloudFormation.
• Secrets scanning : gitleaks, TruffleHog en pre-commit et CI.
• Container scanning : Trivy, grype sur les images OCI.

1.2 Sécurité du pipeline lui-même (supply chain security)

Protège l'infrastructure de build et de déploiement contre les attaques supply chain :

• Identité et authentification forte : OIDC federation entre CI et cloud, MFA obligatoire sur comptes git.
• Protection du code source : branch protection rules, signed commits, PR review obligatoire.
• Isolation des runners : éphémères, sandbox, least privilege.
• Secrets management : secrets courts-lived, rotation automatique.
• Integrity et provenance : signing artefacts via Sigstore, SBOM, SLSA attestations.
• Déploiement contrôlé : GitOps, policy as code (OPA, Kyverno), approvals.

2. Pourquoi la CI/CD est devenue une cible prioritaire

Trois forces convergent en 2024-2026 pour faire du pipeline CI/CD la cible cyber numéro un.

2.1 Incidents supply chain récents et leur impact

• SolarWinds Orion (décembre 2020) : compromission du build system d'un éditeur, malware SUNBURST injecté dans des mises à jour signées, 18 000 organisations affectées dont agences fédérales US.
• Codecov Bash Uploader (avril 2021) : script Bash d'upload compromis pendant plusieurs mois, exfiltration de secrets CI de milliers de projets open source et privés.
• GitHub Actions Pwn Requests (documenté 2022+) : attaque via PR malveillante qui abuse pull_request_target pour obtenir les secrets du workflow.
• Dependency confusion (Alex Birsan, 2021) : publication de packages namés comme dépendances privées internes, compromission de 35+ grandes entreprises dont Apple et Microsoft.
• xz-utils CVE-2024-3094 (mars 2024) : backdoor introduite dans une dépendance Linux critique (liblzma) via social engineering d'un maintainer légitime, détectée in extremis avant release distribution.

2.2 Pression réglementaire UE et internationale

• Cyber Resilience Act (règlement UE 2024/2847) : applicable 2027 pour la plupart des provisions, obligations SBOM, gestion vulnérabilités sur durée de vie du produit, reporting 24-72 h des CVE activement exploitées.
• DORA (règlement UE 2022/2554) : applicable janvier 2025, gestion supply chain logicielle pour entités financières.
• NIS 2 (directive UE 2022/2555) : transposition France octobre 2024, mesures techniques supply chain pour EE et EI.
• US Executive Order 14028 (mai 2021) : impose SBOM et NIST SSDF aux fournisseurs fédéraux US.
• NIST SSDF SP 800-218 (février 2022, révision 2024) : Secure Software Development Framework, 4 groupes de pratiques (PO, PS, PW, RV).

2.3 Cible à fort effet de levier

Compromettre un pipeline CI/CD donne accès à tous les déploiements downstream : dizaines de microservices, milliers d'installations, écosystème de dépendants. Pour un attaquant, le ROI est bien supérieur à compromettre un poste utilisateur ou un serveur isolé.

3. Modèle de menace CI/CD : mapping OWASP Top 10 CI/CD Security Risks

L'OWASP CI/CD Top 10 Security Risks (2022, porté par Omer Gil et Daniel Krivelevich, toujours la référence 2026) structure les menaces en 10 catégories.

Les 3 risques concentrant plus de 70 % des incidents

1. CICD-SEC-4 PPE : l'attaque pull_request_target GitHub Actions est le pattern le plus documenté 2022-2024. Un attaquant crée une PR qui modifie un script de build ; le workflow pull_request_target s'exécute avec les secrets du repo et les permissions write.
2. CICD-SEC-6 Credential Hygiene : PAT avec repo:admin scope stocké dans un secret partagé, déployable clé AWS avec AdministratorAccess policy.
3. CICD-SEC-3 Dependency Chain Abuse : le vecteur xz-utils 2024, dépendance transitive profonde compromise.

4. Les 7 piliers d'une CI/CD sécurisée

Adressage technique des 10 risques OWASP CI/CD via 7 piliers opérationnels.

4.1 Identité forte et authentification

• MFA obligatoire sur tous les comptes qui peuvent push ou merge.
• SSO centralisé (Okta, Entra ID, Keycloak) pour le SCM et le CI.
• Abandonner les PAT (Personal Access Tokens) long-lived au profit d'OIDC federation : CI émet un token OIDC, cloud (AWS, Azure, GCP) valide et émet des credentials temporaires.
• Short-lived tokens : maximum 1 heure, révocation possible.

Exemple OIDC GitHub Actions → AWS (remplace totalement les AWS_ACCESS_KEY_ID long-lived)

name: deploy-to-aws
on:
  push:
    branches: [main]
 
permissions:
  id-token: write  # requis pour OIDC
  contents: read
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeployRole
          aws-region: eu-west-3
      - run: aws s3 sync ./build/ s3://my-prod-bucket/

La policy IAM côté AWS limite l'assume-role au repo et à la branche : token.actions.githubusercontent.com:sub = repo:org/repo:ref:refs/heads/main.

4.2 Protection de branche et revue PR

• Branch protection sur main : no force push, linear history, require PR.
• Required reviewers : minimum 1, idéalement 2 pour code critique.
• CODEOWNERS : revue obligatoire par équipe sectorielle (auth, finance, infra).
• Signed commits via GPG ou SSH key, vérifiés par GitHub/GitLab.
• Status checks obligatoires : SAST, SCA, tests, lint.

4.3 Secrets management centralisé

Quatre niveaux de maturité hiérarchisés :

Règles transverses

• Jamais de secrets committés : secrets scanning obligatoire (gitleaks pre-commit + CI).
• Rotation régulière : maximum 90 jours pour credentials long-lived restants.
• Least privilege : un secret par usage, scope minimal.
• Audit log : qui a lu quel secret, quand, pour quelle action.

4.4 Runners éphémères et isolés

Hosted runners par défaut (GitHub hosted, GitLab shared) : VM fraîche par job, détruite après.

Self-hosted runners si nécessaire (GPU, réseau privé, compliance) :

• Ephemeral runners : un job = un runner, destruction immédiate.
• Isolation réseau : VPC dédié, accès outbound restreint, pas d'accès au réseau d'entreprise général.
• Rotation des tokens d'enregistrement : expiration courte, rotation automatisée.
• Labels restrictifs : pas de runner partagé entre repos publics et privés.
• Patching : OS et runner agent à jour.

4.5 SAST, SCA, DAST, IaC dans le pipeline

Pipeline de référence avec seuils bloquants OWASP mappés.

• SAST : Semgrep avec p/owasp-top-ten + p/cwe-top-25 + règles custom, seuil bloquant sur CVSS ≥ 7.0.
• SCA : Trivy fs scan, seuil bloquant sur HIGH et CRITICAL en production.
• IaC : Checkov sur Terraform + Kubernetes manifests, seuil bloquant sur CIS High.
• Secrets : gitleaks historique complet + detect-secrets.
• Container : Trivy image scan, Cosign verify avant deploy.
• DAST : OWASP ZAP baseline ou full scan en nightly ou staging, non-bloquant mais reporté.

Voir Qu'est-ce qu'un SAST section 6 pour un pipeline GitHub Actions complet.

4.6 Signing et attestation des artefacts (Sigstore)

Sigstore (OpenSSF, CNCF incubating) est devenu le standard 2023-2026 pour la signature d'artefacts open source et enterprise.

Composants Sigstore

• Cosign : outil de signature d'artefacts (container images, blobs, SBOM).
• Fulcio : autorité de certification qui émet des certificats courts-lived (10 min) liés à une identité OIDC.
• Rekor : transparency log immuable qui enregistre chaque signature.

Flow typique en GitHub Actions

- name: Sign container image with cosign via OIDC
  env:
    COSIGN_EXPERIMENTAL: "true"  # keyless mode
  run: |
    cosign sign --yes \
      --identity-token ${{ secrets.GITHUB_TOKEN }} \
      ghcr.io/${{ github.repository }}:${{ github.sha }}
 
- name: Generate SBOM with syft
  run: |
    syft packages ghcr.io/${{ github.repository }}:${{ github.sha }} \
      -o cyclonedx-json=sbom.json
 
- name: Attach SBOM attestation
  run: |
    cosign attest --yes \
      --type cyclonedx \
      --predicate sbom.json \
      ghcr.io/${{ github.repository }}:${{ github.sha }}

Côté consumer (déploiement)

# Vérifier signature avant déploiement
cosign verify \
  --certificate-identity-regexp "^https://github.com/org/repo/" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/org/repo:v1.2.3

4.7 Déploiement contrôlé via GitOps et policy as code

• GitOps (ArgoCD, FluxCD) : state désiré en Git, réconciliation automatique, rollback natif.
• Policy as Code : Open Policy Agent (OPA) + Rego, Kyverno pour Kubernetes, Conftest pour Terraform.
• Admission controllers : rejettent les déploiements non conformes (image non signée, CVE critique, config manifestement risquée).
• Approvals gates : environnements protégés avec approbation manuelle pour production.

5. SLSA v1.0 : framework supply chain de référence

SLSA (Supply chain Levels for Software Artifacts), OpenSSF, version 1.0 publiée avril 2023, définit 4 niveaux de maturité pour la supply chain logicielle.

5.1 Qu'est-ce qu'une provenance SLSA ?

Une provenance attestation est un document signé qui décrit comment et par qui un artefact a été construit. Format standard : in-toto attestation en JSON.

Champs clés d'une provenance L2 :

• builder.id : identifiant du build system (ex https://github.com/actions/runner/github-hosted).
• buildType : URI désignant le type de build.
• invocation : paramètres du build (commit SHA, environnement, workflow YAML).
• metadata : timestamps, reproducible flag.
• materials : sources (repos, dépendances résolues).

5.2 Comment atteindre SLSA L2 en GitHub Actions

L'action officielle slsa-framework/slsa-github-generator permet d'atteindre L2 en 2-5 jours.

name: release-with-slsa
on:
  push:
    tags: ["v*"]
 
permissions:
  id-token: write
  contents: write
  actions: read
 
jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digest: $${{ steps.hash.outputs.digest }}
    steps:
      - uses: actions/checkout@v4
      - run: make build-release
      - id: hash
        run: |
          echo "digest=$(sha256sum dist/my-app-linux-amd64 | cut -d ' ' -f1)" \
            >> "$GITHUB_OUTPUT"
 
  provenance:
    needs: build
    permissions:
      id-token: write
      contents: write
      actions: read
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.0.0
    with:
      base64-subjects: $${{ needs.build.outputs.digest }}

5.3 Vérification côté consumer

# Vérifier provenance avec slsa-verifier
slsa-verifier verify-artifact my-app-linux-amd64 \
  --provenance-path my-app-linux-amd64.intoto.jsonl \
  --source-uri github.com/org/repo \
  --source-tag v1.2.3

6. Supply chain dépendances : gestion des risques 2026

6.1 Risques de la supply chain dépendances

• Typosquatting : packages nommés similairement à des libs légitimes (lodash-js vs lodash).
• Dependency confusion : publication publique d'un nom de package privé interne pour leurrer le resolver.
• Maintainer compromis : prise de contrôle de compte maintainer via social engineering ou phishing.
• Packages abandonnés : repris par un mauvais acteur qui publie une version avec backdoor.
• Vulnérabilités transitives profondes : xz-utils via liblzma via systemd.

6.2 Contre-mesures techniques

• Pinning par hash : package-lock.json avec integrity SHA-512, pnpm-lock.yaml, poetry.lock.
• Vendoring critique : pour dépendances sensibles, inclure le code dans le repo (déconseillé par défaut mais utile pour code critique).
• Dependabot ou Renovate : PR automatiques de mise à jour avec tests CI.
• SCA scanners : Trivy, Snyk, Dependabot alerts, OSV-scanner.
• OpenSSF Scorecard : évaluation automatisée de la posture sécurité d'un repo open source dépendant.
• Allowlist : pour contextes sensibles, restreindre les packages utilisables à une liste revue par AppSec.

6.3 SBOM : Software Bill of Materials

Document formalisé listant toutes les dépendances d'un artefact. Formats standards :

• CycloneDX (OWASP) : XML ou JSON, très riche, adoption dominante Europe.
• SPDX (Linux Foundation) : XML ou JSON, historique plus ancien, adoption US.

Outils de génération 2026 :

• Syft (Anchore) : le plus utilisé, multi-format, multi-langage.
• CycloneDX tools : génération native pour npm, pip, maven, gradle.
• Trivy : génère SBOM en complément du scan vulnerabilities.

Obligations réglementaires 2026 : SBOM requis par Cyber Resilience Act pour produits numériques UE, par US Executive Order 14028 pour fournisseurs fédéraux, recommandé par NIS 2.

7. Pipeline GitHub Actions sécurisé de référence

Exemple complet combinant les 7 piliers.

name: secure-cicd
on:
  push:
    branches: [main]
    tags: ["v*"]
  pull_request:
    branches: [main]
 
permissions:
  contents: read
  security-events: write
  id-token: write  # pour OIDC
 
concurrency:
  group: $${{ github.workflow }}-$${{ github.ref }}
  cancel-in-progress: true
 
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Secrets scan with gitleaks
        uses: gitleaks/gitleaks-action@v2
      - name: SAST with Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/cwe-top-25
            p/secrets
          generateSarif: "1"
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif
      - name: SCA with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: HIGH,CRITICAL
          exit-code: "1"
      - name: IaC with Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: infra/
          soft_fail: false
 
  build-and-sign:
    needs: security-scan
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v')
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: $${{ github.actor }}
          password: $${{ secrets.GITHUB_TOKEN }}
      - name: Build and push image
        uses: docker/build-push-action@v5
        id: build
        with:
          push: true
          tags: ghcr.io/$${{ github.repository }}:$${{ github.ref_name }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
      - name: Install cosign
        uses: sigstore/cosign-installer@v3
      - name: Sign image
        env:
          COSIGN_EXPERIMENTAL: "true"
        run: |
          cosign sign --yes \
            ghcr.io/$${{ github.repository }}@$${{ steps.build.outputs.digest }}
      - name: Generate SBOM with syft
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/$${{ github.repository }}@$${{ steps.build.outputs.digest }}
          format: cyclonedx-json
          output-file: sbom.json
      - name: Attest SBOM
        env:
          COSIGN_EXPERIMENTAL: "true"
        run: |
          cosign attest --yes --type cyclonedx --predicate sbom.json \
            ghcr.io/$${{ github.repository }}@$${{ steps.build.outputs.digest }}
 
  deploy:
    needs: build-and-sign
    runs-on: ubuntu-latest
    environment: production  # approvals gate
    steps:
      - uses: actions/checkout@v4
      - name: AWS OIDC configure
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/DeployProdRole
          aws-region: eu-west-3
      - name: Verify image signature before deploy
        run: |
          cosign verify \
            --certificate-identity-regexp "^https://github.com/org/repo/" \
            --certificate-oidc-issuer https://token.actions.githubusercontent.com \
            ghcr.io/org/repo:$${{ github.ref_name }}
      - name: Deploy to ECS
        run: |
          aws ecs update-service \
            --cluster prod-cluster \
            --service my-app \
            --force-new-deployment

Points clés de ce pipeline

• OIDC AWS au lieu de AWS_ACCESS_KEY_ID.
• Scan sécurité obligatoire avant build (fail fast).
• Tag-triggered build and sign (pas sur PR non merged).
• Signing keyless Sigstore via GitHub OIDC.
• SBOM CycloneDX généré et attesté.
• Verify signature avant déploiement.
• Environment protection avec approvals pour production.

8. Checklist OWASP CI/CD Top 10 mise en œuvre

Checklist actionnable structurée par catégorie OWASP.

checklist_cicd_secure = {
    # CICD-SEC-1 Flow Control
    "trigger_controls": "Workflow triggers minimum nécessaires",
    "branch_targeting": "Pas de self-hosted sur repo public, PR fork",
 
    # CICD-SEC-2 IAM
    "mfa_obligatoire": "MFA sur SCM et CI pour tous",
    "sso_centralise": "SSO SCM via IdP central",
    "pat_remplaces": "PAT remplacés par OIDC federation",
 
    # CICD-SEC-3 Dependency Chain
    "lockfiles_pines": "Lockfiles avec hashes intégrité",
    "dependabot_renovate": "Dependabot ou Renovate actif",
    "sca_bloquant": "SCA Trivy seuil HIGH CRITICAL bloquant",
 
    # CICD-SEC-4 PPE
    "pull_request_target_audit": "Audit des usages pull_request_target",
    "actions_pinnees_sha": "Actions tierces pinées par SHA",
 
    # CICD-SEC-5 PBAC
    "permissions_minimums": "permissions bloc minimum par job",
    "least_privilege_token": "GITHUB_TOKEN scope minimal",
 
    # CICD-SEC-6 Credential Hygiene
    "pas_secrets_logs": "Secrets masqués dans logs",
    "rotation_90j": "Rotation credentials long-lived tous 90 jours",
    "secrets_scanning_ci": "gitleaks ou équivalent en CI",
 
    # CICD-SEC-7 Configuration
    "jenkins_patche": "Jenkins ou equivalent version à jour",
    "github_apps_audit": "Audit annuel des GitHub Apps installées",
 
    # CICD-SEC-8 3rd Party
    "actions_allowlist": "Actions autorisées via policies",
    "github_apps_reviewed": "GitHub Apps revues avant install",
 
    # CICD-SEC-9 Artifact Integrity
    "cosign_signing": "Artefacts signés via Sigstore",
    "sbom_cyclonedx": "SBOM CycloneDX généré et attesté",
    "slsa_l2_minimum": "Provenance SLSA L2 minimum",
    "verify_before_deploy": "cosign verify avant déploiement",
 
    # CICD-SEC-10 Logging
    "audit_log_retention": "Audit log CI conservé 1 an minimum",
    "detection_anomalies": "Alerting sur triggers inhabituels",
}
 
# Viser 80+ % de checks validés pour CI/CD sécurisée mature 2026

9. Maturité et roadmap d'implémentation

Progression recommandée sur 12-24 mois pour une équipe partant d'une CI/CD classique.

Budget indicatif

• Phase 1-3 : outils open source principaux, investissement temps équipe 0,3-0,5 ETP DevSecOps.
• Phase 4-5 : 0,5-1 ETP DevSecOps dédié, outils premium optionnels (Snyk, Sysdig, Wiz) selon compliance.

Points clés à retenir

• CI/CD sécurisée = protection simultanée du code livré (SAST, SCA, DAST) et du pipeline lui-même (supply chain, runners, secrets).
• 7 piliers opérationnels : identité OIDC, branch protection, secrets management, runners éphémères, scanners sécu bloquants, signing Sigstore, déploiement contrôlé GitOps + policy as code.
• Référentiels 2026 : SLSA v1.0 (supply chain), NIST SSDF SP 800-218, OWASP CI/CD Top 10 Security Risks.
• 3 menaces dominantes (plus de 70 % des incidents 2020-2024) : Poisoned Pipeline Execution, Insufficient Credential Hygiene, Dependency Chain Abuse.
• Remplacer les credentials long-lived par OIDC federation : token éphémère 1 h, révocation immédiate, cible 2026.
• Signing Sigstore keyless via OIDC = standard 2026 pour intégrité artefacts, accessible à tous via GitHub Actions.
• SLSA L2 cible pragmatique 2026 via slsa-framework/slsa-github-generator, L3 pour éditeurs sous Cyber Resilience Act.
• SBOM CycloneDX obligatoire pour produits numériques UE dès 2027 via Cyber Resilience Act.
• Progression 12-24 mois de la CI/CD classique à la CI/CD sécurisée mature, ETP DevSecOps croissant 0,3 à 1.

Pour aller plus loin

• Devenir DevSecOps sans expérience — pillar DevSecOps avec contexte marché.
• Roadmap DevSecOps — skill tree 6 niveaux incluant supply chain.
• SAST vs DAST — comparaison approfondie des paradigmes de scan.
• Qu'est-ce qu'un SAST — focus outil SAST dans le pipeline.
• Pourquoi apprendre le secure coding — motivation humaine complémentaire aux contrôles pipeline.