SCA et SBOM : analyse composition logicielle en CI/CD 2026

En juillet 2021, la vulnérabilité Log4Shell a révélé un problème systémique : des milliers d'organisations utilisaient une bibliothèque Java tierce (Log4j) dans leurs applications sans même le savoir, parce qu'elle était une dépendance transitive d'une autre dépendance. En 2024, la backdoor XZ Utils a montré qu'un acteur étatique pouvait compromettre une bibliothèque open source utilisée dans la quasi-totalité des distributions Linux. Ces incidents ont transformé la gestion des dépendances logicielles en enjeu de sécurité national. L'analyse de composition logicielle (SCA) et le Software Bill of Materials (SBOM) sont désormais les outils de référence pour cartographier, surveiller et sécuriser les composants tiers intégrés dans vos applications. En 2026, ils ne sont plus optionnels : le Cyber Resilience Act européen, les recommandations NIS 2 et l'Executive Order américain de 2021 les imposent progressivement aux éditeurs logiciels et aux opérateurs d'infrastructures critiques. Ce guide vous explique comment intégrer SCA et SBOM dans votre pipeline CI/CD de manière opérationnelle.

Pourquoi SCA est indispensable : la crise des dépendances

Une application moderne moyenne embarque entre 500 et 2 000 dépendances directes et transitives. Une application Node.js avec 50 dépendances directes peut en réalité embarquer 800 packages npm. Une application Java Spring Boot standard inclut des centaines de JARs. Dans cet écosystème complexe, une seule bibliothèque vulnérable peut compromettre toute l'application.

Les incidents qui ont tout changé

Log4Shell (CVE-2021-44228) : une vulnérabilité de type RCE (Remote Code Execution) dans Apache Log4j, une bibliothèque de logging Java présente dans des millions d'applications commerciales et open source. La surface d'attaque était invisible pour la plupart des équipes car Log4j était une dépendance de 3ème ou 4ème niveau. Score CVSS : 10.0/10.

XZ Utils backdoor (CVE-2024-3094) : une porte dérobée soigneusement insérée sur 2 ans dans la bibliothèque de compression XZ Utils par un acteur étatique présumé, ciblant le processus d'authentification SSH sur les systèmes Linux. Détectée de justesse par un ingénieur Microsoft avant une distribution massive. Illustration d'une attaque supply chain sophistiquée.

Attaques PyPI supply chain : dépôt de packages malveillants sur PyPI imitant des packages populaires (typosquatting : reqeusts au lieu de requests, colourama au lieu de colorama). Ces packages volent des credentials ou installent des backdoors. Notre analyse des attaques supply chain 2026 détaille ces vecteurs.

SCA (Software Composition Analysis) : définition et périmètre

Le SCA est la pratique qui consiste à analyser automatiquement les composants open source (et parfois commerciaux) intégrés dans une application pour détecter :

• Vulnérabilités connues : référencées dans des bases CVE (NVD, GitHub Advisory Database, OSV) avec leur score CVSS et leur exploitabilité réelle (EPSS).
• Problèmes de licence : utilisation de composants GPL dans un produit commercial propriétaire (contamination copyleft), licences interdites par la politique interne.
• Dépendances transitives : les dépendances de vos dépendances — souvent la source principale des vulnérabilités non détectées.
• Composants obsolètes : bibliothèques sans maintenance active depuis plus de 2 ans, composants dépréciés par leurs auteurs.

Le SCA ne remplace pas le SAST (analyse statique de code) ni le DAST (tests dynamiques) — il les complète. Un pipeline DevSecOps mature intègre les trois. Notre article sur le pipeline CI/CD SAST/DAST/SCA positionne le SCA dans le cadre global.

SBOM (Software Bill of Materials) : inventaire structuré

Un SBOM est un inventaire machine-readable de tous les composants logiciels d'une application — nom, version, fournisseur, licence, hash de vérification, relations entre composants. C'est le "bordereau de composition" du logiciel, analogue à la liste d'ingrédients d'un produit alimentaire.

Formats SBOM : SPDX vs CycloneDX

