reviewing-dependencies

Flux de travail de vulnérabilité de dépendance

Étape 1 : Rassembler les alertes

# Lister toutes les alertes Dependabot ouvertes triées par sévérité
gh api /repos/{owner}/{repo}/dependabot/alerts --jq '.[] | select(.state == "open") | {number, severity: .security_vulnerability.severity, package: .security_vulnerability.package.name, ecosystem: .security_vulnerability.package.ecosystem, summary: .security_advisory.summary}'

# Filtrer par sévérité
gh api "/repos/{owner}/{repo}/dependabot/alerts?severity=critical&state=open"

# Obtenir les détails complets pour une alerte spécifique
gh api /repos/{owner}/{repo}/dependabot/alerts/{alert_number}

Étape 2 : Évaluer l'impact

Pour chaque alerte, déterminez :

1. Le chemin de code vulnérable est-il accessible ? — L'application utilise-t-elle réellement la fonction/fonctionnalité vulnérable de la dépendance ?
2. S'agit-il d'une dépendance directe ou transitive ? — Les vulnérabilités transitives peuvent être plus difficiles à corriger mais posent un risque réel.
3. Quel est le score CVSS et la disponibilité d'exploit ? — Un score CVSS élevé avec un exploit public nécessite une action immédiate. Un CVSS moyen sans exploit connu peut être planifié.
4. Quelles versions sont affectées et quelles versions le corrigent ? — Vérifiez si la mise à jour est un changement mineur ou une modification majeure.

Étape 3 : Décider de l'action

Risque de dépendance transitive

Les dépendances directes sont visibles dans les fichiers package.json ou .csproj, mais les dépendances transitives (dépendances des dépendances) constituent la majorité de l'arbre de dépendances et sont souvent invisibles.

Pourquoi les dépendances transitives sont importantes :

• Une vulnérabilité dans une dépendance imbriquée est tout aussi exploitable qu'une vulnérabilité dans une dépendance directe
• Les dépendances transitives sont moins susceptibles d'être activement surveillées
• La mise à jour d'une dépendance transitive peut nécessiter de mettre à jour la dépendance directe qui l'importe

Comment enquêter :

# npm : Afficher l'arbre de dépendances complet
npm ls --all

# npm : Trouver quelle dépendance directe importe une transitive vulnérable
npm ls <vulnerable-package>

# .NET : Lister tous les packages vulnérables incluant les transitifs
dotnet list package --vulnerable --include-transitive

# .NET : Afficher le graphique de dépendances
dotnet list package --include-transitive

Évaluation de la santé des dépendances

Lors de l'évaluation de l'adoption ou du maintien d'une dépendance, évaluez :

Intégration Grype

Grype analyse les images conteneur et les systèmes de fichiers pour détecter les vulnérabilités connues :

# Analyser une image conteneur
grype <image>:<tag>

# Analyser un répertoire
grype dir:/path/to/project

# Sortie en JSON pour traitement programmatique
grype <image> -o json

# Filtrer par sévérité
grype <image> --only-fixed --fail-on high

Interpréter la sortie de Grype :

• Chaque résultat inclut : CVE ID, sévérité, nom du package, version installée, version corrigée
• La colonne Fixed indique si une mise à jour est disponible
• Utilisez --only-fixed pour vous concentrer sur les éléments actionnables (vulnérabilités avec correctifs disponibles)

Conseils spécifiques à la plateforme

NuGet (.NET)

# Vérifier les packages vulnérables
dotnet list package --vulnerable

# Inclure les dépendances transitives
dotnet list package --vulnerable --include-transitive

# Vérifier les packages obsolètes
dotnet list package --outdated

Préoccupations spécifiques à NuGet :

• Les packages .NET framework peuvent avoir des profils de vulnérabilité différents de .NET Core
• PackageReference dans .csproj est préféré à packages.config pour une meilleure résolution transitive
• Utilisez Directory.Packages.props pour la gestion des versions centralisée dans les solutions multi-projets

npm (Node.js)

# Exécuter l'audit de sécurité
npm audit

# Corriger automatiquement où possible
npm audit fix

# Forcer les corrections (peut introduire des changements cassants)
npm audit fix --force

# Vérifier l'intégrité du lockfile
npm ci  # Installe exactement depuis le lockfile, échoue si le lockfile est à jour

Préoccupations spécifiques à npm :

• package-lock.json doit être commité et maintenu synchronisé
• Utilisez overrides dans package.json pour forcer les versions de dépendances transitives :

  {
    "overrides": {
      "vulnerable-package": ">=2.0.0"
    }
  }

• Méfiez-vous des scripts postinstall dans les dépendances — ils exécutent du code arbitraire lors de npm install

Concepts SBOM

Une Software Bill of Materials (SBOM) est un inventaire de tous les composants dans un artefact logiciel. Comprendre les SBOM aide à raisonner sur le risque de supply chain :

• Ce qu'elle contient : Noms de packages, versions, licences, relations (directes vs. transitives)
• Pourquoi c'est important : Permet une réponse rapide quand une nouvelle CVE est publiée — identifier immédiatement les projets affectés
• Formats standards : SPDX, CycloneDX
• Intégration GitHub : GitHub génère automatiquement les graphiques de dépendances ; Dependabot l'utilise pour les alertes

Règles critiques

• Ne jamais ignorer les alertes Dependabot critiques/élevées sans justification documentée. Même si le chemin de code vulnérable semble inaccessible, documentez pourquoi.
• Préférez la mise à jour à l'épinglage. Épingler une version vulnérable et ajouter une contournement accumule de la dette technique. Mettez à jour quand un correctif est disponible.
• Évaluez l'arbre transitive complet. Une dépendance directe peut être sûre, mais ses dépendances transitives peuvent ne pas l'être.
• Passez en revue les nouvelles dépendances avant adoption. Vérifiez les critères de santé ci-dessus avant d'ajouter un nouveau package. Plus de dépendances = plus de surface d'attaque.
• Verrouillez les dépendances. Commettez toujours les lockfiles (package-lock.json, packages.lock.json). Utilisez npm ci en CI/CD, pas npm install.