Interpréter les alertes à partir des outils de scanneur

11 minutes

Les outils d’analyse de composition logicielle génèrent de nombreuses alertes sur les vulnérabilités, les problèmes de licence et les problèmes de qualité du code dans les dépendances. L’interprétation efficace de ces alertes nécessite de comprendre les scores de gravité, d’évaluer l’exploitabilité, de gérer les faux positifs et de hiérarchiser les efforts de correction en fonction du risque réel pour vos applications. Sans interprétation et hiérarchisation appropriées, les équipes font face à la fatigue des alertes et perdent du temps sur les problèmes à faible impact tout en manquant des vulnérabilités critiques.

Présentation de la gravité des vulnérabilités

Les scores de gravité des vulnérabilités fournissent des évaluations standardisées des risques :

Système de scoring CVSS

Common Vulnerability Scoring System (CVSS) fournit des scores numériques standardisés indiquant la gravité des vulnérabilités.

Catégories de métriques CVSS :

Métriques de base : Caractéristiques de vulnérabilité intrinsèques indépendantes d’environnements spécifiques.
Métriques temporelles : Caractéristiques de vulnérabilité qui changent au fil du temps (exploitation de la disponibilité, disponibilité des correctifs, confiance).
Métriques environnementales : Caractéristiques de vulnérabilité spécifiques à des environnements et déploiements particuliers.

Calcul du score de base CVSS v3 : Les scores de base combinent plusieurs métriques :

Métriques d’exploitabilité :

Vecteur d’attaque (AV) : Réseau (N), Adjacent (A), Local (L) ou Physique (P).
Complexité des attaques (AC) : Faible (L) ou Haute (H) difficulté à exploiter la vulnérabilité.
Privilèges requis (PR) : Aucun (N), Faible (L) ou Haut (H) privilèges nécessaires pour exploiter.
Interaction utilisateur (interface utilisateur) : Aucun (N) ou Obligatoire (R) pour une exploitation réussie.

Métriques d’impact :

Impact sur la confidentialité (C) : Aucune (N), faible (L) ou divulgation d’informations élevée (H).
Impact sur l’intégrité (I) : Aucune (N), Faible (L) ou Haute (H) capacité de modification des données.
Impact sur la disponibilité (A) : Aucune (N), faible (L) ou interruption de service élevée (H).

Exemple de vecteur CVSS :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Cela représente une vulnérabilité exploitable par le réseau avec une complexité d’attaque faible, aucun privilège requis, aucune interaction utilisateur et un impact élevé sur la confidentialité, l’intégrité et la disponibilité.

Classifications de gravité

Les scores CVSS correspondent aux évaluations de gravité :

Severity	CVSS Score	Description	Priorité
Critique	9.0 - 10.0	Des vulnérabilités facilement exploitables provoquent une compromission généralisée du système.	Correction immédiate requise.
Élevé	7.0 - 8.9	Vulnérabilités graves permettant une divulgation d’informations ou une interruption de service significatives.	Correction requise dans les jours.
Moyenne	4.0 - 6.9	Modérer les vulnérabilités avec une exploitabilité ou un impact limités.	Correction requise dans les semaines.
Low	0.1 - 3.9	Vulnérabilités mineures ayant un impact minimal sur la sécurité.	Remédiation quand c’est pratique.
Aucun	0,0	Résultats d’information sans impact réel sur la sécurité.	Correction facultative.

Exemples d'interprétation de la gravité :

Vulnérabilité critique (CVSS 10.0) :

CVE-2021-44228 (Log4Shell)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Description: Remote code execution in Apache Log4j 2
Impact: Unauthenticated attacker can execute arbitrary code remotely
Exploitability: Actively exploited in the wild with publicly available exploits

Vulnérabilité élevée (CVSS 8.1) :

CVE-2022-23648
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Description: Path traversal in container runtime
Impact: Authenticated users can access files outside container boundaries
Exploitability: Requires authentication but easily exploitable

Vulnérabilité moyenne (CVSS 5.9) :

CVE-2023-12345
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description: Information disclosure through timing attack
Impact: Sensitive information disclosure possible with sophisticated attack
Exploitability: Requires specific timing conditions, difficult to exploit

