SBOM for Containers & Helm Charts in 2026: Syft, Grype, EU CRA & the Complete DevOps GuideSBOM pour Containers & Helm Charts en 2026 : Syft, Grype, EU CRA & Guide Complet DevOps

If you are deploying containerized workloads on Kubernetes in 2026, your attack surface extends far beyond your application code. Every Docker image layer, every OS package, every system library bundled in your containers is a potential CVE vector — and you almost certainly don't have a complete inventory of them. That's what an SBOM is for. And since September 2026 marks the start of mandatory vulnerability reporting under the EU Cyber Resilience Act, the moment to act is now.

Si vous déployez des workloads conteneurisés sur Kubernetes en 2026, votre surface d’attaque s’étend bien au-delà de votre code applicatif. Chaque couche d’image Docker, chaque package OS, chaque bibliothèque système embarquée dans vos containers est un vecteur CVE potentiel — et vous n’en avez presque certainement pas d’inventaire complet. C’est à ça que sert un SBOM. Et puisque septembre 2026 marque le début du reporting obligatoire des vulnérabilités sous l’EU Cyber Resilience Act, le moment d’agir est maintenant.

This guide covers the full DevOps SBOM pipeline: generating SBOMs from container images and Helm charts with Syft, scanning with Grype, integrating into GitHub Actions, validating against CISA's 2025 minimum elements update, and what the EU CRA September 2026 deadline actually requires from your team.

Ce guide couvre le pipeline SBOM DevOps complet : génération de SBOM depuis les images containers et les charts Helm avec Syft, scan avec Grype, intégration dans GitHub Actions, validation contre la mise à jour des éléments minimaux CISA 2025, et ce que la deadline EU CRA septembre 2026 exige concrètement de votre équipe.

EU CRA September 2026: What the Incident Reporting Deadline Means for Container Teams

EU CRA Septembre 2026 : Ce que la Deadline de Reporting Signifie pour les Équipes Containers

The EU Cyber Resilience Act entered into force December 2024. Its phased timeline creates an often-misunderstood compliance sequence. The formal SBOM documentation requirement is December 2027 — but the incident reporting obligation starts September 2026, and it is this earlier deadline that creates urgency for container teams now.

L’EU Cyber Resilience Act est entré en vigueur en décembre 2024. Son calendrier phasé crée une séquence de conformité souvent mal comprise. L’exigence formelle de documentation SBOM est en décembre 2027 — mais l’obligation de reporting d’incidents commence en septembre 2026, et c’est cette deadline antérieure qui crée l’urgence pour les équipes containers dès maintenant.

Under EU CRA Article 14, manufacturers of products with digital elements must report to national authorities:

En vertu de l’article 14 de l’EU CRA, les fabricants de produits à éléments numériques doivent signaler aux autorités nationales :

• 24-hour early warning for any actively exploited vulnerability in their product
• Alerte précoce en 24h pour toute vulnérabilité activement exploitée dans leur produit
• 72-hour full notification with technical details and initial mitigation
• Notification complète en 72h avec détails techniques et mitigation initiale
• 14-day final report with root cause and remediation status
• Rapport final en 14 jours avec cause racine et statut de remédiation

To respond within 24 hours, you must already know every component in your deployed artifacts. That means having a current SBOM for your container images. A container image SBOM is fundamentally different from an application SBOM: it includes OS-level packages (apt/rpm), system libraries (glibc, openssl), language runtimes, AND your application dependencies — all of which can contain CVEs.

Pour répondre en 24h, vous devez déjà connaître chaque composant de vos artefacts déployés. Cela signifie avoir un SBOM courant pour vos images containers. Un SBOM d’image container est fondamentalement différent d’un SBOM applicatif : il inclut les packages OS (apt/rpm), les bibliothèques système (glibc, openssl), les runtimes de langages, ET vos dépendances applicatives — qui peuvent toutes contenir des CVE.

CISA's August 2025 update to the SBOM minimum elements added four new required fields: component hash (SHA-256/SHA-512), license identifier (SPDX expression), tool name and version (the generator), and generation context (build-time vs analysis-time). These are particularly relevant for container SBOMs: a container image SBOM generated at build time (before the image is deployed) is categorically different from one generated by analyzing a running container. The generation context field now makes this distinction explicit.

