Sécuriser la chaîne d'approvisionnement logicielle sur Linux : guide pratique SBOM, Sigstore et SLSA en 2026

Introduction : la chaîne d'approvisionnement logicielle sous pression

Soyons honnêtes : les attaques ciblant la chaîne d'approvisionnement logicielle ont explosé ces dernières années, et ça ne fait qu'empirer. De SolarWinds à l'incident XZ Utils en 2024, en passant par les compromissions de registres npm et PyPI, les adversaires ont bien compris qu'il est souvent plus rentable de corrompre un maillon de la chaîne de production que d'attaquer directement un système cible. Pour nous, administrateurs Linux, cette réalité impose une transformation profonde des pratiques : sécuriser les serveurs en production ne suffit plus. Il faut désormais garantir l'intégrité de chaque composant logiciel, de sa source jusqu'à son déploiement.

En 2026, le cadre réglementaire vient renforcer cette exigence. Le Cyber Resilience Act (CRA) de l'Union européenne impose aux fabricants de produits numériques de maintenir un inventaire logiciel (SBOM) et de signaler les vulnérabilités activement exploitées dès septembre 2026. En parallèle, des standards ouverts comme SLSA (Supply-chain Levels for Software Artifacts), Sigstore et les formats SPDX et CycloneDX sont devenus les piliers techniques de cette sécurisation.

Les chiffres donnent le vertige : le nombre de CVE affectant le noyau Linux a bondi de plus de 1 100 % en 2024 pour atteindre 3 529 vulnérabilités, puis plus de 5 500 en 2025. Ça fait en moyenne 8 à 9 nouvelles CVE du noyau par jour. Autant dire que disposer d'un inventaire précis de chaque composant logiciel n'est plus un luxe — c'est une nécessité opérationnelle.

Ce guide vous accompagne pas à pas dans la mise en place d'une chaîne d'approvisionnement logicielle sécurisée sur Linux. On va combiner la génération de SBOM, la signature cryptographique des artefacts, la vérification de provenance et l'analyse automatisée des vulnérabilités. Chaque section inclut des exemples concrets et des commandes prêtes à l'emploi que vous pouvez intégrer immédiatement dans votre infrastructure.

Comprendre le SBOM : inventaire complet de vos composants logiciels

Qu'est-ce qu'un SBOM et pourquoi est-il indispensable ?

Un Software Bill of Materials (SBOM) est un inventaire structuré et lisible par machine de tous les composants qui constituent un logiciel : bibliothèques, frameworks, modules, dépendances directes et transitives. Pour faire simple, il joue le même rôle que la liste d'ingrédients sur un produit alimentaire — il vous dit exactement ce qui se trouve dans votre application.

L'intérêt du SBOM est multiple :

• Réponse rapide aux vulnérabilités : quand une CVE critique tombe (comme Log4Shell), un SBOM permet d'identifier en quelques secondes tous les systèmes affectés
• Conformité réglementaire : le CRA européen et les directives du NIST américain exigent désormais la production et la conservation de SBOM
• Transparence de la chaîne de confiance : chaque maillon de la chaîne logicielle peut être audité et vérifié
• Gestion des licences : identification automatique des obligations légales liées aux composants open source

Les deux formats standards : SPDX et CycloneDX

Deux formats dominent l'écosystème SBOM en 2026, et le choix entre les deux n'est pas toujours évident.

SPDX (Software Package Data Exchange), développé sous l'égide de la Linux Foundation, est devenu un standard ISO (ISO/IEC 5962:2021). Sa version 3.0 offre une couverture étendue des informations de licence et de conformité. Les formats de sortie supportés incluent JSON, XML, RDF/XML et YAML. Si la conformité légale et la gestion des licences sont votre priorité, c'est vers SPDX qu'il faut se tourner.

CycloneDX, créé par l'OWASP Foundation, est davantage orienté sécurité. Sa version 1.6 supporte nativement les déclarations VEX (Vulnerability Exploitability eXchange), le hachage cryptographique des composants et les arbres de dépendances complets. Formats de sortie : JSON, XML et Protocol Buffers. C'est le choix privilégié des équipes DevSecOps, et personnellement c'est celui que je recommande dans la plupart des cas.

