SCA : analyser les vulnérabilités des dépendances

En décembre 2021, une vulnérabilité critique est découverte dans Log4j, une bibliothèque de logging Java utilisée par des millions d’applications. En quelques heures, des attaquants exploitent déjà la faille. Les équipes qui n’avaient aucune visibilité sur leurs dépendances ont mis des semaines à identifier tous les projets impactés.

Cette histoire illustre un problème fondamental : une application moderne repose sur des centaines de dépendances, chacune pouvant contenir des vulnérabilités. Sans outil pour les inventorier et les surveiller, vous naviguez à l’aveugle.

Qu’est-ce que le SCA ?

Le SCA (Software Composition Analysis) désigne l’ensemble des techniques et outils qui analysent les composants tiers d’une application : bibliothèques, frameworks, packages installés via npm, pip, Maven, Go modules, etc.

L’objectif est triple :

• Inventorier toutes les dépendances (directes et transitives)
• Identifier les vulnérabilités connues (CVE) dans ces composants
• Alerter quand une nouvelle faille est publiée

Le SCA répond à une question simple : “Quelles bibliothèques externes utilise mon application, et sont-elles sûres ?”

SCA vs SAST : quelle différence ?

Ces deux approches sont complémentaires mais distinctes :

Aspect	SAST	SCA
Cible	Code écrit par l’équipe	Code externe (dépendances)
Analyse	Patterns de vulnérabilités	Base de données CVE
Détection	Failles introduites par les développeurs	Failles héritées des bibliothèques
Exemple	Injection SQL dans votre code	CVE dans une version de lodash

Glissez pour voir

Un projet peut avoir un code irréprochable et pourtant être vulnérable à cause d’une dépendance non mise à jour. Le SCA couvre cette surface d’attaque.

Pourquoi le SCA est devenu indispensable

L’explosion des dépendances

Une application moderne tire en moyenne :

• JavaScript : 300 à 1500 dépendances (transitives incluses)
• Python : 50 à 300 dépendances
• Java : 100 à 500 dépendances

Ces chiffres incluent les dépendances transitives : les bibliothèques que vos bibliothèques utilisent. Vous installez express ? Vous embarquez aussi ses 30+ dépendances. Chacune est un vecteur potentiel de vulnérabilité.

Des CVE publiées en continu

En 2024, plus de 30 000 CVE ont été publiées, soit environ 80 par jour. Une partie concerne les bibliothèques open source. Sans surveillance automatisée, il est impossible de suivre le rythme.

Comprendre les CVE

Une CVE (Common Vulnerabilities and Exposures) est un identifiant unique pour une faille de sécurité. Chaque CVE possède un score CVSS qui évalue sa gravité. Pour approfondir : Guide CVE, CVSS et EPSS

Qui doit se préoccuper du SCA ?

Profil	Responsabilité	Action type
Développeur	Choisir des dépendances saines, mettre à jour	Scanner avant merge
DevOps/SRE	Intégrer les scans dans la CI/CD	Bloquer les builds vulnérables
DevSecOps	Définir les seuils, gérer les exceptions	Configurer les policies
RSSI	Conformité, reporting, gouvernance	Exiger un inventaire (SBOM)
Juridique	Licences open source	Auditer les licences

Glissez pour voir

Comment fonctionne un scanner SCA

Un outil SCA suit un processus en quatre étapes :

1. Extraction de l’inventaire

   Le scanner parcourt les fichiers de dépendances de votre projet :

   • package-lock.json / yarn.lock (JavaScript)
   • requirements.txt / poetry.lock (Python)
   • pom.xml / build.gradle (Java)
   • go.sum (Go)
   • Cargo.lock (Rust)

   Il en extrait la liste complète des packages avec leurs versions exactes.

2. Résolution des dépendances transitives

   Pour chaque dépendance directe, le scanner identifie ses propres dépendances. Un package.json avec 10 dépendances peut générer un arbre de 500 packages.

3. Consultation des bases de vulnérabilités

   Le scanner compare chaque couple (package, version) aux bases de données CVE :

   • NVD (National Vulnerability Database) — base officielle NIST
   • GitHub Advisory Database — CVE + advisories GitHub
   • OSV (Open Source Vulnerabilities) — base Google unifiée
   • Bases spécialisées (npm, PyPI, RubyGems advisory databases)

4. Génération du rapport

   Le scanner produit une liste des vulnérabilités trouvées avec :

   • Identifiant CVE
   • Score CVSS (gravité)
   • Package et version affectés
   • Version corrigée (si disponible)
   • Description et références

Exemple concret

Vous avez cette dépendance dans votre package.json :

{
  "dependencies": {
    "lodash": "4.17.20"
  }
}

Le scanner SCA détecte que lodash@4.17.20 est vulnérable à CVE-2021-23337 (injection de prototype, score CVSS 7.2). La version corrigée est 4.17.21.

Le rapport indique :

CRITICAL lodash 4.17.20
  CVE-2021-23337 - Prototype Pollution
  Fixed in: 4.17.21
  https://nvd.nist.gov/vuln/detail/CVE-2021-23337