La mise à jour CISA d’août 2025 des éléments minimaux SBOM a ajouté quatre nouveaux champs obligatoires : hash du composant (SHA-256/SHA-512), identifiant de licence (expression SPDX), nom et version de l’outil (le générateur), et contexte de génération (build-time vs analyse). Ces champs sont particulièrement pertinents pour les SBOM containers : un SBOM d’image container généré au build (avant le déploiement) est catégoriquement différent d’un généré par analyse d’un container en cours d’exécution. Le champ contexte de génération rend maintenant cette distinction explicite.

Installing Syft and Grype: The Open-Source Container SBOM Stack

Installer Syft et Grype : Le Stack SBOM Container Open Source

Syft (by Anchore) is the de facto standard for container SBOM generation. It understands Docker image layers, extracts OS packages from Debian/Alpine/RHEL, discovers application dependencies, and outputs CycloneDX or SPDX. Grype (also by Anchore) takes any SBOM as input and matches components against NVD, GitHub Advisory Database, GHSA, and OSV. Together they form the most widely used open-source container security scanning pipeline in 2026.

Syft (par Anchore) est le standard de facto pour la génération de SBOM containers. Il comprend les couches d’images Docker, extrait les packages OS de Debian/Alpine/RHEL, découvre les dépendances applicatives, et produit du CycloneDX ou SPDX. Grype (aussi par Anchore) prend n’importe quel SBOM en entrée et fait correspondre les composants contre NVD, GitHub Advisory Database, GHSA et OSV. Ensemble ils forment le pipeline de sécurité container open source le plus utilisé en 2026.

# Install Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Verify installation
syft version

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

# Verify installation
grype version

# Docker alternative — run without installing
docker pull anchore/syft:latest
docker pull anchore/grype:latest

Generating SBOMs from Docker Container Images

Générer des SBOM depuis des Images Docker

A container image SBOM captures every component installed in the image at build time: OS packages, language runtimes, application dependencies, and base image contents. Syft can generate this from a local image, a remote registry, or a Dockerfile + build context.

Un SBOM d’image container capture chaque composant installé dans l’image au moment du build : packages OS, runtimes de langages, dépendances applicatives et contenu de l’image de base. Syft peut le générer depuis une image locale, un registre distant ou un Dockerfile + contexte de build.

# Generate SBOM from a local Docker image (CycloneDX format)
syft my-app:latest -o cyclonedx-json > sbom.cdx.json

# Generate from a remote registry image
syft registry:nginx:1.27-alpine -o cyclonedx-json > nginx-sbom.cdx.json

# Generate from official Node.js base image
syft node:22-slim -o cyclonedx-json > node-base-sbom.cdx.json

# Generate from Python base image
syft python:3.13-slim -o cyclonedx-json > python-base-sbom.cdx.json

# Both CycloneDX and SPDX in a single pass
syft my-app:latest \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

# Scope: only application packages (no OS packages)
syft my-app:latest --scope squashed -o cyclonedx-json > app-sbom.cdx.json

# Scope: all layers including base image OS packages (recommended for CRA)
syft my-app:latest --scope all-layers -o cyclonedx-json > full-sbom.cdx.json

For EU CRA compliance, use --scope all-layers. It captures every component across all image layers, including base image packages, which are the most common source of OS-level CVEs (openssl, curl, libexpat, etc.). The squashed scope only captures the final filesystem state and may miss packages installed in intermediate build layers.

Pour la conformité EU CRA, utilisez --scope all-layers. Il capture chaque composant à travers toutes les couches d’images, y compris les packages de l’image de base, qui sont la source la plus courante de CVE OS (openssl, curl, libexpat, etc.). Le scope squashed ne capture que l’état final du système de fichiers et peut rater des packages installés dans les couches de build intermédiaires.

Generating SBOMs from Helm Charts

Générer des SBOM depuis des Charts Helm

A Helm chart SBOM captures the collection of Kubernetes manifests, sub-chart dependencies, and the container images referenced by the chart. Syft has native Helm chart support that allows you to generate a comprehensive SBOM from a chart directory or a packaged .tgz file.

Un SBOM de chart Helm capture l’ensemble des manifestes Kubernetes, des dépendances de sous-charts et des images containers référencées par le chart. Syft supporte nativement les charts Helm et vous permet de générer un SBOM complet depuis un répertoire de chart ou un fichier .tgz packagé.

# Generate SBOM from a local Helm chart directory
syft dir:./my-helm-chart -o cyclonedx-json > helm-sbom.cdx.json

# Generate from a packaged Helm chart
syft file:./my-chart-1.2.0.tgz -o cyclonedx-json > helm-sbom.cdx.json

