~5 minutes
Maintenant que nous avons vu comment atteindre le niveau 3 de SLSA avec GitHub Actions, une question se pose : est-ce la seule manière de faire ? La réponse est non. Il existe tout un spectre de stratégies pour implémenter SLSA, chacune avec ses propres compromis entre simplicité, flexibilité et niveau de confiance. Analysons ensemble les options.
Après avoir mis en place mes premiers builds conformes SLSA 3, j’ai rapidement réalisé que les workflows réutilisables, bien que très pratiques, ne convenaient pas à tous les projets. Certains ont des processus de build plus complexes, d’autres ne sont pas sur GitHub Actions, ou nécessitaient une personnalisation que les “builders” officiels ne permettent pas.
Je me suis donc penché sur les différentes manières d’intégrer SLSA. Je les classe en trois grandes catégories, allant du plus simple et rigide au plus complexe et flexible.
Le spectre des stratégies d’implémentation SLSA
Il n’y a pas de “meilleure” solution universelle. Le bon choix dépend de la maturité de votre équipe, de la complexité de votre build et du niveau de contrôle que vous souhaitez avoir.
| Critère | 1. Workflows Réutilisables | 2. Générateurs Génériques | 3. Implémentation Manuelle (DIY) |
|---|---|---|---|
| Simplicité | Très Élevée | Moyenne | Très Faible |
| Flexibilité | Très Faible | Moyenne | Très Élevée |
| Maintenance | Très Faible | Faible | Très Élevée |
| Niveau de Confiance | Très Élevé | Élevé | Dépend de l'implémentation |
| Niveau SLSA Atteint | Garanti Niveau 3 | Jusqu'à Niveau 3 (si bien configuré) | Tous les niveaux (si bien fait) |
| Idéal pour... | Projets standards, démarrage rapide. | Builds avec étapes personnalisées, besoin de plus de contrôle. | Plateformes non-standard (Jenkins, etc.), exigences très spécifiques. |
Approche 1 : Les Workflows Réutilisables (“La voie royale”)
C’est l’approche que j’ai décrite dans mon guide pratique pour SLSA 3. Elle consiste à utiliser les workflows fournis et maintenus par le projet SLSA lui-même, comme slsa-framework/slsa-github-generator.
Comment ça marche ?
Votre fichier de workflow GitHub Actions se contente d’appeler le workflow réutilisable avec la directive uses:. Vous lui passez quelques paramètres (nom de l’image, version de Python, etc.), et il s’occupe de tout le reste.
# .github/workflows/build.yml
jobs:
build:
permissions:
id-token: write
contents: read
packages: write
uses: slsa-framework/slsa-github-generator/.github/workflows/container_slsa3.yml@v1.9.0
with:
image-name: my-app
registry: ghcr.io/my-org
Avantages :
- Simplicité extrême : Quelques lignes de YAML suffisent.
- Confiance maximale : Le “builder” est maintenu par les experts de l’OpenSSF. C’est la garantie la plus forte que le processus est sécurisé.
- Maintenance minimale : Il suffit de mettre à jour la version du workflow (
@v1.9.0) de temps en temps.
Inconvénients :
- Manque de flexibilité : Vous êtes contraint par le processus de build défini dans le workflow réutilisable. Si vous avez besoin d’étapes de tests complexes, de compilation multi-architecture non standard ou d’autres logiques personnalisées, cette approche ne fonctionnera pas.
- Dépendance à GitHub Actions : Cette approche est spécifique à GitHub Actions. Si vous utilisez Jenkins, GitLab CI ou une autre plateforme, vous ne pourrez pas utiliser ces workflows réutilisables.
Approche 2 : Les Générateurs Génériques (“Le juste milieu”)
Cette approche consiste à utiliser des actions GitHub (ou des outils similaires sur d’autres plateformes) qui ne s’occupent que de la partie “SLSA” : générer et signer la provenance. Vous gardez le contrôle total sur vos étapes de build.
Comment ça marche ?
Votre workflow contient vos propres étapes de build (run: make build, run: docker build, etc.). À la fin, vous appelez une action générique qui va inspecter les artefacts produits, générer l’attestation de provenance, la signer avec Sigstore via OIDC, et l’attacher à vos artefacts.
Un bon exemple est l’action slsa-framework/slsa-provenance-action.
# .github/workflows/custom-build.yml
jobs:
build:
permissions:
id-token: write
contents: read
packages: write
steps:
- uses: actions/checkout@v4
- name: Build my artifact
run: |
# Mes étapes de build complexes et personnalisées
make test
make build
# Le binaire est dans ./dist/my-app
- name: Generate SLSA Provenance
uses: slsa-framework/slsa-provenance-action@v1
with:
artifact-path: ./dist/my-app
# L'action s'occupe de la signature OIDC et de la publication
Avantages :
- Flexibilité : Vous contrôlez entièrement le processus de build.
- Bon équilibre : Vous n’avez pas à réimplémenter la logique complexe de signature et de génération de provenance.
Inconvénients :
- Confiance partagée : Le niveau de confiance est un peu moins élevé, car une partie du processus (le build) est sous votre contrôle. Une erreur dans vos scripts de build pourrait compromettre l’intégrité, même si la provenance est correctement signée.
- Configuration plus complexe : Il faut s’assurer que les artefacts sont correctement passés à l’action de génération de provenance.
- Dépendance à GitHub Actions : Comme pour les workflows réutilisables, cette approche est spécifique à GitHub Actions.
Approche 3 : L’implémentation Manuelle (“Do It Yourself”)
Ici, on prend le contrôle total. C’est à vous d’implémenter chaque étape du processus SLSA. C’est la seule option si vous n’êtes pas sur une plateforme supportée (comme GitHub Actions) ou si vous avez des exigences de sécurité qui vous interdisent d’utiliser des actions tierces.
Comment ça marche ? Votre script de CI/CD doit :
- Obtenir un token OIDC de votre plateforme (si elle le supporte).
- Utiliser des outils en ligne de commande comme
cosign(de Sigstore) pour interagir avec Fulcio (l’autorité de certification) et Rekor (le journal de transparence). - Construire manuellement l’attestation de provenance au format in-toto.
- Signer cette attestation avec la clé obtenue.
- Publier l’artefact et son attestation.
# Extrait d'un script de build manuel (simplifié)
# 1. Obtenir le token OIDC (spécifique à la plateforme)
export GITHUB_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_RUNTIME_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL" | jq -r .value)
# 2. Builder le package Python
python -m build
# 3. Générer la provenance (ici, manuellement)
ARTIFACT_HASH=$(sha256sum dist/*.whl | awk '{ print $1 }')
cat <<EOF > provenance.json
{ ... format in-toto ... }
EOF
# 4. Signer l'attestation avec cosign en mode keyless
cosign sign-blob --oidc-issuer https://token.actions.githubusercontent.com \
--output-signature attestation.sig \
--output-certificate attestation.pem \
provenance.json
Avantages :
- Flexibilité maximale : Fonctionne sur n’importe quelle plateforme (Jenkins, GitLab, CircleCI, etc.) et avec n’importe quel processus de build.
Inconvénients :
- Complexité extrême : Vous êtes responsable de tout. La moindre erreur dans la génération de la provenance ou dans le processus de signature peut invalider toutes vos garanties de sécurité.
- Maintenance très élevée : Vous devez suivre les évolutions des spécifications SLSA, in-toto et Sigstore et mettre à jour vos scripts en conséquence.
- Niveau de confiance auto-déclaré : Il est plus difficile de prouver à des tiers que votre processus est réellement sécurisé, car vous êtes à la fois le “builder” et le “vérificateur” de votre propre processus.
À retenir