Dépendances directes vs transitives

C’est un concept fondamental du SCA.

Dépendance directe : package que vous installez explicitement (npm install express).

Dépendance transitive : package installé automatiquement parce qu’une de vos dépendances en a besoin.

votre-app
├── express (directe)
│   ├── body-parser (transitive)
│   │   └── raw-body (transitive niveau 2)
│   └── cookie (transitive)
└── lodash (directe)

Le problème ? 80% des vulnérabilités se trouvent dans les dépendances transitives. Vous n’avez pas choisi ces packages, vous ne savez même pas qu’ils sont là, mais ils font partie de votre surface d’attaque.

C’est pourquoi les scanners SCA analysent l’arbre complet des dépendances, pas seulement le package.json.

Intégration dans le pipeline CI/CD

Un scan SCA efficace s’exécute à plusieurs moments :

En local (avant commit)

Le développeur scanne avant de pousser son code :

# Avec Trivy
trivy fs --scanners vuln .

# Avec Grype
grype dir:.

À chaque pull request

Le pipeline CI bloque la PR si des vulnérabilités critiques sont détectées :

GitHub Actions

name: Security Scan
on: pull_request

jobs:
  sca:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - name: Run Trivy SCA scan
        uses: aquasecurity/trivy-action@6c175e9c4083a92bbca2f9724c8a5e33bc2d97a5 # 0.30.0
        with:
          scan-type: 'fs'
          scanners: 'vuln'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

GitLab CI

sca_scan:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy fs --scanners vuln --severity CRITICAL,HIGH --exit-code 1 .
  allow_failure: false

Sur les images conteneur

Le scan SCA s’applique aussi aux images Docker qui embarquent des dépendances :

# Scanner une image pour ses vulnérabilités
trivy image mon-app:latest

# Grype sur une image
grype mon-app:latest

Surveillance continue

Les CVE apparaissent après le déploiement. Une image saine aujourd’hui peut devenir vulnérable demain. La surveillance continue alerte quand une nouvelle CVE affecte vos dépendances en production.

Des outils comme Dependency-Track ingèrent vos SBOM et surveillent les nouvelles publications CVE.

Outils SCA recommandés

Trivy Scanner polyvalent : dépendances, images, IaC. Gratuit et rapide.

Grype Scanner de vulnérabilités spécialisé, excellent pour les images et SBOM.

Dependency-Track Plateforme de gestion continue des vulnérabilités avec ingestion SBOM.

Comparatif rapide

Outil	Type	Points forts	Cas d’usage
Trivy	CLI / CI	Polyvalent, rapide, gratuit	Scan CI/CD universel
Grype	CLI / CI	Précis, compatible Syft	Scan images + SBOM
Dependency-Track	Plateforme	Gestion continue, dashboard	Gouvernance entreprise
Snyk	SaaS	Intégrations riches, fix auto	Équipes avec budget
OWASP Dependency-Check	CLI	Mature, Java-friendly	Projets Java/Maven

Glissez pour voir

Bonnes pratiques

Définir des seuils de blocage réalistes

Bloquer sur toutes les CVE paralyse les équipes. Bloquer sur aucune revient à ne pas scanner. Un bon compromis :

• Bloquer : CRITICAL et HIGH sans correctif disponible
• Alerter : HIGH avec correctif, MEDIUM
• Accepter : LOW (après analyse)

Maintenir un processus d’exception

Certaines CVE ne s’appliquent pas à votre contexte (fonction non utilisée, environnement non exposé). Documentez les exceptions avec :

• Justification technique
• Date de revue
• Responsable

Mettre à jour régulièrement

La meilleure défense reste la mise à jour. Automatisez avec Dependabot, Renovate ou Mend pour recevoir des PR de mise à jour.

Générer un SBOM

Un SBOM (Software Bill of Materials) est l’inventaire de vos composants. Il permet la surveillance continue et répond aux exigences de conformité (NIS2, CRA, contrats clients).

→ Guide SBOM

Ne pas ignorer les dépendances de développement

Les devDependencies (npm) ou extras (pip) font partie du build. Une faille dans un outil de test peut compromettre votre pipeline CI/CD.

Limites du SCA

Le SCA n’est pas une solution miracle :

• Faux positifs : une CVE peut ne pas s’appliquer à votre usage
• Faux négatifs : les CVE non publiées (0-day) ne sont pas détectées
• Délai : entre la découverte d’une faille et sa publication CVE
• Couverture : certains écosystèmes sont mieux couverts que d’autres

Le SCA complète le SAST (code maison) et le DAST (tests dynamiques) pour une couverture complète.

Pour aller plus loin

• Comprendre les CVE, CVSS et EPSS — Interpréter les scores de gravité
• Trivy — Guide complet du scanner polyvalent
• Grype — Scanner de vulnérabilités Anchore
• Dependency-Track — Plateforme de gestion continue
• SBOM — Générer et exploiter un inventaire logiciel
• Supply chain — Sécuriser la chaîne d’approvisionnement logicielle

×

📖 Voir la documentation →