SPDX (Software Package Data Exchange) est le standard ISO/IEC 5962:2021 porté par la Linux Foundation. Il est particulièrement complet pour la gestion des licences et la compliance légale. Le format JSON SPDX v2.3 est le plus utilisé.

CycloneDX est le standard OWASP, conçu spécifiquement pour la sécurité applicative. Il supporte des extensions pour les vulnérabilités (BOM-Link), les services (API dependencies), les conteneurs et les fichiers. CycloneDX est préféré dans les contextes DevSecOps car il intègre nativement les informations de vulnérabilités et le VEX (voir plus bas).

Les deux formats coexistent et sont souvent générés conjointement. La plupart des outils modernes (Syft, Trivy) supportent les deux. Pour la conformité Cyber Resilience Act, l'ENISA accepte les deux formats.

Champs obligatoires d'un SBOM (NTIA minimum elements)

La NTIA américaine a défini les éléments minimaux d'un SBOM : nom du composant, fournisseur, version, identifiants uniques (PURL, CPE), relations de dépendance, auteur du SBOM, horodatage. Un SBOM sans PURL (Package URL) est difficile à consommer automatiquement par les outils de scan.

Réglementation SBOM : ce qui est imposé en 2026

Le cadre réglementaire SBOM se durcit des deux côtés de l'Atlantique :

• Executive Order US 14028 (2021) : impose un SBOM à tous les fournisseurs de logiciels vendant au gouvernement américain. Les agences fédérales doivent exiger et consommer les SBOM. Le NIST a publié des lignes directrices détaillées (NIST SP 800-218).
• Cyber Resilience Act EU (2026) : règlement européen imposant des exigences de sécurité aux produits avec éléments numériques. Exige un SBOM pour les produits de classe 1 et 2 (composants critiques). Applicable progressivement à partir de 2027 mais préparation requise dès 2026.
• NIS 2 : recommande fortement la gestion des dépendances dans les mesures de gestion des risques (article 21). Un SBOM est une preuve de diligence acceptable pour les audits NIS 2. Notre article sur le DevSecOps et pipeline CI/CD sécurisé intègre ces exigences.

Outils SCA open source : comparatif

OWASP Dependency-Check

L'outil de référence open source pour Java, .NET, JavaScript et Python. Il télécharge la NVD (National Vulnerability Database) en local et compare vos dépendances. Intégration Maven, Gradle, Jenkins, GitLab CI native. Limitation : taux de faux positifs élevé sur certains ecosystèmes (npm), analyse des dépendances transitives moins précise que les outils plus récents.

# Scan d'un projet Maven avec OWASP Dependency-Check
dependency-check --project "mon-projet"   --scan ./target/   --format HTML   --format JSON   --out ./reports/   --failOnCVSS 7

Syft + Grype (Anchore)

Syft génère un SBOM (formats SPDX, CycloneDX, Syft-JSON) à partir d'un répertoire, d'une image Docker ou d'un fichier de lock. Grype consomme ce SBOM et le compare aux bases CVE. Excellent support multi-langages (Go, Rust, Ruby, PHP en plus des standards). Très performant dans les pipelines CI.

# Générer un SBOM avec Syft
syft dir:./mon-projet -o cyclonedx-json > sbom.json

# Scanner le SBOM avec Grype
grype sbom:./sbom.json --fail-on critical

Trivy (Aqua Security)

Trivy est l'outil le plus polyvalent du marché open source : il scanne les images Docker, les dépôts Git, les filesystems, les configurations IaC (Terraform, Kubernetes) et génère des SBOM. Mise à jour quotidienne de la base de vulnérabilités. C'est aujourd'hui l'outil recommandé pour une intégration simple dans un pipeline GitHub Actions ou GitLab CI.

# SCA sur un projet local avec Trivy
trivy fs --security-checks vuln,license   --exit-code 1   --severity CRITICAL,HIGH   --format cyclonedx   --output sbom-trivy.json   ./mon-projet/

# Scan d'une image Docker
trivy image --severity CRITICAL --exit-code 1 mon-image:latest