# Generate from a Helm chart in a registry (OCI)
syft registry:oci://registry.example.com/charts/my-chart:1.2.0 \
  -o cyclonedx-json > helm-oci-sbom.cdx.json

# Using helm template + Syft for complete manifest analysis
helm template my-release ./my-chart --values values-prod.yaml > manifests.yaml
# Syft can analyze the rendered manifests for image references
syft dir:. -o cyclonedx-json > complete-sbom.cdx.json

For a complete Kubernetes workload SBOM, you need to combine two approaches: the Helm chart SBOM (which documents what is declared) and the container image SBOMs for each image referenced in the chart (which documents what is actually running). A mature DevOps pipeline generates both at deploy time and stores them as attestations alongside the artifacts.

Pour un SBOM complet de workload Kubernetes, vous devez combiner deux approches : le SBOM du chart Helm (qui documente ce qui est déclaré) et les SBOM d’images containers pour chaque image référencée dans le chart (qui documente ce qui tourne réellement). Un pipeline DevOps mature génère les deux au moment du déploiement et les stocke comme attestations aux côtés des artefacts.

Scanning SBOMs with Grype: CVE Gates in Your Container Pipeline

Scanner les SBOM avec Grype : Portes CVE dans votre Pipeline Container

Once you have an SBOM, Grype matches every component against multiple vulnerability databases simultaneously. Unlike docker scout or trivy, Grype accepts any CycloneDX or SPDX SBOM as input — meaning it works with SBOMs generated by any tool, not just Syft.

Une fois que vous avez un SBOM, Grype fait correspondre chaque composant contre plusieurs bases de données de vulnérabilités simultanément. Contrairement à docker scout ou trivy, Grype accepte n’importe quel SBOM CycloneDX ou SPDX en entrée — ce qui signifie qu’il fonctionne avec des SBOM générés par n’importe quel outil, pas seulement Syft.

# Basic scan from SBOM file
grype sbom:sbom.cdx.json

# Fail the build on any HIGH or CRITICAL CVE
grype sbom:sbom.cdx.json --fail-on high

# Fail only on CRITICAL
grype sbom:sbom.cdx.json --fail-on critical

# Scan directly from container image (Syft + Grype in one command)
grype my-app:latest

# Output as JSON for downstream processing
grype sbom:sbom.cdx.json -o json > grype-report.json

# Output as SARIF for GitHub Security tab integration
grype sbom:sbom.cdx.json -o sarif > grype.sarif

# Pipe Syft output directly into Grype
syft my-app:latest -o syft-json | grype --add-cpes-if-none

# Ignore specific CVEs (use sparingly, document the reason)
# Create a .grype.yaml in project root:
# ignore:
#   - vulnerability: CVE-2023-1234
#     reason: "Not exploitable: vulnerable code path not used"

Understanding Grype output

Comprendre la sortie Grype

NAME          INSTALLED  FIXED-IN   TYPE       VULNERABILITY   SEVERITY
curl          8.7.1      8.7.2      deb        CVE-2026-18510  High
libssl3       3.1.4      3.1.7      deb        CVE-2025-15467  Critical
express       4.18.2     4.21.0     node-pkg   CVE-2024-43796  Medium
python3.12    3.12.0     3.12.4     rpm        CVE-2025-6114   High

Key columns: INSTALLED is the version in your image; FIXED-IN is the version that patches the CVE. If FIXED-IN is empty, no patch exists yet. Prioritize: fix CRITICAL and HIGH with available patches first. For unfixed CVEs, assess exploitability using the severity and consider VEX attestation if the vulnerability is in a code path you don't use.

Colonnes clés : INSTALLED est la version dans votre image ; FIXED-IN est la version qui corrige le CVE. Si FIXED-IN est vide, aucun patch n’existe encore. Prioritisez : corrigez d’abord les CRITICAL et HIGH avec des patchs disponibles. Pour les CVE sans correction, évaluez l’exploitabilité et envisagez une attestation VEX si la vulnérabilité est dans un code path non utilisé.

Complete GitHub Actions SBOM Pipeline

Pipeline SBOM GitHub Actions Complet

The following workflow generates a CycloneDX SBOM from your Docker image after every build, scans with Grype, uploads results to the GitHub Security tab (SARIF), and attaches the SBOM as a build attestation using Sigstore/cosign. This is the production-grade pattern that satisfies EU CRA artifact documentation requirements.

