Skip to content
Learni
Voir tous les tutoriels
Sécurité DevOps

Comment sécuriser la supply chain logicielle en 2026

Read in English

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

scan-deps.sh
#!/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.sarif

Ce 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

.github/workflows/sca-trivy.yml
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

Dockerfile
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=MIT

Dockerfile 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

sign-image.sh
#!/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 $IMAGE

Script 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

.github/workflows/build-sign.yml
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

docker-compose.yml
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.json

Docker 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.
Comment sécuriser supply chain logicielle 2026 | Learni