Outils SCA commerciaux

Snyk Open Source est le leader commercial SCA pour les développeurs. Interface développeur-friendly, fix PR automatiques (Snyk ouvre automatiquement une PR avec la version corrigée), base de vulnérabilités propriétaire plus riche que la NVD. Tier gratuit disponible pour les projets open source.

GitHub Advanced Security (GHAS) intègre le SCA via Dependabot Alerts (nativement dans GitHub) et CodeQL. Dependabot crée automatiquement des PR de mise à jour pour les dépendances vulnérables. Très adapté aux organisations full-GitHub.

JFrog Xray est intégré à la plateforme Artifactory (binary repository) et scanne les artefacts à chaque publication. Particulièrement adapté aux environnements Java/Maven avec gestion fine des politiques de blocage.

Mend (ex-WhiteSource) se distingue par sa gestion des licences très avancée et son support des politiques d'entreprise complexes (ex : GPL autorisé uniquement pour les projets internes).

Intégration CI/CD : pipeline pratique avec GitHub Actions

name: SCA Security Scan

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  sca-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Trivy SCA scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          exit-code: '1'
          ignore-unfixed: true
          severity: 'CRITICAL,HIGH'
          security-checks: 'vuln,license'
          format: 'cyclonedx'
          output: 'sbom.json'

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: sbom-cyclonedx
          path: sbom.json

      - name: Check for GPL licenses
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          security-checks: 'license'
          license-full: true
          ignored-unfixed: true
          exit-code: '1'
          severity: 'CRITICAL'  # GPL-2.0, GPL-3.0 marqués CRITICAL

Le exit-code: '1' fait échouer le pipeline si des vulnérabilités CRITICAL sont trouvées, bloquant le merge vers main. Le SBOM est conservé comme artefact de build pour traçabilité.

Gestion des licences : contamination GPL et politique d'entreprise

Les licences copyleft (GPL-2.0, GPL-3.0, AGPL-3.0) imposent que tout code combiné avec une bibliothèque GPL soit lui-même distribué sous GPL — la « contamination copyleft ». Pour un éditeur de logiciel propriétaire, intégrer par erreur une dépendance GPL peut imposer la publication du code source.

La politique standard en entreprise :

• Autorisées sans restriction : MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC.
• Autorisées avec avis : LGPL (bibliothèques dynamiquement liées), MPL-2.0.
• Interdites en produit commercial : GPL-2.0, GPL-3.0, AGPL-3.0.
• Cas par cas : Creative Commons (selon la variante), licences commerciales restrictives.

FOSSA est l'outil commercial leader pour la gestion des licences dans les grandes organisations. Trivy et Snyk intègrent une gestion basique des licences suffisante pour la plupart des PME.

VEX (Vulnerability Exploitability eXchange)

VEX est un format de document (supporté par CycloneDX et CSAF 2.0) qui permet à un éditeur ou une équipe sécurité de qualifier l'exploitabilité réelle d'une vulnérabilité dans leur contexte spécifique. Il répond au problème du bruit dans les résultats SCA : une CVE sur une dépendance peut être non exploitable si le code vulnérable n'est jamais appelé par votre application.

Statuts VEX possibles : not_affected (CVE présente mais non exploitable), affected (vulnérable et exposé), fixed (version corrigée déployée), under_investigation. Un document VEX réduit considérablement le travail de triage en contexte réglementaire (Cyber Resilience Act) où les acheteurs exigent des preuves de qualification des vulnérabilités. Les ressources de la NTIA sur le SBOM détaillent le lien entre SBOM et VEX.

Remédiation : priorisation EPSS + CVSS

Un scan SCA typique génère des dizaines voire des centaines d'alertes. Toutes ne méritent pas une action immédiate. La priorisation combine deux scores :

• CVSS (Common Vulnerability Scoring System) : mesure la sévérité théorique (0-10). CRITICAL ≥ 9.0, HIGH 7.0-8.9.
• EPSS (Exploit Prediction Scoring System) : probabilité qu'une CVE soit exploitée dans les 30 jours (0-1). Une CVE CVSS 7.5 avec EPSS 0.85 est plus urgente qu'une CVE CVSS 9.8 avec EPSS 0.01.