Évaluation de l’exploitabilité

Les scores CVSS ne racontent pas l’histoire complète : l’évaluation de l’exploitabilité détermine le risque réel :

Maturité de l’exploit

Étapes de disponibilité d’exploit :

Non prouvé:

Statut: Vulnérabilité théorique sans exploit connu.
Niveau de risque : Moindre risque : l’exploitation nécessite un effort important d’attaquant.
Action : Surveiller le développement d'exploits et planifier la remédiation, mais pas urgent.

Preuve de concept :

État : code d’exploit de preuve de concept publié, mais pas armé.
Niveau de risque : Risque modéré : des attaquants sophistiqués pourraient armer l’exploit.
Action: Hiérarchiser la correction ; développer des stratégies d’atténuation.

Fonctionnel:

Statut: Code d’exploitation disponible publiquement.
Niveau de risque : Risque élevé : exploitation accessible aux attaquants modérément qualifiés.
Action: Accélérer la correction ; implémenter des atténuations temporaires si la mise à jour corrective est retardée.

Exploitation active :

Statut: Vulnérabilité exploitée activement dans la nature.
Niveau de risque : Risque critique : l’exploitation se produit maintenant.
Action: Correction d’urgence ; implémenter des atténuations immédiates ; surveiller la compromission.

Exemple d’évaluation de l’exploitabilité :

CVE-2021-44228 (Log4Shell)
Severity: Critical (CVSS 10.0)
Exploit Maturity: Active exploitation

Analysis:
- Public exploit code available within hours of disclosure
- Automated scanning and exploitation observed globally
- Multiple malware families incorporating the exploit
- Trivial to exploit with single HTTP request

Priority: EMERGENCY - Immediate patching required

Analyse de la surface d’attaque

Déterminez si la vulnérabilité est accessible :

Facteurs d’accessibilité :

Utilisation du code : Le chemin du code vulnérable est-il réellement exécuté par votre application ?
Exposition réseau : Le composant vulnérable est-il exposé à l’accès réseau ?
Configuration requise pour l’authentification : L’exploitation nécessite-t-elle un accès authentifié ?
Dépendances de configuration : La vulnérabilité nécessite-t-elle des configurations spécifiques pour être exploitables ?

Exemple d’accessibilité :

Vulnerability: SQL injection in unused admin feature
Severity: High (CVSS 8.5)
Reachability: NOT REACHABLE

Analysis:
- Vulnerable code exists in imported library
- Admin features are disabled in production configuration
- Vulnerable code paths never executed
- Network access to admin interface blocked by firewall

Priority: LOW - Update during regular maintenance window

Contexte environnemental

Considérez votre environnement spécifique :

Segmentation du réseau :

Accessible sur Internet : Les vulnérabilités dans les composants accessibles sur Internet ont la priorité la plus élevée.
Réseau interne : Les vulnérabilités internes uniquement ont une priorité inférieure si le réseau est segmenté.
Systèmes isolés : Les systèmes air-gappés ou isolés ont un risque minimal d'exposition aux vulnérabilités réseau.

Sensibilité des données :

Données sensibles : Les vulnérabilités dans les systèmes qui gèrent les données sensibles nécessitent une correction urgente.
Informations publiques : Les vulnérabilités de divulgation d’informations sont plus faibles si les données sont déjà publiques.
Environnements de test : Les vulnérabilités dans les environnements hors production sont généralement plus faibles.

Contrôles de compensation :

Pare-feu d’applications web : Les règles WAF peuvent atténuer les tentatives d’exploitation.
Détection des intrusions : IDS/IPS peut détecter et bloquer les tentatives d’exploitation.
Segmentation du réseau : L’isolation réseau limite l’impact de l’exploitation.
Privilège minimum : Les autorisations restreintes réduisent l’impact sur l’exploitation.

Gestion des faux positifs

Toutes les vulnérabilités signalées n’affectent pas réellement vos applications :

Causes de faux positifs courantes

Composants mal identifiés :

