1. Introduction aux SCA (Software Composition Analysis)

1.1 Qu'est-ce que le SCA ?

Le Software Composition Analysis (SCA) est une pratique importante dans le développement moderne, particulièrement en raison de l'utilisation croissante des bibliothèques open-source et des composants tiers dans les projets logiciels. Le SCA consiste à scanner les composants logiciels d'une application afin d'identifier les vulnérabilités, les licences de logiciels problématiques ou non conformes, et les versions obsolètes des dépendances.
Ces outils jouent un rôle essentiel dans la gestion de la sécurité des applications, car de nombreuses vulnérabilités critiques existent dans des bibliothèques que les développeurs intègrent sans toujours les examiner en détail. Les attaques visant ces dépendances sont souvent plus simples à exécuter, car elles exploitent des failles connues dans des versions spécifiques des bibliothèques.

1.2 Pourquoi utiliser le SCA ?

L’adoption de composants logiciels tiers présente de nombreux avantages, notamment la réduction du temps de développement et l'accès à des fonctionnalités éprouvées. Cependant, cela introduit aussi des risques importants. Une vulnérabilité dans un composant tiers peut compromettre l’ensemble de l’application. Le SCA est donc indispensable pour :

• Détecter les vulnérabilités : Identifier les dépendances vulnérables, en particulier celles associées à des CVE (Common Vulnerabilities and Exposures).
• Assurer la conformité : Vérifier que les licences des composants tiers respectent les exigences légales et les politiques internes.
• Mettre à jour les dépendances : Recommander la mise à jour des composants pour combler les failles de sécurité.

1.3 Exemples d'outils SCA

Plusieurs outils de SCA existent pour analyser les dépendances des projets. Voici quelques exemples courants :

• Trivy : Un scanner open-source qui détecte les vulnérabilités non seulement dans les images de conteneurs, mais aussi dans les dépendances de fichiers, les configurations Kubernetes, et plus encore.
• Snyk : Une plateforme qui permet de détecter et de corriger les vulnérabilités dans les dépendances open-source, les conteneurs, et les infrastructures. Snyk propose également une intégration avec des outils CI/CD pour une automatisation complète.
• Dependabot : Un outil intégré à GitHub qui surveille les dépendances et ouvre automatiquement des pull requests pour mettre à jour les versions vulnérables.
• OSS Index : Une base de données d'analyse de vulnérabilités pour les composants open-source, souvent intégrée dans des outils comme Sonatype Nexus.

Vous pouvez trouver une liste d'outil de ce type sur le site de l'OWASP: https://owasp.org/www-community/Component_Analysis

1.4 Limites des outils SCA

Bien que les outils SCA soient très efficaces, ils ont des limitations :

• Faux positifs et faux négatifs : Tous les outils peuvent détecter des vulnérabilités qui ne sont pas nécessairement exploitables dans le contexte spécifique de l'application, ou ne pas identifier certaines failles.
• Dépendance à des bases de données publiques : La plupart des outils SCA se basent sur des bases de données publiques comme la NVD (National Vulnerability Database), qui peuvent ne pas être à jour avec les dernières informations de vulnérabilité.
• Volume de résultats : Les analyses SCA peuvent générer une grande quantité de résultats, ce qui rend la priorisation des vulnérabilités critique pour ne pas être submergé.

1.5 Importance de la priorisation des vulnérabilités SCA

Les résultats SCA peuvent rapidement devenir volumineux, avec des centaines de vulnérabilités détectées, en particulier dans des projets avec un large écosystème de dépendances. Il est donc essentiel de prioriser les vulnérabilités à corriger. Sans priorisation, les équipes de sécurité et de développement risquent de se perdre dans des tâches qui ne répondent pas aux menaces les plus urgentes.
C’est ici que des outils comme le score EPSS (Exploit Prediction Scoring System) entrent en jeu, permettant de trier les vulnérabilités en fonction de la probabilité qu’elles soient exploitées.

2. Présentation du score EPSS (Exploit Prediction Scoring System)

2.1 Qu'est-ce que l'EPSS ?