Processus recommandé :

1. Bloquer le CI : CVSS CRITICAL + EPSS > 0.5 → fix obligatoire avant merge.
2. Alerte prioritaire : CVSS HIGH + EPSS > 0.3 → fix dans les 7 jours.
3. Backlog : reste → fix lors du prochain sprint dédié dépendances.

La stratégie de remédiation : mise à jour de version (solution la plus propre), fork et patch local (si pas de version corrigée disponible), remplacement par une bibliothèque alternative (si la dépendance est abandonnée).

Checklist SCA en 15 points pour un DevSecOps mature

1. Outil SCA intégré dans chaque pipeline CI (Trivy, Grype ou Snyk).
2. Scan SCA déclenché à chaque PR et chaque push sur les branches protégées.
3. Exit code 1 sur CRITICAL non patchées (bloque le merge).
4. SBOM généré et archivé à chaque build de release (CycloneDX ou SPDX).
5. SBOM signé avec Cosign pour garantir l'intégrité.
6. Scan de licences avec politique accept/deny formalisée.
7. Base de vulnérabilités mise à jour quotidiennement (auto-update Trivy DB).
8. Faux positifs documentés dans un fichier .trivyignore ou .grypeconfig avec justification.
9. Dépendances transitives incluses dans le scan (pas seulement directes).
10. Scan des images Docker en plus du code source.
11. Priorisation EPSS activée pour le triage des alertes.
12. SLA remédiation défini : CRITICAL sous 24h, HIGH sous 7 jours, MEDIUM sous 30 jours.
13. Dependabot ou Renovate configuré pour les PR de mise à jour automatique.
14. Formation développeurs sur la sécurité des dépendances (au moins annuelle).
15. Revue mensuelle du SBOM pour détecter les composants abandonnés.

FAQ — Questions fréquentes

Quelle est la différence entre SAST et SCA ?

Le SAST (Static Application Security Testing) analyse le code source que VOUS avez écrit pour détecter des failles (injections SQL, XSS, gestion mémoire). Le SCA analyse les bibliothèques TIERCES que vous consommez pour détecter des CVE connues et des problèmes de licence. Les deux sont complémentaires et doivent coexister dans un pipeline DevSecOps. Un SAST trouvera une injection SQL dans votre code PHP ; un SCA trouvera que la version de Symfony que vous utilisez est vulnérable à une CVE critique. Notre guide sur le empoisonnement de modèles et supply chain IA étend cette problématique à l'écosystème ML/Python.

Mon équipe est petite — quel outil SCA commencer à utiliser ?

Pour une petite équipe, commencez par Trivy (open source, zéro configuration, multiécosystème) ou Dependabot si vous êtes sur GitHub (déjà intégré, gratuit, crée des PR automatiques). Ces deux outils couvrent 80 % du besoin avec un effort minimal. L'intégration dans GitHub Actions ou GitLab CI prend moins d'une heure. Évitez de commencer avec un outil commercial complexe si vous n'avez pas encore les processus de remédiation en place — le risque est de générer du bruit sans capacité d'action. Progressez vers OWASP Dependency-Check ou Snyk quand votre maturité augmente.

Le SBOM est-il obligatoire pour mon entreprise en 2026 ?

En France et en Europe, le SBOM n'est pas encore légalement obligatoire pour toutes les entreprises en 2026. Cependant, si vous vendez des logiciels à des clients américains (US Federal), vous êtes soumis à l'Executive Order 14028 qui impose le SBOM. Le Cyber Resilience Act européen, applicable progressivement à partir de 2027, imposera le SBOM aux produits avec éléments numériques (classe 1 et 2). Si vous êtes éditeur logiciel ciblant les grands comptes ou les marchés publics, anticiper dès maintenant vous donnera un avantage concurrentiel et simplifiera la mise en conformité ultérieure. Les clients ETI et grands groupes commencent à inclure des clauses SBOM dans leurs contrats fournisseurs.