Conflits d’affectation de noms : Différents composants portant des noms similaires sont mal mis en correspondance.
Erreurs de détection de version : Identification de version incorrecte entraînant de fausses correspondances de vulnérabilité.
Confusion de l’espace de noms du package : Les packages dans différents écosystèmes sont identifiés de manière incorrecte comme étant le même package.

Exemple de faux positif :

Alert: CVE-2022-12345 in "parser" package (npm)
Severity: High

Investigation:
- Application uses "xml-parser" package
- Scanner incorrectly identified "xml-parser" as vulnerable "parser" package
- Different packages with similar names
- Vulnerability does not affect application

Resolution: Suppress false positive with documented justification

Chemins de code inutilisés :

Code mort : Code vulnérable importé mais jamais exécuté.
Fonctionnalités facultatives : Les vulnérabilités dans les fonctionnalités facultatives que votre application n’active pas.
Dépendances de développement : Vulnérabilités dans les packages utilisés uniquement pendant le développement, et non en production.

Erreurs de plage de versions :

Rapport de version fixe : Les scanneurs signalent une vulnérabilité dans les versions déjà corrigées.
Correctifs de rétroporteur : les fournisseurs corrigent les correctifs de sécurité de rétroportage sur les versions antérieures sans modifier les numéros de version.
Correctifs personnalisés : Vulnérabilités déjà corrigées par le biais de modifications personnalisées.

Vérification de faux positif

Processus d’investigation :

Vérifier l’identité du composant : Vérifiez que le scanneur a correctement identifié le composant.
Vérifiez la précision de la version : Vérifiez que la version détectée correspond à la version déployée réelle.
Passez en revue les détails des vulnérabilités : Comprendre ce que la vulnérabilité affecte.
Analyser l’utilisation du code : Déterminez si les chemins de code vulnérables sont réellement utilisés.
Consultez les avis sur les fournisseurs : Vérifiez si le fournisseur fournit un contexte supplémentaire.
Exploitation de test : Essayez de reproduire la vulnérabilité dans l’environnement de test.

Exigences de documentation : Lors de la suppression de faux positifs, documentez :

Justification: Pourquoi le constat est un faux positif.
Détails de l’enquête : Étapes prises pour vérifier le faux positif.
Approbateur: Membre de l’équipe de sécurité qui approuve la suppression.
Date de révision : Date de réévaluation de la suppression.

Exemple de fichier de suppression (OWASP Dependency-Check) :

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes>
            False positive: CVE-2022-12345 affects "parser" package but we use "xml-parser".
            Scanner incorrectly matched based on partial name match.
            Investigated by security team on 2025-10-21.
            Review annually.
        </notes>
        <packageUrl regex="true">^pkg:npm/xml-parser@.*$</packageUrl>
        <cve>CVE-2022-12345</cve>
    </suppress>
</suppressions>

Cadres de hiérarchisation

Une gestion efficace des vulnérabilités nécessite une hiérarchisation systématique :

Hiérarchisation basée sur les risques

Facteurs de hiérarchisation :

Score de gravité (poids de 25%) :

Le score de base CVSS fournit des bases pour l’évaluation des risques.
Les scores plus élevés indiquent un impact potentiel plus grave.

Exploitabilité (poids de 35%) :

L’état d’exploitation actif est le facteur le plus critique.
La disponibilité des exploitations publiques augmente considérablement les risques.
Les exploits de preuve de concept indiquent une exploitation réalisable.

Critique des ressources (poids de 20%) :

Les applications accessibles sur Internet ont une priorité plus élevée.
Les systèmes qui traitent des données sensibles nécessitent une mise à jour corrective urgente.
Les applications critiques pour l’entreprise ne peuvent pas tolérer un temps d’arrêt prolongé.

Facteurs environnementaux (poids de 20%) :

Les contrôles de compensation existants réduisent les risques effectifs.
La segmentation du réseau limite le rayon d’explosion.
Les fonctionnalités de surveillance permettent la détection des menaces.

Matrice de hiérarchisation :