Le workflow suivant génère un SBOM CycloneDX depuis votre image Docker après chaque build, scanne avec Grype, télécharge les résultats dans l’onglet Sécurité GitHub (SARIF), et attache le SBOM comme attestation de build via Sigstore/cosign. C’est le pattern production qui satisfait les exigences de documentation d’artefacts EU CRA.

name: Container SBOM & CVE Gate

on:
  push:
    branches: [main]
  pull_request:

env:
  IMAGE_NAME: my-app
  REGISTRY: ghcr.io

jobs:
  build-scan-attest:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      security-events: write
      id-token: write  # Required for OIDC token (Sigstore)

    steps:
      - uses: actions/checkout@v4

      # Build the Docker image
      - name: Build Docker image
        run: docker build -t ${{ env.IMAGE_NAME }}:${{ github.sha }} .

      # Generate SBOM with Syft (CycloneDX + SPDX)
      - name: Generate SBOM with Syft
        uses: anchore/sbom-action@v0
        with:
          image: ${{ env.IMAGE_NAME }}:${{ github.sha }}
          format: cyclonedx-json
          output-file: sbom.cdx.json
          upload-artifact: true
          artifact-name: sbom-${{ github.sha }}

      # Scan SBOM with Grype
      - name: Scan SBOM with Grype
        uses: anchore/scan-action@v4
        id: grype-scan
        with:
          sbom: sbom.cdx.json
          fail-build: true
          severity-cutoff: high
          output-format: sarif
          output-file: grype.sarif
        # Allow the step to fail but continue to upload SARIF
        continue-on-error: true

      # Upload scan results to GitHub Security tab
      - name: Upload SARIF to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: grype.sarif

      # Fail the workflow if Grype found high/critical issues
      - name: Fail if vulnerabilities found
        if: steps.grype-scan.outcome == 'failure'
        run: |
          echo "Critical or High severity CVEs found. Blocking deployment."
          exit 1

      # Push image (only on main, after CVE gate passes)
      - name: Push to GHCR
        if: github.ref == 'refs/heads/main'
        run: |
          echo "${{ secrets.GITHUB_TOKEN }}" | \
            docker login ghcr.io -u ${{ github.actor }} --password-stdin
          docker tag ${{ env.IMAGE_NAME }}:${{ github.sha }} \
            ${{ env.REGISTRY }}/${{ github.repository }}:latest
          docker push ${{ env.REGISTRY }}/${{ github.repository }}:latest

      # Attach SBOM as cosign attestation
      - name: Attest SBOM with cosign
        if: github.ref == 'refs/heads/main'
        uses: sigstore/cosign-installer@v3
        with:
          cosign-release: 'v2.4.1'
      - run: |
          cosign attest \
            --predicate sbom.cdx.json \
            --type cyclonedx \
            ${{ env.REGISTRY }}/${{ github.repository }}:latest

Validating SBOM Quality: CISA 2025 Minimum Elements Compliance

Valider la Qualité SBOM : Conformité aux Éléments Minimaux CISA 2025

A 2025 ScienceDirect study found that 12% of SBOMs analyzed in open-source projects do not comply with their corresponding standard, and only 7% report all NTIA minimum data fields. The most common failure modes are missing component hashes and absent license identifiers. The CycloneDX CLI provides a built-in schema validator:

Une étude ScienceDirect 2025 a constaté que 12% des SBOM analysés dans des projets open source ne sont pas conformes à leur standard correspondant, et seulement 7% rapportent tous les champs NTIA minimaux. Les causes d’échec les plus courantes sont les hash de composants manquants et les identifiants de licences absents. Le CLI CycloneDX fournit un validateur de schéma intégré :

# Install CycloneDX CLI
npm install -g @cyclonedx/cyclonedx-npm
# or for the standalone CLI:
# https://github.com/CycloneDX/cyclonedx-cli/releases

# Validate SBOM against CycloneDX 1.6 schema
cyclonedx validate --input-file sbom.cdx.json --input-version v1_6

# Check output (exit code 0 = valid, non-zero = schema errors)
echo "Exit code: $?"

# List the components and check for missing hashes
cat sbom.cdx.json | python3 -c "
import json, sys
sbom = json.load(sys.stdin)
components = sbom.get('components', [])
missing_hash = [c['name'] for c in components if not c.get('hashes')]
missing_license = [c['name'] for c in components if not c.get('licenses')]
print(f'Total components: {len(components)}')
print(f'Missing hashes: {len(missing_hash)} → {missing_hash[:5]}')
print(f'Missing licenses: {len(missing_license)} → {missing_license[:5]}')
"