L'Exploit Prediction Scoring System (EPSS) est une métrique développée pour aider les équipes de sécurité à prioriser les vulnérabilités en fonction de leur probabilité d'exploitation. Plutôt que de simplement classer les vulnérabilités en fonction de leur gravité (comme c'est le cas avec le CVSS), l'EPSS estime la probabilité qu'une vulnérabilité soit activement exploitée dans des cyberattaques réelles.
Créé par le Forum of Incident Response and Security Teams (FIRST), l'EPSS se base sur une analyse de données globales, y compris les vulnérabilités, les exploits publiés et les observations d'incidents réels, pour produire un score prédictif. Cela permet aux organisations de se concentrer sur les vulnérabilités présentant le plus grand risque d'exploitation immédiate.

2.2 Comment est calculé le score EPSS ?

Le score EPSS est basé sur un modèle statistique qui prend en compte divers facteurs liés aux vulnérabilités, notamment :

• Données sur les vulnérabilités : Le système utilise des informations sur les vulnérabilités extraites de bases de données publiques, comme la NVD (National Vulnerability Database) et les CVE.
• Données sur les exploits connus : Le modèle évalue la disponibilité d'exploits publics (exploits connus dans les bases de données comme ExploitDB, Metasploit, etc.).
• Données d'attaques réelles : Il intègre également des informations sur les exploitations observées dans des incidents réels (cyberattaques, incidents de sécurité, etc.).
  Chaque CVE reçoit un score compris entre 0 et 1, représentant la probabilité qu'il soit exploité dans les 30 prochains jours. Un score proche de 1 indique une forte probabilité d'exploitation, tandis qu'un score proche de 0 suggère une faible probabilité.

2.3 Différence entre EPSS et CVSS

Le CVSS (Common Vulnerability Scoring System) est une métrique bien connue pour évaluer la gravité d'une vulnérabilité, mais il ne prend pas en compte le facteur de risque d'exploitation. Le CVSS fournit un score basé sur l'impact potentiel et la complexité de l'attaque, mais il ne dit pas si une vulnérabilité sera réellement exploitée dans un futur proche.

L'EPSS vient compléter ce manque en offrant une vue plus pragmatique et orientée vers l'action. Alors qu'un score CVSS élevé peut indiquer une vulnérabilité critique, il se peut que cette vulnérabilité n'ait aucune exploitation active ni exploit public, ce qui la rend moins prioritaire dans l'immédiat. En combinant l'EPSS et le CVSS, les organisations peuvent mieux identifier les vulnérabilités qui nécessitent une correction rapide.

2.4 Cas d'utilisation de l'EPSS

L'EPSS est particulièrement utile dans les cas suivants :

• Priorisation des correctifs : Les entreprises peuvent se concentrer sur les vulnérabilités qui ont un score EPSS élevé, même si leur score CVSS est relativement faible, car elles présentent un risque plus immédiat.
• Réduction du temps de réponse : En identifiant rapidement les vulnérabilités susceptibles d'être exploitées, les équipes de sécurité peuvent réduire le temps nécessaire pour réagir aux incidents potentiels.
• Équilibrage des ressources : Les équipes de développement ont souvent des ressources limitées pour corriger les vulnérabilités. En intégrant l'EPSS dans leur processus de triage, elles peuvent mieux allouer leurs efforts sur les vulnérabilités les plus critiques.

2.5 Limites de l'EPSS

Comme tout modèle prédictif, l'EPSS a ses limites :

• Absence de certitude absolue : L'EPSS n'est pas une garantie que chaque vulnérabilité avec un score élevé sera exploitée, ni que celles avec un score faible ne le seront pas. C'est un outil de prédiction basé sur des données historiques.
• Dépendance aux données publiques : L'EPSS repose en grande partie sur les données disponibles publiquement, ce qui peut laisser de côté certaines vulnérabilités spécifiques à des systèmes ou logiciels non publics.
• Variation du score dans le temps : Le score EPSS peut évoluer au fil du temps en fonction des nouvelles données disponibles. Une vulnérabilité qui avait un faible score peut voir sa probabilité d'exploitation augmenter si de nouveaux exploits sont publiés ou si elle est observée dans des attaques réelles. Il est donc important de surveiller régulièrement les scores pour ajuster les priorités en conséquence.

2.6 Accès aux données EPSS

Les données EPSS sont accessibles via plusieurs routes d'API, ce qui permet de récupérer des informations spécifiques sur les scores associés aux vulnérabilités (CVE). L'API est flexible et offre différentes options pour interagir avec les données, que ce soit pour un seul CVE ou pour un lot de vulnérabilités. Voici un aperçu des principales routes disponibles :

• Scores pour les CVE les plus récents :
  Cette route renvoie les scores EPSS pour les 100 premières vulnérabilités (CVE) répertoriées.
  URL : https://api.first.org/data/v1/epss
• Score pour un seul CVE :
  Obtenez le score EPSS pour une vulnérabilité spécifique en ajoutant l'identifiant CVE dans la requête.
  URL : https://api.first.org/data/v1/epss?cve=CVE-2022-27225
• Scores pour plusieurs CVE (Batch) :
  Vous pouvez demander les scores EPSS pour une liste de CVE en les séparant par des virgules.
  URL : https://api.first.org/data/v1/epss?cve=CVE-2022-27225,CVE-2022-27223,CVE-2022-27218
• Pagination des résultats :
  Si vous souhaitez naviguer dans les résultats en plusieurs pages, vous pouvez utiliser l'option d'offset pour décaler les résultats.
  URL : https://api.first.org/data/v1/epss?envelope=true&pretty=true&offset=160000
• Scores pour une date spécifique :
  Il est possible d'obtenir le score EPSS d'un CVE à une date donnée, en ajoutant un paramètre de date (au format yyyy-mm-dd) à la requête.
  URL pour un seul CVE : https://api.first.org/data/v1/epss?cve=CVE-2022-26332&date=2022-03-05
  URL pour plusieurs CVE : https://api.first.org/data/v1/epss?cve=CVE-2022-26332,CVE-2022-26315,CVE-2022-26181&date=2022-03-05
• Séries temporelles :
  Pour obtenir les scores EPSS d'un CVE sur les 30 derniers jours, utilisez l'option scope=time-series dans la requête.
  URL : https://api.first.org/data/v1/epss?cve=CVE-2022-25204&scope=time-series
• Top N CVE avec les scores les plus élevés :
  Vous pouvez afficher les CVE ayant les scores EPSS les plus élevés en ordonnant les résultats par order=!epss.
  URL : https://api.first.org/data/v1/epss?order=!epss
• CVE avec un score EPSS supérieur à une valeur donnée :
  Cette route permet de filtrer les CVE en fonction d'un score de probabilité supérieur à une certaine valeur (par exemple, 0,95).
  URL : https://api.first.org/data/v1/epss?epss-gt=0.95
• CVE avec un percentile supérieur à une valeur donnée :
  Vous pouvez également filtrer les résultats pour n'afficher que les CVE avec un percentile supérieur à une certaine valeur.
  URL : https://api.first.org/data/v1/epss?percentile-gt=0.95

Ces différentes routes offrent une grande flexibilité pour l'intégration des données EPSS dans vos systèmes de gestion des vulnérabilités et permettent de prioriser efficacement les correctifs en fonction des risques d'exploitation.

3. Prioriser les vulnérabilités dans Trivy avec le score EPSS

Trivy ne compte pas intégrer les scores EPSS car cela est considéré hors scope, je vous invite à lire ce thread si vous voulez savoir pourquoi: https://github.com/aquasecurity/trivy/discussions/4543
C'est pourquoi dans cette section, nous allons voir comment intégrer le score EPSS aux résultats d'un scan SCA avec l'outil Trivy. L'objectif est de prioriser les vulnérabilités détectées en fonction de leur probabilité d'exploitation, ce qui permet de mieux allouer les efforts de correction.

3.1 Introduction à Trivy

Trivy est un outil open-source polyvalent qui permet de scanner les images de conteneurs, les fichiers systèmes, et les configurations pour détecter des vulnérabilités connues dans les dépendances open-source. C’est un outil largement utilisé dans les pipelines CI/CD pour garantir la sécurité des applications.

Installation de Trivy

L'installation de Trivy est simple et peut se faire via plusieurs méthodes.
Je vous invites à regarder la documentation de l'outil : https://aquasecurity.github.io/trivy/v0.55/getting-started/installation/

3.2 Exécution d'un scan avec Trivy

Trivy permet de scanner des fichiers système ou des dossiers pour détecter les vulnérabilités dans les dépendances open-source. Voici une commande de base pour exécuter un scan et obtenir les résultats au format JSON :

trivy fs --format json --output results.json /path/to/project

Cette commande scanne le répertoire spécifié et enregistre les résultats dans un fichier results.json.

3.3 Intégration du score EPSS aux résultats Trivy

L’étape suivante consiste à enrichir les résultats générés par Trivy avec les scores EPSS pour chaque vulnérabilité (CVE) identifiée. Cela permet de donner un poids plus précis aux vulnérabilités qui ont une probabilité d’exploitation réelle.

Script Python pour ajouter le score EPSS

Voici un exemple de script Python qui parse les résultats JSON de Trivy et ajoute le score EPSS pour chaque CVE détecté.

import json
import requests

# Charger le fichier JSON des résultats Trivy
with open('results.json', 'r') as file:
    trivy_results = json.load(file)

def get_epss_score(cve_id):
    # Requête à l'API EPSS pour obtenir le score basé sur le CVE
    response = requests.get(f'https://api.first.org/data/v1/epss?cve={cve_id}')
    data = response.json()
    if data['status'] == 'OK' and data['data']:
        return data['data'][0]['epss']
    return None

# Ajouter les scores EPSS aux résultats Trivy
for result in trivy_results['Results']:
    for vuln in result.get('Vulnerabilities', []):
        cve = vuln.get('VulnerabilityID')
        epss_score = get_epss_score(cve)
        if epss_score:
            vuln['EPSS_Score'] = epss_score

# Sauvegarder les résultats modifiés
with open('results_with_epss.json', 'w') as file:
    json.dump(trivy_results, file, indent=4)

Le script commence par charger le fichier JSON généré par Trivy qui contient les résultats du scan. La fonction get_epss_score envoie une requête HTTP à l'API EPSS pour obtenir le score du CVE concerné. Le script parcourt ensuite toutes les vulnérabilités trouvées par Trivy et ajoute le score EPSS correspondant. Enfin, les résultats enrichis avec les scores EPSS sont sauvegardés dans un nouveau fichier JSON.
Voici un exemple de résultat JSON après avoir ajouté les scores EPSS :

{
    "Target": "/path/to/project",
    "Type": "filesystem",
    "Vulnerabilities": [
        {
            "VulnerabilityID": "CVE-2022-27225",
            "PkgName": "example-package",
            "InstalledVersion": "1.0.0",
            "FixedVersion": "1.0.1",
            "Severity": "HIGH",
            "Description": "A vulnerability in example-package...",
            "EPSS_Score": 0.92
        },
        {
            "VulnerabilityID": "CVE-2021-45046",
            "PkgName": "another-package",
            "InstalledVersion": "2.0.0",
            "FixedVersion": "2.0.1",
            "Severity": "CRITICAL",
            "Description": "A vulnerability in another-package...",
            "EPSS_Score": 0.68
        }
    ]
}

Dans cet exemple, les vulnérabilités ont un score EPSS ajouté, ce qui permet de prioriser celles avec un score élevé (comme le CVE-2022-27225 qui a un score de 0,92, indiquant une forte probabilité d'exploitation).

Nous ne somes pas les premiers à avoir pensé a l'intégration des scores EPSS dans les résultats d'un SCA, il existe plusieurs projet qui fait cela mieux que le petit script présenté ci-dessus comme https://github.com/EdgewareRoad/TrivySummary

Conclusion

En intégrant le score EPSS aux résultats SCA de Trivy, les équipes peuvent concentrer leurs efforts sur les vulnérabilités les plus susceptibles d'être exploitées, améliorant ainsi l'efficacité de la gestion des risques. Ce type de priorisation réduit non seulement la charge de travail, mais permet aussi de sécuriser les systèmes de manière plus proactive.