Exploitabilité	Gravité critique	Gravité élevée	Gravité moyenne	Gravité faible
Exploitation active	P0 (urgence)	P0 (urgence)	P1 (critique)	P2 (haut)
Exploit fonctionnel	P0 (urgence)	P1 (critique)	P2 (haut)	P3 (moyen)
Preuve de concept	P1 (critique)	P2 (haut)	P3 (moyen)	P4 (faible)
Non prouvé	P2 (haut)	P3 (moyen)	P4 (faible)	P5 (facultatif)

SLA de remédiation

Définissez des contrats de niveau de service pour la correction :

Urgence (P0) :

Délai : Immédiat (dans les 24 heures).
Critères: Vulnérabilités critiques sous exploitation active dans les systèmes accessibles sur Internet.
Processus: Processus de modification d’urgence avec notification de la direction.
Exemple: Log4Shell (CVE-2021-44228) dans l’application publique.

Critique (P1) :

Période : 7 jours.
Critères: Gravité élevée/critique avec des attaques fonctionnelles ou une exposition accessible sur Internet.
Processus: Processus de changement accéléré avec coordination de l’équipe de sécurité.
Exemple: Injection SQL dans l’interface d’administration authentifiée.

Élevé (P2) :

Période : 30 jours.
Critères: Gravité moyenne/élevée avec des exploits de preuve de concept ou une exposition interne.
Processus: Processus de modification standard avec fenêtre de maintenance planifiée.
Exemple : Cross-site scripting (XSS) dans le tableau de bord interne.

Moyen (P3) :

Période : 90 jours.
Critères: Gravité faible/moyenne sans exploits connus.
Processus: Cycle de mise à jour régulière avec mise à jour trimestrielle.
Exemple: Divulgation d’informations dans la dépendance de l’outil de développement.

Faible (P4) :

Délai : Prochaine version majeure.
Critères: Faible gravité ou faux positifs nécessitant une documentation.
Processus : inclure dans les activités de maintenance régulières.
Exemple: Déni de service dans une fonctionnalité facultative inutilisée.

Établissement de niveaux de criticité des bugs de sécurité

Les seuils de sécurité définissent les normes de sécurité minimales qui doivent être respectées :

Définition des critères de complétion

Exemple de barre de bogues de sécurité :

Security Bug Bar:
  Blocking Issues (Must Fix Before Release):
    - No critical severity vulnerabilities
    - No high severity vulnerabilities with public exploits
    - No vulnerabilities actively exploited in the wild
    - No strong copyleft licenses (GPL, AGPL) in proprietary code
    - No secrets in source code or container images

  Non-Blocking Issues (Track and Plan):
    - High severity without public exploits (90-day remediation plan)
    - Medium severity vulnerabilities (next minor release)
    - License issues requiring legal review (document plan)

  Informational (Monitor):
    - Low severity vulnerabilities
    - Informational security findings
    - Code quality issues

Application de la stratégie

Porte de qualité Azure Pipelines :

- task: WhiteSource@21
  inputs:
    cwd: "$(System.DefaultWorkingDirectory)"
    projectName: "$(Build.Repository.Name)"
    checkPolicies: true
    failBuildOnPolicyViolation: true
  displayName: "Enforce security bug bar"

- script: |
    # Custom policy check script
    if [ $(jq '.vulnerabilities.critical' scan-results.json) -gt 0 ]; then
      echo "##vso[task.logissue type=error]Critical vulnerabilities detected"
      echo "##vso[task.complete result=Failed;]Failed security bug bar"
      exit 1
    fi
  displayName: "Validate security bug bar compliance"

Flux de travail de triage des vulnérabilités

Le tri systématique garantit une gestion efficace des vulnérabilités :

Processus de triage

Étape 1 : Filtrage automatisé :

Outils de scanneur : Filtrez automatiquement les vulnérabilités par gravité.
Analyse de l'accessibilité : Supprimez les vulnérabilités inaccessibles de la file d’attente de triage.
Faux positifs connus : Supprimez automatiquement les faux positifs identifiés précédemment.

Étape 2 : Évaluation initiale :