To maximize SBOM quality from Syft, use the all-layers scope and ensure your image is built with package manifests intact (don't RUN rm -rf /var/lib/apt/lists/* before the Syft scan step — Syft needs the package database files to accurately identify installed packages):

Pour maximiser la qualité du SBOM avec Syft, utilisez le scope all-layers et assurez-vous que votre image est construite avec les manifestes de packages intacts (ne faites pas RUN rm -rf /var/lib/apt/lists/* avant l’étape de scan Syft — Syft a besoin des fichiers de base de données packages pour identifier précisément les packages installés) :

# Dockerfile best practice for SBOM-compatible images
FROM node:22-slim

# Install packages (Syft reads /var/lib/dpkg/status)
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    && rm -rf /var/lib/apt/lists/*
# Note: Syft reads the dpkg database BEFORE rm -rf — in image layers
# The scan happens against the built image, not during build

WORKDIR /app
COPY package-lock.json .
RUN npm ci --omit=dev
COPY . .

USER node
CMD ["node", "server.js"]

CycloneDX vs SPDX: The DevOps-Specific Comparison

CycloneDX vs SPDX : La Comparaison Spécifique DevOps

For container and Kubernetes workloads, CycloneDX is generally the better choice. Here's why: CycloneDX natively models VEX (Vulnerability Exploitability eXchange) documents, which allow you to declare that a given CVE is not exploitable in your specific deployment context. This is the mechanism regulators want to see for EU CRA compliance when you can prove a CVE doesn't apply. SPDX 3.0 added VEX via its security profile, but tooling maturity for this feature in SPDX remains lower than in CycloneDX.

Pour les workloads containers et Kubernetes, CycloneDX est généralement le meilleur choix. Voici pourquoi : CycloneDX modélise nativement les documents VEX (Vulnerability Exploitability eXchange), qui vous permettent de déclarer qu’un CVE donné n’est pas exploitable dans votre contexte de déploiement spécifique. C’est le mécanisme que les régulateurs veulent voir pour la conformité EU CRA quand vous pouvez prouver qu’un CVE ne s’applique pas. SPDX 3.0 a ajouté VEX via son profil de sécurité, mais la maturité des outils pour cette fonctionnalité dans SPDX reste inférieure à CycloneDX.

Both formats are accepted for EU CRA (CycloneDX 1.6+ and SPDX 3.0.1+, per German BSI TR-03183-2). If you need to deliver SBOMs to enterprise clients who specify SPDX, Syft can generate both in a single command: syft image:latest -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.json.

Les deux formats sont acceptés pour l’EU CRA (CycloneDX 1.6+ et SPDX 3.0.1+, selon le BSI allemand TR-03183-2). Si vous devez livrer des SBOM à des clients entreprise qui spécifient SPDX, Syft peut générer les deux en une seule commande : syft image:latest -o cyclonedx-json=sbom.cdx.json -o spdx-json=sbom.spdx.json.

VEX: Managing OS-Level CVE Noise in Container SBOMs

VEX : Gérer le Bruit CVE au Niveau OS dans les SBOM Containers

A full container image SBOM will typically surface dozens of OS-level CVEs in packages like curl, libssl, or libc. Many of these are unfixed (no patch available) or are in code paths never executed in your specific container configuration. Without VEX, your Grype scan will fail with dozens of findings, most of which are not actionable. VEX solves this.

Un SBOM d’image container complète va typiquement faire remonter des dizaines de CVE OS dans des packages comme curl, libssl ou libc. Beaucoup sont sans correction (aucun patch disponible) ou dans des code paths jamais exécutés dans votre configuration container spécifique. Sans VEX, votre scan Grype échouera avec des dizaines de résultats, dont la plupart ne sont pas actionnables. VEX résoud ce problème.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2023-38545",
      "source": {"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38545"},
      "affects": [{"ref": "curl-8.3.0"}],
      "analysis": {
        "state": "not_affected",
        "justification": "vulnerable_code_not_in_execute_path",
        "detail": "Container network access is restricted to internal VPC only; SOCKS5 proxy functionality is disabled at the application layer."
      }
    }
  ]
}

Valid VEX justifications under CycloneDX 1.6 : component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist. Document the justification carefully — regulators reviewing your EU CRA incident report documentation will scrutinize VEX assertions.

Justifications VEX valides sous CycloneDX 1.6 : component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist. Documentez soigneusement la justification — les régulateurs examinant votre documentation EU CRA scrutineront les assertions VEX.

Frequently Asked Questions

Questions Fréquentes