Introduction
La sécurité de la supply chain logicielle est devenue critique en 2026, après des incidents majeurs comme Log4Shell ou les attaques sur SolarWinds. Elle vise à protéger l'ensemble du cycle de vie des logiciels, des dépendances open-source aux artefacts déployés. Une brèche dans la supply chain peut compromettre des millions d'utilisateurs, avec des coûts estimés à des milliards.
Ce tutoriel advanced vous guide pas à pas pour implémenter une défense en profondeur : scans statiques et dynamiques des vulnérabilités (SCA/SBOM), signatures cryptographiques des conteneurs (Cosign/Sigstore), frameworks SLSA pour l'intégrité des pipelines, et monitoring continu avec Dependency-Track. Nous utilisons des outils open-source matures comme Trivy, Cosign et GitHub Actions.
À la fin, vous disposerez d'un pipeline CI/CD attestant SLSA Level 2, protégeant contre les injections malveillantes et les compromissions upstream. Idéal pour les équipes DevSecOps cherchant une implémentation production-ready (128 mots).
Prérequis
- Docker et Docker Compose installés (version 27+).
- Compte GitHub avec repository privé.
- Outil Cosign installé via
brew install cosign(macOS) ou équivalent. - Node.js 20+ et npm/yarn pour un projet exemple.
- Accès à un registry conteneurs (Docker Hub ou GHCR).
- Connaissances avancées en CI/CD et cryptographie.
Installer Trivy et scanner les dépendances
#!/bin/bash
# Installation de Trivy (scanner open-source pour vulnérabilités)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.55.0
# Créer un projet Node.js exemple
mkdir supply-chain-demo && cd supply-chain-demo
npm init -y
npm install lodash express
# Générer SBOM et scanner
trivy fs . --format json --output trivy-deps.json --scanners vuln,license,malware
trivy sbom trivy-deps.json --format table
# Exemple de sortie critique si vulnérabilités hautes
# Afficher résumé
trivy fs . --format sarif --output results.sarifCe script installe Trivy, crée un projet Node.js vulnérable, génère un SBOM et scanne les dépendances pour vulnérabilités, licences et malwares. Il produit un rapport SARIF compatible GitHub. Piège : Toujours scanner en mode vuln,license pour une vue complète ; ignorez les faux positifs sans triage manuel.
Interpréter les scans Trivy
Trivy détecte les CVE dans les dépendances comme lodash (ex: CVE-2021-23337). Le SBOM (Software Bill of Materials) liste tous les composants, essentiel pour la traçabilité. Intégrez les rapports SARIF à GitHub pour des alertes automatiques.
Analogie : Imaginez votre supply chain comme une chaîne alimentaire ; Trivy est le contrôle sanitaire qui repère les contaminants avant distribution.
Configurer GitHub Actions pour SCA automatique
name: SCA with Trivy
on: [push, pull_request]
permissions:
contents: read
id-token: write
security-events: write
jobs:
sca:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
format: 'sarif'
output: 'trivy-results.sarif'
severity: 'CRITICAL,HIGH'
- name: Upload Trivy scan
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: 'trivy-results.sarif'Ce workflow GitHub Actions scanne automatiquement à chaque push/PR avec Trivy, upload les résultats SARIF pour des alertes de sécurité. Permissions minimales (id-token: write) pour SLSA. Piège : Limitez severity pour éviter les faux positifs bloquants ; testez en branch avant main.
Dockerfile sécurisé avec base image minimale
FROM node:20-alpine AS base
# Installer deps sans cache pour reproductibilité
WORKDIR /app
COPY package*.json .
RUN --mount=type=cache,target=/root/.npm npm ci --only=production --no-optional
# Copier source
COPY . .
# Multi-stage pour runtime minimal
FROM base AS runner
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]
# Labels SLSA
LABEL org.opencontainers.image.source=https://github.com/user/supply-chain-demo
LABEL org.opencontainers.image.licenses=MITDockerfile multi-stage avec Node Alpine, non-root user, cache npm et labels OCI pour traçabilité. Évite les layers inutiles réduisant la surface d'attaque. Piège : Utilisez --mount=type=cache en CI pour accélérer sans compromettre la reproductibilité.
Build et push de l'image
Compilez avec docker build -t ghcr.io/user/supply-chain-demo:v1 . et pushez vers GHCR. Les labels facilitent la vérification downstream.
Signer l'image avec Cosign
#!/bin/bash
# Authentification GitHub Container Registry
echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin
# Build et tag
IMAGE=ghcr.io/USERNAME/supply-chain-demo:v1
docker build -t $IMAGE .
docker push $IMAGE
# Générer clé Cosign (ou utiliser GitHub OIDC)
cosign generate-key-pair
# Signer avec clé privée
cosign sign -key cosign.key $IMAGE
# Attestation SLSA provenance
cosign attest --predicate-type https://slsa.dev/provenance/v1 $IMAGE
# Vérifier
cosign verify $IMAGEScript complet pour build, push, signer et attester une image avec Cosign via GitHub OIDC (token implicite). Crée une signature Fulcio Rekor pour vérification sans clé privée. Piège : Utilisez OIDC (permissions: id-token) en CI pour éviter les secrets statiques.
Workflow GitHub Actions pour build/sign SLSA Level 2
name: Build and Sign SLSA L2
on: [push]
permissions:
contents: read
id-token: write
packages: write
jobs:
build:
runs-on: ubuntu-latest
container:
image: ghcr.io/project-everest/kstool:slsa2-debian11
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: slsa-framework/slsa-github-generator/.github/actions/slsa-build-provenance@main
with:
provenance-name: 'supply-chain-demo'
base64-provenance: false
- name: Sign
run: |
cosign sign --yes ghcr.io/USERNAME/supply-chain-demo@${{ steps.slsa.outputs.artifact-digest }}Workflow SLSA Level 2 utilisant kstool et slsa-github-generator pour build en conteneur reproductible et génération d'attestations provenance. Signature Cosign sur digest immuable. Piège : fetch-depth: 0 pour historique Git complet ; validez SLSA compliance avec slsa-verifier.
Déployer Dependency-Track pour monitoring SBOM
version: '3.8'
services:
postgres:
image: postgres:15-alpine
environment:
POSTGRES_DB: dtrack
POSTGRES_USER: dtrack
POSTGRES_PASSWORD: changeit
volumes:
- postgres:/var/lib/postgresql/data
dependency-track:
image: owasp/dependency-track:4.14.0
ports:
- "8081:8080"
environment:
ALPINE_CDN_MIRROR: http://dl-cdn.alpinelinux.org/alpine
depends_on:
- postgres
volumes:
- dtrack:/data
volumes:
postgres:
dtrack:
# Upload SBOM: curl -X POST http://localhost:8081/api/v1/bom -F autoCreate=true -F projectUuid=UUID -F bom=@trivy-deps.jsonDocker Compose pour Dependency-Track, outil de monitoring SBOM qui tracke les vulnérabilités en continu. Upload SBOM via API. Piège : Changez les creds par défaut ; intégrez à CI pour uploads automatisés avec projectUuid fixe.
Bonnes pratiques
- SLSA au minimum Level 2 : Assurez la provenance non-falsifiable des builds.
- SBOM systématique : Générez en CycloneDX/SPDX pour tous artefacts.
- Signatures hiérarchiques : Cosign + Rekor pour chaîne de confiance.
- Zero-trust pipelines : Permissions OIDC, pas de secrets long-lived.
- Alerting proactif : Intégrez SARIF à GitHub Advanced Security.
Erreurs courantes à éviter
- Scanner seulement en dev : Toujours en CI/CD et pre-prod pour catch upstream.
- Ignorer les signatures : Vérifiez systématiquement avec
cosign verify --certificate-identity. - Dépendances non-pinned : Utilisez lockfiles (package-lock.json) pour reproductibilité.
- Builds root : Non-root users et multi-stage pour réduire blast radius.
Pour aller plus loin
- Documentation SLSA : slsa.dev.
- Sigstore : sigstore.dev.
- Formation DevSecOps avancée : Formations Learni.
- Outils : in-toto, Chainguard Images.
- Livre : 'Secure Software Supply Chain' de Dan Lorenc.