Scanner de dépendances (SCA) : guide complet 2026

Un scanner de dépendances, ou SCA (Software Composition Analysis), est un outil qui identifie automatiquement les bibliothèques et composants open source utilisés par un projet, puis vérifie chacun contre une base de vulnérabilités publiques pour détecter les CVE connues, les paquets abandonnés, les licences non conformes et les dépendances compromises. Depuis l'incident Log4Shell de décembre 2021 (CVE-2021-44228, CVSS 10.0) et l'attaque backdoor xz-utils de mars 2024 (CVE-2024-3094), le SCA est devenu un contrôle non négociable de tout pipeline moderne. Les outils gratuits (Dependabot, OSV-Scanner, Trivy, npm audit, pip-audit) couvrent les besoins de la majorité des projets ; les solutions commerciales (Snyk, JFrog Xray, Mend, Socket.dev) ajoutent reachability analysis, VEX, scoring d'exploitabilité et détection proactive de paquets suspects. Cet article détaille le fonctionnement d'un SCA, la différence avec SAST et DAST, les outils 2026, le rôle du SBOM dans la conformité US (EO 14028) et européenne (CRA), l'intégration en pipeline CI/CD et les pièges d'adoption.

Pourquoi le SCA est devenu critique en 2026

Trois évolutions structurelles imposent le SCA comme contrôle de premier ordre en 2026.

La proportion de code tiers explose. Une application web moderne contient typiquement 80 à 95 % de code open source importé, 5 à 20 % de code écrit par l'équipe. Un projet Node.js typique installe 500 à 2 000 paquets transitifs pour un unique npm install. Sans inventaire automatisé, personne ne connaît la surface réelle.

Les incidents supply chain ont démontré l'impact systémique. Log4Shell (décembre 2021) a exposé des millions de systèmes via une dépendance Java ubiquitaire (Log4j 2.x). L'attaque xz-utils (mars 2024) a injecté une backdoor dans une bibliothèque de compression présente dans quasi toutes les distributions Linux, détectée quelques semaines avant de toucher Debian et Ubuntu LTS. Chalk/debug/ua-parser-js (2021-2022) ont subi des compromissions npm temporaires. Les paquets PyTorch compromis via dependency confusion (décembre 2022) ont affecté des milliers d'installations.

La régulation rattrape le sujet. Executive Order 14028 (mai 2021) impose aux fournisseurs logiciels du gouvernement américain un SBOM livrable pour tout produit. Le Cyber Resilience Act européen (publié au JOUE en novembre 2024, applicable à partir de 2027) impose des obligations similaires pour les produits vendus en Europe, incluant gestion active des vulnérabilités de composants. DORA (janvier 2025) et NIS2 (octobre 2024) ajoutent des exigences sectorielles.

Comment fonctionne un scanner de dépendances

Le fonctionnement se décompose en quatre étapes canoniques.

1. Parsing des manifests et détection des dépendances

Le scanner lit les fichiers de déclaration de dépendances propres à chaque écosystème et reconstitue l'arbre complet incluant les dépendances transitives.

Les scanners modernes privilégient les lockfiles (qui fixent les versions exactes résolues) aux manifests (qui déclarent des plages de versions). Le parsing inclut aussi les dépendances transitives, qui représentent typiquement 90 % des paquets installés.

2. Matching avec les bases de vulnérabilités

Les bases consultées en 2026 :

• NVD (National Vulnerability Database) : référentiel historique du NIST, agrège les CVE avec métadonnées CVSS, CPE, CWE. Latence de publication parfois élevée (jours à semaines après la disclosure).
• GHSA (GitHub Security Advisories) : très réactif sur l'écosystème npm, PyPI, RubyGems, Maven. Souvent publié avant le NVD.
• OSV.dev (Google) : agrégateur universel gratuit, format OSV standardisé, couvre GHSA + PyPI Advisory + RustSec + Go vuln DB + Debian/Ubuntu + Kernel CVE.
• Snyk Intel, Mend, Sonatype OSS Index : bases commerciales souvent enrichies en avance du NVD par recherche interne.
• RustSec, Go Vuln DB, CocoaPods Advisory : bases écosystème-spécifiques.