En pratique, les deux formats sont interopérables dans une certaine mesure, mais une conversion peut entraîner une perte de données spécifiques. La recommandation : choisissez le format le mieux adapté à votre cas d'usage principal et tenez-vous-y.

Générer des SBOM avec Syft sur Linux

Installation de Syft

Syft, développé par Anchore, est devenu l'outil de référence pour la génération de SBOM sur Linux. Il analyse les images de conteneurs, les systèmes de fichiers et les répertoires de projets pour produire un inventaire complet des composants.

# Installation via le script officiel
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Vérification de l'installation
syft version

# Alternative : installation via Go
go install github.com/anchore/syft/cmd/syft@latest

Générer un SBOM pour une image de conteneur

La méthode la plus courante consiste à générer un SBOM pour une image Docker ou OCI :

# SBOM au format SPDX JSON pour une image Docker
syft docker:nginx:latest -o spdx-json=nginx-sbom.spdx.json

# SBOM au format CycloneDX JSON
syft docker:nginx:latest -o cyclonedx-json=nginx-sbom.cdx.json

# SBOM pour une image depuis un registre distant
syft registry:ghcr.io/mon-org/mon-app:v2.1.0 -o spdx-json=mon-app-sbom.json

Générer un SBOM pour un système de fichiers Linux

Syft peut aussi analyser directement un système de fichiers, ce qui est particulièrement utile pour auditer un serveur en production :

# Analyser le répertoire racine d'un système
syft dir:/ -o cyclonedx-json=serveur-sbom.cdx.json

# Analyser un répertoire de projet spécifique
syft dir:/opt/mon-application -o spdx-json=app-sbom.spdx.json

# Analyser une archive tar
syft file:mon-image.tar -o cyclonedx-json=image-sbom.cdx.json

Automatiser la génération dans un pipeline CI/CD

L'intégration dans un pipeline CI/CD garantit que chaque build produit un SBOM à jour. Voici comment procéder :

# Exemple pour GitLab CI (.gitlab-ci.yml)
generate_sbom:
  stage: build
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json=sbom.cdx.json
    - syft docker:${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA} -o spdx-json=sbom.spdx.json
  artifacts:
    paths:
      - sbom.cdx.json
      - sbom.spdx.json
    expire_in: 1 year

# Exemple pour GitHub Actions
name: Generate SBOM
on:
  push:
    branches: [main]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anchore/sbom-action@v0
        with:
          image: ${{ env.IMAGE_NAME }}
          format: cyclonedx-json
          output-file: sbom.cdx.json
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json

Analyser les vulnérabilités avec Grype

Installation et configuration

Grype, également développé par Anchore, est le compagnon naturel de Syft. Il prend un SBOM en entrée et le croise avec des bases de données de vulnérabilités pour identifier les composants affectés. L'installation est tout aussi simple.

# Installation de Grype
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Mise à jour de la base de données de vulnérabilités
grype db update

# Vérification
grype version

Analyser un SBOM existant

# Analyse à partir d'un SBOM généré par Syft
grype sbom:./nginx-sbom.cdx.json

# Analyse directe d'une image (sans SBOM intermédiaire)
grype docker:nginx:latest

# Filtrer par sévérité (Critical et High uniquement)
grype sbom:./nginx-sbom.cdx.json --only-fixed --fail-on high

# Sortie au format JSON pour traitement automatisé
grype sbom:./nginx-sbom.cdx.json -o json > vulnerabilities.json

Intégrer Grype comme porte de qualité (quality gate)

Dans un pipeline CI/CD, Grype peut servir de garde-fou automatique qui bloque un déploiement si des vulnérabilités critiques sont détectées. C'est un filet de sécurité que je conseille vraiment de mettre en place :

# Script de vérification pour pipeline CI/CD
#!/bin/bash
set -e

SBOM_FILE="sbom.cdx.json"
SEVERITY_THRESHOLD="high"

echo "=== Analyse des vulnérabilités ==="
grype sbom:./${SBOM_FILE} --fail-on ${SEVERITY_THRESHOLD} -o table

if [ $? -ne 0 ]; then
    echo "ERREUR : Des vulnérabilités de sévérité ${SEVERITY_THRESHOLD} ou supérieure ont été détectées."
    echo "Le déploiement est bloqué. Veuillez corriger les vulnérabilités avant de continuer."
    exit 1
fi

