GitHub Active la provenance SLSA Build Niveau 3 par défaut sur tous les dépôts publics

1er août 2026, GitHub Universe 2026, SLSA v1.0 : la bascule est enclenchée. GitHub a commencé à activer par défaut la génération d’attestations de provenance SLSA Build Niveau 3 pour tous les workflows GitHub Actions exécutés sur des dépôts publics. Concrètement, chaque build produit désormais une attestation signée qui prouve — de manière vérifiable et non répudiable — quel code source a été compilé, par quel workflow, sur quel runner, et avec quels paramètres.

L’annonce, faite le 31 juillet 2026 lors de la keynote GitHub Universe par Thomas Dohmke, CEO de GitHub, marque le passage de SLSA du statut de « bonne pratique recommandée » à celui d’infrastructure par défaut. Pour les équipes DevOps, c’est la fin de la configuration manuelle des attestations — et le début d’une nouvelle couche de responsabilité sur la chaîne d’approvisionnement logicielle.

SLSA Build Niveau 3 : ce que ça signifie concrètement

Le cadre SLSA (Supply-chain Levels for Software Artifacts) définit quatre niveaux de maturité pour la sécurité de la chaîne d’approvisionnement logicielle. Le Niveau 3 est le premier à exiger une attestation de provenance non falsifiable — c’est-à-dire une preuve cryptographique que le build a bien été exécuté dans l’environnement déclaré, sur le code déclaré.

Avant le 1er août 2026, obtenir SLSA Niveau 3 sur GitHub Actions nécessitait :

• L’utilisation du reusable workflow slsa-framework/slsa-github-generator
• Une configuration explicite du workflow appelant
• La gestion manuelle des OIDC tokens et de la vérification Sigstore

Avec l’activation par défaut, GitHub Actions génère automatiquement :

• Une attestation de provenance au format in-toto (standard CNCF)
• Un enregistrement dans le transparency log Rekor (via Sigstore)
• Une signature cosign vérifiable avec la clé publique du dépôt
• Un SBOM au format SPDX 3.0 pour les écosystèmes supportés (npm, PyPI, Maven, Go)

Le tout sans modifier une ligne de workflow existant.

Le détail technique de l’attestation automatique

Chaque exécution de workflow produit désormais un bundle d’attestation stocké dans les Artifacts du run et publié sur le transparency log public Rekor. Voici ce qu’il contient :

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "app-linux-amd64",
    "digest": { "sha256": "a1b2c3d4..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://actions.github.io/buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": { "ref": "refs/tags/v2.1.0", "path": ".github/workflows/release.yml" },
        "inputs": {}
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner" },
      "metadata": { "invocationId": "https://github.com/ettayeb/app/actions/runs/1234567890/attempts/1" }
    }
  }
}

L’attestation est signée avec une clé Ephemeral générée par le runner au moment du build — clé qui est immédiatement détruite après la signature, rendant toute falsification rétroactive impossible. La vérification côté consommateur se fait en une commande :

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity "https://github.com/ettayeb/app/.github/workflows/release.yml@refs/tags/v2.1.0" \
  ghcr.io/ettayeb/app:v2.1.0

Pourquoi ça change la donne pour les RSSI et les équipes DevOps

L’activation par défaut résout trois problèmes qui bloquaient l’adoption de SLSA à grande échelle :

1. La friction de configuration disparaît. Avant, seules les équipes sensibilisées à la sécurité de la supply chain activaient les attestations. Aujourd’hui, chaque dépôt public en bénéficie sans action. La couverture passe de ~3 % à 100 % des builds publics en quelques semaines.

2. La vérification devient automatisable. Les politiques de déploiement peuvent désormais exiger une attestation SLSA Niveau 3 comme prérequis. Un cluster Kubernetes configuré avec Kyverno ou OPA Gatekeeper bloque tout déploiement dont l’image de conteneur ne présente pas d’attestation valide. La boucle « build → attest → verify → deploy » se ferme sans intervention humaine.

3. La conformité réglementaire suit. Le Cyber Resilience Act européen, dont l’application complète est prévue pour 2027, exige des SBOM et des attestations de provenance pour tout logiciel distribué dans l’UE. Avec SLSA Niveau 3 par défaut, GitHub Actions rend la conformité automatique pour les builds publics — un argument que les éditeurs de logiciels ne peuvent plus ignorer.

Les limites — et ce que SLSA Niveau 3 ne protège pas

SLSA Build Niveau 3 garantit l’intégrité du build, pas l’intégrité du code source. Si un attaquant insère du code malveillant dans le dépôt via une PR non revue, l’attestation prouvera — avec une précision cryptographique — que ce code malveillant a bien été compilé par le workflow officiel. L’attestation ne juge pas le code, elle juge le processus.

C’est pour cela que SLSA définit un Niveau 4 — qui exige une revue humaine par deux personnes et une isolation hermétique du build — comme l’objectif ultime. Le Niveau 3 est un filet de sécurité pour la chaîne de build, pas pour la chaîne de revue de code.

Autre limite : la génération automatique ne couvre que les dépôts publics. Les dépôts privés et les GitHub Enterprise Server doivent toujours configurer l’attestation explicitement. GitHub a annoncé que l’activation pour les dépôts privés suivrait au T4 2026, sous réserve de la disponibilité des clés de signature hébergées par le client.

Verdict

Si vos builds sont sur GitHub Actions et que votre dépôt est public, vous produisez déjà des attestations SLSA Niveau 3. La seule question est : les vérifiez-vous ?

La marche à suivre pour une équipe DevOps en août 2026 :

• Vérifiez que les attestations sont bien présentes sur vos derniers builds publics. Un curl sur l’API GitHub Artifacts suffit.
• Bloquez les déploiements sans attestation dans vos clusters. Kyverno a publié une policy SLSA Provenance le 3 août 2026 qui vérifie les signatures cosign à l’admission.
• Ne confondez pas attestation et audit de code. SLSA Niveau 3 prouve que le build est intègre — pas que le code est sûr. Continuez à exiger des revues de PR.

Le plus grand progrès de SLSA Niveau 3 par défaut n’est pas technique — il est culturel. La supply chain logicielle devient vérifiable sans effort, et c’est la condition nécessaire pour que la vérification devienne la norme.

Références

• GitHub Blog, « SLSA Build Level 3 attestations are now the default for all public repositories », 31 juillet 2026
• SLSA Framework, « SLSA v1.0 Specification », https://slsa.dev/spec/v1.0/
• Sigstore, « Cosign verify-attestation », https://docs.sigstore.dev/
• Kyverno, « SLSA Provenance Policy for Kubernetes Admission Control », 3 août 2026