3. Analyse de licences et policy

En parallèle du scoring sécurité, les SCA matures évaluent les licences pour détecter les incompatibilités (copyleft fort type GPL dans un produit commercial propriétaire) ou les licences non approuvées par l'entreprise.

4. Rapport et intégration

Sortie typique : rapport SARIF (Static Analysis Results Interchange Format) pour intégration CI/CD, JSON pour tooling interne, PR automatique pour suggestion de remédiation, ticket Jira ou GitLab pour suivi.

SAST vs DAST vs SCA : le tableau de référence

Confusion fréquente entre ces trois familles d'outils qui couvrent des surfaces différentes.

Règle pragmatique : un pipeline mature 2026 combine les trois. SCA est le plus facile à mettre en place (activation d'un scanner en quelques minutes), donne les gains les plus rapides, et sert de point d'entrée à la culture DevSecOps dans une équipe qui n'en a jamais eu.

Outils SCA en 2026

Trois catégories selon le budget et la maturité cible.

Outils gratuits et open source

Solutions commerciales

Ordre d'adoption pragmatique

1. Dependabot activé sur GitHub (5 minutes, gratuit, couvre 80 % des besoins de base).
2. Trivy en CI pour scanner les images Docker avant push registry.
3. OSV-Scanner ou Snyk CLI en check pre-merge pour refuser les PR introduisant des CVE critiques.
4. Dependency-Track self-hosted pour centraliser l'inventaire SBOM de tous les projets.
5. Solution commerciale quand volume ou compliance exigent reachability, VEX, et détection supply chain active.

SBOM et supply chain sécurisée

Le SBOM (Software Bill of Materials) est l'inventaire machine-readable de toutes les dépendances d'un logiciel, avec versions, fournisseurs, licences et relations. Deux formats standards.

SPDX 2.3 (ISO/IEC 5962:2021)

Format historique, maintenu par la Linux Foundation. Lisibilité humaine, riche en métadonnées de licences. Adopté par Linux distros, de nombreux gouvernements.

CycloneDX 1.5+ (OWASP)

Format moderne axé sécurité, maintenu par OWASP. Meilleure intégration avec VEX, plus compact. Adopté par le DoD US, Open Source Security Foundation (OpenSSF).

Exemple minimal CycloneDX JSON :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-04-24T08:00:00+02:00",
    "component": {
      "type": "application",
      "name": "my-app",
      "version": "2.1.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.19.2",
      "purl": "pkg:npm/express@4.19.2",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

Génération automatisée de SBOM

# Syft (Anchore) — multi-écosystème
syft packages dir:./my-project -o cyclonedx-json=sbom.cyclonedx.json
syft packages docker:my-image:latest -o spdx-json=sbom.spdx.json
 
# Trivy (Aqua) — depuis image OCI ou filesystem
trivy image --format cyclonedx --output sbom.json my-image:latest
trivy fs --format spdx-json --output sbom.spdx.json ./my-project
 
# Node.js : @cyclonedx/cyclonedx-npm
npx @cyclonedx/cyclonedx-npm --output-file sbom.json
 
# Python : cyclonedx-python
cyclonedx-py poetry -o sbom.cyclonedx.json

VEX : compléter le SBOM avec l'exploitabilité

VEX (Vulnerability Exploitability eXchange) documente formellement si une CVE détectée dans le SBOM est effectivement exploitable dans le contexte de l'application. Réduit le bruit et les faux positifs.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2021-44228",
      "affects": [
        { "ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1" }
      ],
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "response": ["will_not_fix"],
        "detail": "Le code vulnérable JndiLookup n'est jamais appelé dans notre application. Confirmé via analyse de reachability Snyk."
      }
    }
  ]
}

Intégration en pipeline CI/CD

Le SCA ne délivre sa valeur qu'intégré aux processus de build et déploiement.

GitHub Actions exemple

name: SCA checks
on: [pull_request, push]
 