echo "Aucune vulnérabilité critique détectée. Déploiement autorisé."

Enrichir l'analyse avec les déclarations VEX

Les déclarations VEX (Vulnerability Exploitability eXchange) permettent de contextualiser les vulnérabilités détectées. Parce qu'une CVE présente dans une dépendance n'est pas forcément exploitable dans votre contexte spécifique (et ça arrive plus souvent qu'on ne le pense) :

# Appliquer un document VEX pour filtrer les faux positifs
grype sbom:./sbom.cdx.json --vex mon-projet.vex.json

# Exemple de document VEX (OpenVEX)
{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://mon-org.fr/vex/2026-001",
  "author": "Équipe Sécurité",
  "timestamp": "2026-02-07T10:00:00Z",
  "statements": [
    {
      "vulnerability": {"name": "CVE-2026-12345"},
      "products": [{"@id": "pkg:oci/mon-app@sha256:abc123"}],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

Signer et vérifier les artefacts avec Sigstore et Cosign

L'écosystème Sigstore

Sigstore est un projet de la Linux Foundation qui fournit une infrastructure de signature cryptographique gratuite et ouverte pour les artefacts logiciels. C'est un peu la révolution dans le domaine. L'écosystème comprend plusieurs composants :

• Cosign : outil de signature et de vérification des images de conteneurs et des artefacts binaires
• Fulcio : autorité de certification qui émet des certificats éphémères basés sur l'identité OpenID Connect
• Rekor : journal de transparence immuable qui enregistre toutes les signatures pour garantir leur non-répudiation
• Gitsign : extension pour signer les commits Git avec Sigstore

Installation de Cosign

# Installation sur Linux (amd64)
COSIGN_VERSION="v2.4.1"
curl -LO "https://github.com/sigstore/cosign/releases/download/${COSIGN_VERSION}/cosign-linux-amd64"
chmod +x cosign-linux-amd64
sudo mv cosign-linux-amd64 /usr/local/bin/cosign

# Vérification
cosign version

# Alternative via Go
go install github.com/sigstore/cosign/v2/cmd/cosign@latest

Signature sans clé (keyless signing)

La signature sans clé est l'approche recommandée par Sigstore, et franchement c'est ce qui rend cet outil si élégant. Elle utilise l'identité du développeur (via OIDC) plutôt qu'une clé privée à gérer manuellement :

# Signer une image de conteneur (keyless)
cosign sign ghcr.io/mon-org/mon-app:v2.1.0

# Le processus :
# 1. Cosign génère une paire de clés éphémère
# 2. Fulcio vérifie votre identité via OIDC (Google, GitHub, Microsoft)
# 3. Un certificat éphémère est émis
# 4. L'image est signée et la signature enregistrée dans Rekor
# 5. La clé privée éphémère est détruite

# Vérifier la signature
cosign verify ghcr.io/mon-org/mon-app:v2.1.0 \
  [email protected] \
  --certificate-oidc-issuer=https://accounts.google.com

Signature avec clé traditionnelle

Pour les environnements sans accès à un fournisseur OIDC ou nécessitant un contrôle complet des clés, l'approche classique reste disponible :

# Générer une paire de clés
cosign generate-key-pair

# Signer avec la clé privée
cosign sign --key cosign.key ghcr.io/mon-org/mon-app:v2.1.0

# Vérifier avec la clé publique
cosign verify --key cosign.pub ghcr.io/mon-org/mon-app:v2.1.0

Attacher un SBOM à une image signée

Cosign permet d'attacher un SBOM directement à une image de conteneur dans le registre OCI. C'est malin, parce que ça crée un lien indissociable entre l'artefact et son inventaire :

# Générer le SBOM
syft docker:ghcr.io/mon-org/mon-app:v2.1.0 -o cyclonedx-json=sbom.cdx.json

# Attacher le SBOM à l'image
cosign attach sbom --sbom sbom.cdx.json ghcr.io/mon-org/mon-app:v2.1.0

# Signer le SBOM attaché
cosign sign --attachment sbom ghcr.io/mon-org/mon-app:v2.1.0

# Vérifier le SBOM attaché
cosign verify --attachment sbom \
  [email protected] \
  --certificate-oidc-issuer=https://accounts.google.com \
  ghcr.io/mon-org/mon-app:v2.1.0

Signer les commits Git avec Gitsign

La sécurisation de la chaîne d'approvisionnement commence dès le code source. Gitsign remplace la signature GPG traditionnelle des commits par une signature basée sur l'identité OIDC, et c'est un vrai changement de paradigme :

# Installation de Gitsign
go install github.com/sigstore/gitsign@latest

# Configuration globale de Git pour utiliser Gitsign
git config --global commit.gpgsign true
git config --global tag.gpgsign true
git config --global gpg.x509.program gitsign
git config --global gpg.format x509

# Effectuer un commit signé
git commit -m "feat: ajout du module d'authentification"
# Gitsign ouvre automatiquement le navigateur pour l'authentification OIDC

# Vérifier la signature d'un commit
git log --show-signature -1

# Vérifier avec Gitsign directement
gitsign verify [email protected] \
  --certificate-oidc-issuer=https://accounts.google.com \
  HEAD

L'avantage de Gitsign par rapport à GPG est énorme : plus de clé privée à gérer, à distribuer ou à révoquer. L'identité du développeur est vérifiée à chaque commit via son fournisseur d'identité, et la signature est enregistrée dans le journal de transparence Rekor. Résultat : une piste d'audit immuable de tous les commits signés.

Garantir la provenance avec SLSA

Qu'est-ce que SLSA ?

SLSA (prononcé « salsa ») est un cadre de sécurité créé par la communauté OpenSSF qui définit des niveaux progressifs de garantie pour la chaîne d'approvisionnement logicielle. La version 1.2, publiée fin 2025, introduit des pistes distinctes pour le build (Build Track) et le code source (Source Track).

Les niveaux du Build Track :

• SLSA Build Level 1 : la provenance existe. Le build produit un document décrivant comment l'artefact a été construit (plateforme, processus, entrées principales)
• SLSA Build Level 2 : plateforme de build hébergée. La provenance est générée et signée par la plateforme de build elle-même, pas par le développeur
• SLSA Build Level 3 : builds durcis. La plateforme de build est isolée et protégée contre les altérations, même par les administrateurs du projet

Générer et vérifier la provenance SLSA

GitHub Actions offre un support natif pour la génération de provenance SLSA, ce qui rend l'adoption assez simple si vous êtes déjà sur cette plateforme :

# .github/workflows/slsa-build.yml
name: Build avec provenance SLSA
on:
  push:
    tags: ['v*']

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/checkout@v4

      - name: Build de l'image
        run: |
          docker build -t ghcr.io/mon-org/mon-app:${{ github.ref_name }} .

      - name: Push de l'image
        run: |
          docker push ghcr.io/mon-org/mon-app:${{ github.ref_name }}

      - name: Générer l'attestation de provenance
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ghcr.io/mon-org/mon-app
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

Pour vérifier la provenance d'un artefact :

# Installation du vérificateur SLSA
go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest

# Vérification de la provenance d'un binaire
slsa-verifier verify-artifact mon-app-linux-amd64 \
  --provenance-path mon-app.intoto.jsonl \
  --source-uri github.com/mon-org/mon-app \
  --source-tag v2.1.0

# Vérification de la provenance d'une image de conteneur
slsa-verifier verify-image ghcr.io/mon-org/mon-app:v2.1.0 \
  --source-uri github.com/mon-org/mon-app \
  --source-tag v2.1.0

Politique d'admission Kubernetes : n'autoriser que les artefacts vérifiés

Kyverno : contrôleur d'admission pour la vérification de signatures

Bon, maintenant que vos artefacts sont signés et accompagnés de leur SBOM, il serait dommage de ne pas en profiter au moment du déploiement. Kyverno est un contrôleur d'admission natif Kubernetes qui peut vérifier les signatures Cosign et les attestations SLSA avant d'autoriser le déploiement d'un pod :

# Installation de Kyverno
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

# Politique de vérification des signatures Cosign
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verifier-signatures-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verifier-signature-cosign
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/mon-org/*"
          attestors:
            - entries:
                - keyless:
                    subject: "*@mon-org.fr"
                    issuer: "https://accounts.google.com"
                    rekor:
                      url: https://rekor.sigstore.dev

Politique de vérification du SBOM

On peut aller encore plus loin en exigeant qu'un SBOM soit attaché à chaque image :

# Politique Kyverno exigeant un SBOM attaché
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: exiger-sbom
spec:
  validationFailureAction: Enforce
  rules:
    - name: verifier-sbom-attache
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/mon-org/*"
          attestations:
            - type: https://cyclonedx.org/bom
              attestors:
                - entries:
                    - keyless:
                        subject: "*@mon-org.fr"
                        issuer: "https://accounts.google.com"
              conditions:
                - all:
                    - key: "{{ components[].name }}"
                      operator: AllNotIn
                      value: ["composant-interdit-v1"]

Pipeline complet DevSecOps : de la source au déploiement

Architecture du pipeline sécurisé

Voici un pipeline complet qui intègre toutes les étapes de sécurisation de la chaîne d'approvisionnement. C'est le genre de configuration qu'on met en place une fois et qui vous protège au quotidien :

# Pipeline DevSecOps complet (.gitlab-ci.yml)
stages:
  - build
  - sbom
  - scan
  - sign
  - deploy

variables:
  IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}

build_image:
  stage: build
  script:
    - docker build -t ${IMAGE} .
    - docker push ${IMAGE}

generate_sbom:
  stage: sbom
  script:
    - syft docker:${IMAGE} -o cyclonedx-json=sbom.cdx.json
    - syft docker:${IMAGE} -o spdx-json=sbom.spdx.json
    # Archiver les SBOM pour conformité CRA
    - cp sbom.cdx.json /archives/sbom-${CI_COMMIT_SHA}.cdx.json
  artifacts:
    paths:
      - sbom.cdx.json
      - sbom.spdx.json

scan_vulnerabilities:
  stage: scan
  script:
    - grype sbom:./sbom.cdx.json --fail-on critical -o table
    - grype sbom:./sbom.cdx.json -o json > rapport-vuln.json
  artifacts:
    paths:
      - rapport-vuln.json
  allow_failure: false

sign_and_attach:
  stage: sign
  script:
    # Signer l'image
    - cosign sign ${IMAGE}
    # Attacher et signer le SBOM
    - cosign attach sbom --sbom sbom.cdx.json ${IMAGE}
    - cosign sign --attachment sbom ${IMAGE}
    # Attacher l'attestation de provenance
    - cosign attest --predicate provenance.json --type slsaprovenance ${IMAGE}

deploy_verified:
  stage: deploy
  script:
    # Vérifier avant déploiement
    - cosign verify ${IMAGE}
      [email protected]
      --certificate-oidc-issuer=https://gitlab.com
    # Déployer sur Kubernetes
    - kubectl set image deployment/mon-app
      container=${IMAGE}
  environment:
    name: production

Script d'audit complet de la chaîne d'approvisionnement

Ce script bash permet d'auditer l'état de sécurité de la chaîne d'approvisionnement pour un ensemble d'images. Je l'utilise régulièrement et il a déjà permis de repérer des problèmes avant qu'ils ne deviennent critiques :

#!/bin/bash
# audit-supply-chain.sh
# Script d'audit de la chaîne d'approvisionnement logicielle

set -euo pipefail

REGISTRY="ghcr.io/mon-org"
IMAGES=("api-gateway:latest" "auth-service:latest" "web-frontend:latest")
REPORT_DIR="./rapports-audit-$(date +%Y%m%d)"
OIDC_ISSUER="https://accounts.google.com"
IDENTITY="[email protected]"

mkdir -p "${REPORT_DIR}"

echo "============================================"
echo "  Audit de la chaîne d'approvisionnement"
echo "  Date : $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "============================================"

TOTAL=0
PASSED=0
FAILED=0

for IMAGE_TAG in "${IMAGES[@]}"; do
    FULL_IMAGE="${REGISTRY}/${IMAGE_TAG}"
    IMAGE_NAME=$(echo "${IMAGE_TAG}" | cut -d: -f1)
    echo ""
    echo "--- Audit de ${FULL_IMAGE} ---"
    TOTAL=$((TOTAL + 1))
    IMAGE_OK=true

    # Étape 1 : Vérification de la signature
    echo "[1/4] Vérification de la signature Cosign..."
    if cosign verify "${FULL_IMAGE}" \
        --certificate-identity="${IDENTITY}" \
        --certificate-oidc-issuer="${OIDC_ISSUER}" > /dev/null 2>&1; then
        echo "  ✓ Signature valide"
    else
        echo "  ✗ Signature INVALIDE ou absente"
        IMAGE_OK=false
    fi

    # Étape 2 : Génération du SBOM
    echo "[2/4] Génération du SBOM..."
    SBOM_FILE="${REPORT_DIR}/${IMAGE_NAME}-sbom.cdx.json"
    syft docker:"${FULL_IMAGE}" -o cyclonedx-json="${SBOM_FILE}" 2>/dev/null
    COMPONENT_COUNT=$(jq '.components | length' "${SBOM_FILE}")
    echo "  ✓ ${COMPONENT_COUNT} composants identifiés"

    # Étape 3 : Analyse des vulnérabilités
    echo "[3/4] Analyse des vulnérabilités..."
    VULN_FILE="${REPORT_DIR}/${IMAGE_NAME}-vulns.json"
    grype sbom:"${SBOM_FILE}" -o json > "${VULN_FILE}" 2>/dev/null
    CRITICAL=$(jq '[.matches[] | select(.vulnerability.severity == "Critical")] | length' "${VULN_FILE}")
    HIGH=$(jq '[.matches[] | select(.vulnerability.severity == "High")] | length' "${VULN_FILE}")
    echo "  Critiques: ${CRITICAL} | Hautes: ${HIGH}"
    if [ "${CRITICAL}" -gt 0 ]; then
        IMAGE_OK=false
    fi

    # Étape 4 : Vérification de la provenance SLSA
    echo "[4/4] Vérification de la provenance SLSA..."
    if cosign verify-attestation "${FULL_IMAGE}" \
        --type slsaprovenance \
        --certificate-identity="${IDENTITY}" \
        --certificate-oidc-issuer="${OIDC_ISSUER}" > /dev/null 2>&1; then
        echo "  ✓ Provenance SLSA vérifiée"
    else
        echo "  ⚠ Aucune attestation SLSA trouvée"
    fi

    if [ "${IMAGE_OK}" = true ]; then
        PASSED=$((PASSED + 1))
        echo "  → Résultat : CONFORME"
    else
        FAILED=$((FAILED + 1))
        echo "  → Résultat : NON CONFORME"
    fi
done

echo ""
echo "============================================"
echo "  Résumé de l'audit"
echo "  Total: ${TOTAL} | Conformes: ${PASSED} | Non conformes: ${FAILED}"
echo "  Rapports sauvegardés dans : ${REPORT_DIR}"
echo "============================================"

Conformité réglementaire : CRA et au-delà

Le Cyber Resilience Act et les obligations SBOM

Le Cyber Resilience Act (Règlement (UE) 2024/2847) impose des obligations concrètes aux fabricants de produits numériques commercialisés dans l'Union européenne. Le calendrier est progressif, et certaines échéances approchent vite :

• 11 juin 2026 : application des règles de notification et de désignation des organismes d'évaluation de la conformité
• 11 septembre 2026 : obligation de signalement des vulnérabilités et incidents activement exploités (Article 14)
• 11 décembre 2027 : entrée en vigueur complète, y compris les exigences SBOM

Concrètement, pour nous administrateurs Linux, ça veut dire :

• Chaque produit doit disposer d'un SBOM dans un format lisible par machine (SPDX ou CycloneDX)
• Le SBOM doit couvrir au minimum les dépendances de premier niveau
• Le SBOM doit être intégré à la documentation technique du produit
• Le SBOM doit être fourni aux autorités de surveillance du marché sur demande
• Un nouveau SBOM doit être généré à chaque mise à jour d'un composant

Recommandations de la CISA

L'agence américaine CISA (Cybersecurity and Infrastructure Security Agency) a publié des recommandations complémentaires pour la consommation de SBOM. Même si elles n'ont pas force de loi en Europe, elles constituent un bon cadre de référence :

• Inventaire continu : maintenir un inventaire centralisé et à jour de tous les SBOM de l'organisation
• Corrélation avec les vulnérabilités : croiser automatiquement les SBOM avec les bases de données de vulnérabilités (NVD, OSV)
• Contrôle d'accès : protéger les SBOM car ils révèlent la composition interne des systèmes
• Chaîne de confiance : vérifier l'authenticité et l'intégrité des SBOM reçus de fournisseurs tiers

Leçons tirées des incidents récents

L'affaire XZ Utils (CVE-2024-3094) : un cas d'école

L'incident XZ Utils de mars 2024 reste probablement le meilleur exemple de pourquoi la sécurité de la chaîne d'approvisionnement est critique pour l'écosystème Linux. Un mainteneur malveillant, « Jia Tan », a infiltré le projet open source xz-utils pendant deux ans. Deux ans ! Il a gagné progressivement la confiance de la communauté avant d'injecter une porte dérobée dans les versions 5.6.0 et 5.6.1 de la bibliothèque liblzma. Cette porte dérobée ciblait spécifiquement les serveurs OpenSSH sur les distributions Linux utilisant systemd, permettant potentiellement l'exécution de code à distance.

Cet incident met en lumière plusieurs faiblesses que les outils présentés dans ce guide auraient pu aider à mitiger :

• Absence de provenance vérifiable : si les artefacts avaient été construits sur une plateforme SLSA Level 3, la porte dérobée injectée dans les scripts de build aurait été plus difficile à dissimuler, car la provenance aurait documenté exactement les étapes de construction exécutées
• Manque de transparence des dépendances : un SBOM de chaque distribution affectée aurait permis d'identifier immédiatement quels paquets incluaient les versions compromises de liblzma
• Pas de signature liée à l'identité : avec Sigstore, chaque release aurait été traçable à une identité vérifiée, rendant l'usurpation plus compliquée

La vulnérabilité TARmageddon dans async-tar (2026)

Début 2026, une faille de traversée de chemin (path traversal) dans la bibliothèque Rust async-tar a rappelé à quel point les dépendances transitives sont fragiles. Cette bibliothèque est utilisée dans de nombreux serveurs de build, pipelines CI et processus de construction d'images de conteneurs. Une vulnérabilité de ce type peut permettre à un attaquant d'écrire des fichiers arbitraires sur le système de fichiers lors de l'extraction d'une archive.

La défense en profondeur contre ce type de menace repose sur :

• La génération de SBOM récursifs incluant les dépendances transitives
• Le scan automatisé de ces SBOM avec Grype à chaque mise à jour de la base de vulnérabilités
• L'utilisation de déclarations VEX pour documenter rapidement si la vulnérabilité est exploitable dans votre contexte

Bonnes pratiques et recommandations avancées

Sécuriser le pipeline de build lui-même

La sécurisation de la chaîne d'approvisionnement commence par la protection de l'infrastructure de build. C'est souvent le maillon oublié :

• Isolation des runners CI/CD : utilisez des runners éphémères qui sont détruits après chaque build pour éliminer la persistance d'un attaquant
• Principe du moindre privilège : les jetons d'accès du pipeline ne doivent avoir que les permissions strictement nécessaires
• Reproductibilité des builds : visez les builds reproductibles (reproducible builds) pour permettre la vérification indépendante des artefacts
• Pinning des dépendances : épinglez les versions exactes (pas de plages) et vérifiez les sommes de contrôle

# Exemple de Dockerfile avec pinning strict et vérification
FROM ubuntu:24.04@sha256:abc123def456...

# Vérifier les clés GPG des dépôts
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    curl=8.5.0-2ubuntu10.6 \
    ca-certificates=20240203 && \
    rm -rf /var/lib/apt/lists/*

# Vérifier l'intégrité d'un binaire téléchargé
RUN curl -LO https://example.com/tool-v1.2.3-linux-amd64.tar.gz && \
    echo "sha256sum_attendu  tool-v1.2.3-linux-amd64.tar.gz" | sha256sum -c - && \
    tar xzf tool-v1.2.3-linux-amd64.tar.gz

Gestion des dépendances transitives

Les attaques les plus insidieuses ciblent les dépendances transitives — ces bibliothèques que vous n'avez jamais directement choisies mais qui sont incluses par vos dépendances directes. C'est un angle mort classique :

# Générer un SBOM récursif avec toutes les dépendances transitives
syft docker:mon-image:latest -o cyclonedx-json \
  --source-name mon-app \
  --source-version v2.1.0 > sbom-complet.cdx.json

# Identifier les dépendances les plus profondes
jq '.dependencies[] | select(.dependsOn | length > 5) | .ref' sbom-complet.cdx.json

# Vérifier les attestations en chaîne
cosign verify-attestation mon-image:latest \
  --type cyclonedx \
  --certificate-identity="*@trusted-builder.com" \
  --certificate-oidc-issuer="https://accounts.google.com"

Surveiller en continu avec un tableau de bord

La sécurité de la chaîne d'approvisionnement n'est pas un exercice ponctuel. C'est un processus continu, et il est essentiel de mettre en place une surveillance active :

# Cron job pour rescanner quotidiennement les images en production
# /etc/cron.d/supply-chain-scan
0 6 * * * root /opt/scripts/audit-supply-chain.sh 2>&1 | \
  mail -s "Rapport quotidien - Chaîne d'approvisionnement" [email protected]

# Script de surveillance des nouvelles CVE affectant vos SBOM
#!/bin/bash
SBOM_DIR="/var/lib/sbom"
for sbom in "${SBOM_DIR}"/*.cdx.json; do
    IMAGE_NAME=$(basename "${sbom}" .cdx.json)
    NEW_VULNS=$(grype sbom:"${sbom}" -o json 2>/dev/null | \
        jq '[.matches[] | select(.vulnerability.severity == "Critical")] | length')
    if [ "${NEW_VULNS}" -gt 0 ]; then
        echo "ALERTE: ${IMAGE_NAME} a ${NEW_VULNS} nouvelles vulnérabilités critiques"
    fi
done

Stratégie de rétention et archivage des SBOM

La conformité au CRA impose de conserver les SBOM pendant toute la durée de vie du produit, plus une période supplémentaire de dix ans. Oui, dix ans. Une stratégie d'archivage robuste est donc indispensable :

# Structure de répertoire recommandée pour l'archivage
/var/lib/sbom/
├── par-produit/
│   ├── api-gateway/
│   │   ├── v2.0.0/
│   │   │   ├── sbom.cdx.json
│   │   │   ├── sbom.spdx.json
│   │   │   ├── provenance.intoto.jsonl
│   │   │   └── rapport-vulns.json
│   │   └── v2.1.0/
│   │       └── ...
│   └── auth-service/
│       └── ...
└── index.json  # Index centralisé des SBOM

# Script de nettoyage et d'archivage
#!/bin/bash
ARCHIVE_DIR="/var/lib/sbom/archives"
ACTIVE_DIR="/var/lib/sbom/par-produit"
RETENTION_DAYS=3650  # 10 ans

find "${ACTIVE_DIR}" -name "*.cdx.json" -mtime +${RETENTION_DAYS} \
  -exec gzip {} \; \
  -exec mv {}.gz "${ARCHIVE_DIR}/" \;

Pensez aussi à stocker les SBOM dans un registre OCI en les attachant directement aux images avec Cosign, comme on l'a vu plus haut. Cette approche garantit que le SBOM reste associé à l'artefact qu'il décrit, même si les systèmes de fichiers changent.

Conclusion : vers une chaîne de confiance complète

La sécurisation de la chaîne d'approvisionnement logicielle sur Linux est devenue une nécessité technique et réglementaire incontournable en 2026. Les outils et standards présentés dans ce guide — SBOM avec Syft, analyse de vulnérabilités avec Grype, signature avec Cosign/Sigstore, provenance avec SLSA et admission contrôlée avec Kyverno — forment un écosystème cohérent et mature.

Voici les points clés à retenir :

• Automatisez la génération de SBOM à chaque build, pas manuellement ni ponctuellement
• Signez tous vos artefacts avec Cosign, en privilégiant la signature sans clé pour sa simplicité
• Bloquez les déploiements d'images non signées ou contenant des vulnérabilités critiques
• Adoptez SLSA progressivement : commencez par le niveau 1 (provenance) puis progressez vers le niveau 3
• Préparez-vous au CRA : les échéances de septembre 2026 et décembre 2027 arrivent plus vite qu'on ne le croit
• Surveillez en continu : la sécurité de la chaîne d'approvisionnement est un processus, pas un état figé

La mise en place de ces pratiques demande un investissement initial, c'est vrai. Mais le retour est considérable : une confiance vérifiable dans chaque composant logiciel déployé sur vos systèmes Linux, et la conformité avec un cadre réglementaire de plus en plus exigeant. Alors, on s'y met ?