Révision de gravité : vérifiez la précision du score CVSS pour votre environnement.
Vérification de l'exploitation : Déterminer la disponibilité des exploits et leur exploitation active.
Identification des ressources : Identifiez les applications et les systèmes affectés.

Étape 3 : Évaluation des risques :

Impact commercial : Évaluez l’impact potentiel de l’exploitation réussie.
Analyse de l’exposition : Déterminez l’exposition du réseau et la surface d’attaque.
Contrôles de compensation : Identifier les atténuations existantes réduisant les risques.

Étape 4 : Hiérarchisation :

Affecter la priorité : Utilisez la matrice de hiérarchisation pour affecter la priorité de correction.
Définir la date limite : Attribuez la date limite de correction en fonction du niveau de service SLA.
Assigner un responsable : Désignez l'équipe responsable pour la remédiation.

Étape 5 : Suivi des corrections :

Créer des tickets : Générer des éléments de travail dans le système de suivi (Jira, Azure Boards).
Surveillance de la progression : Suivez la progression de la correction par rapport aux échéances.
Vérification: Validez la correction réussie par une ré-analyse.

Cadence de réunion de triage

Triage de sécurité hebdomadaire :

Participants: Équipe de sécurité, responsable du développement, représentants des opérations.
Ordre du jour: Passez en revue les nouvelles conclusions importantes/critiques, suivez la progression de la correction, ajustez les priorités.
Durée : 30 à 60 minutes.

Révision mensuelle des vulnérabilités :

Participants: Leadership en matière de sécurité, gestion de l’ingénierie, équipe de conformité.
Ordre du jour: Passez en revue les tendances, ajustez les stratégies, évaluez la posture globale de sécurité.
Durée : 60 à 90 minutes.

Métriques et rapports

Suivez l’efficacité de la gestion des vulnérabilités :

Mesures clés

Métriques de vulnérabilité :

Temps moyen à détecter (MTTD) : Délai de divulgation des vulnérabilités à la détection dans vos systèmes.
Temps moyen de correction (MTTR) : Délai de détection jusqu’à la correction réussie.
Densité des vulnérabilités : Nombre de vulnérabilités par application ou ligne de code.
Taux de correction : Pourcentage de vulnérabilités corrigées dans le contrat SLA.

Métriques de tendance :

Nombre de vulnérabilités ouverts : Nombre de tendances de vulnérabilités non résolues par gravité.
Nouveau ou résolu : Comparaison des vulnérabilités nouvellement détectées et corrigées.
Conformité du contrat SLA : Pourcentage de vulnérabilités corrigées dans les contrats SLA définis.
Taux de faux positifs : Pourcentage de résultats déterminés comme faux positifs.

Exemple de tableau de bord

Tableau de bord de gestion des vulnérabilités :

Critical Vulnerabilities: 0 (Target: 0)
High Vulnerabilities: 3 (Target: < 10)
Medium Vulnerabilities: 47 (Target: < 100)
Low Vulnerabilities: 132 (Tracking only)

Mean Time to Remediate:
- Critical: 18 hours ✓
- High: 6 days ✓
- Medium: 21 days ✓

Remediation Progress:
- P0 (Emergency): 0 overdue
- P1 (Critical): 1 due in 3 days
- P2 (High): 5 due in next 30 days
- P3 (Medium): 12 due in next 90 days

Trends (Last 90 Days):
- New vulnerabilities: 127
- Remediated: 138
- Net reduction: -11 ✓

Note

Pour plus d’informations sur les contrats de niveau de service (SLA) et les chronologies de correction, consultez Contrats de niveau de service Azure.

L’interprétation efficace des alertes de vulnérabilité et la hiérarchisation transforment la sortie du scanneur écrasante en améliorations de sécurité exploitables. En comprenant les scores de gravité, en évaluant l’exploitabilité, en gérant les faux positifs et en implémentant une hiérarchisation systématique, les équipes concentrent les efforts de correction sur les vulnérabilités présentant des risques réels plutôt que de poursuivre chaque alerte. Cette approche basée sur les risques permet des programmes de sécurité durables qui protègent les applications sans surcharger les équipes de développement avec du bruit.

Commentaires

Cette page a-t-elle été utile ?