jobs:
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Run OSV-Scanner
        uses: google/osv-scanner-action/osv-scanner-action@v1
        with:
          scan-args: |-
            --recursive
            --skip-git
            ./
 
      - name: Run Trivy on filesystem
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          severity: CRITICAL,HIGH
          exit-code: 1
 
      - name: Generate SBOM with Syft
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.cyclonedx.json
 
      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cyclonedx.json

GitLab CI exemple

sca-check:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
    - trivy fs --format cyclonedx --output sbom.json .
  artifacts:
    paths:
      - sbom.json
    expire_in: 30 days

Politique de break-the-build

Trois niveaux à définir dans la politique d'équipe :

1. Bloquant : CVE critique (CVSS 9.0+) avec code reachable. La PR ne peut pas être mergée.
2. Avertissement : CVE haute ou médium, sans reachability confirmée. Review obligatoire, pas de blocage automatique.
3. Information : CVE faible, dépendances à update sous 30 jours. Issue automatique créée.

Pièges d'adoption et fausses alertes

Cinq écueils fréquents dans les déploiements SCA observés en France.

Noise fatigue

Un projet Node.js typique remonte 50 à 300 CVE lors du premier scan. L'équipe se désensibilise en quelques semaines si aucun mécanisme de priorisation n'est en place. Solution : activer d'emblée le scoring d'exploitabilité (Snyk Priority Score, Socket's Risk Score, EPSS), filtrer par reachability, et mettre en place une revue hebdomadaire plutôt qu'une notification par CVE.

Absence de remédiation

Les CVE sont remontées mais jamais corrigées. Le pipeline devient un dashboard permanent rouge que personne ne regarde. Solution : SLA explicite par criticité (CVSS 9.0+ sous 7 jours, 7.0-8.9 sous 30 jours, 4.0-6.9 sous 90 jours), intégration Jira ou GitLab issues, revue mensuelle en rituel équipe.

Configuration par défaut insuffisante

Dependabot default ne scanne que certains manifests et peut manquer les sous-projets. Solution : auditer la couverture effective via dependabot.yml explicite, ajouter les ecosystems manquants (docker, gitsubmodule, github-actions).

Dépendances abandonnées

Un paquet avec dernière release il y a 4 ans, un maintainer inactif, 3 issues ouvertes critiques. Les scanners SCA classiques ne remontent pas cette classe. Solution : outils dédiés (Socket.dev, Tidelift, Scorecard de OpenSSF) qui évaluent la santé du projet amont.

Oubli des transitives

Beaucoup d'équipes surveillent les dépendances directes (déclarées dans package.json) mais ignorent les transitives (imports par les dépendances). En pratique, 80 % des CVE critiques viennent des transitives. Solution : forcer le scan récursif sur le lockfile complet.

Points clés à retenir

• Le SCA (Software Composition Analysis) analyse les dépendances open source d'une application contre les bases CVE et les règles de licences. Complémentaire de SAST (code) et DAST (runtime).
• 80 à 95 % du code d'une application moderne vient de l'open source. Sans SCA, l'inventaire de la surface réelle est impossible.
• Dependabot gratuit couvre les besoins de base. Trivy, OSV-Scanner et Grype complètent pour containers et formats spécifiques. Snyk, Socket.dev et Endor Labs ajoutent reachability, VEX et détection supply chain active.
• Le SBOM (SPDX 2.3, CycloneDX 1.5+) est l'inventaire machine-readable des dépendances. Obligatoire US (EO 14028) et européen (CRA 2027) pour les fournisseurs logiciels.
• L'adoption échoue par noise fatigue ou absence de remédiation. Priorisation par exploitabilité, SLA par criticité et intégration aux rituels équipe sont les conditions de réussite.

Pour aller plus loin

• Injection SQL : fonctionnement, types et défenses - classe de vulnérabilité souvent introduite par dépendances tierces mal maintenues.
• Sécurité des uploads de fichiers - autre surface critique AppSec moderne.
• Roadmap secure coding - intégrer SCA dans une pratique dev quotidienne.
• SAST vs DAST - comparer avec les autres approches d'analyse automatisée.