> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/fr/helm/get-started-with-helm/understand-data-sources-and-update-frequency.md).
# Comprendre les sources de données et la fréquence des mises à jour
Notre produit de gestion des vulnérabilités des SBOM intègre des données provenant de plusieurs sources afin de vous fournir les informations les plus complètes et les plus à jour, notamment en ce qui concerne la fréquence des mises à jour. En intégrant ces sources, notre produit de gestion des vulnérabilités des SBOM vous permet de gérer et d’atténuer efficacement les risques.
## À quelle fréquence les données sont-elles mises à jour ?
| Action | Mise à jour |
| --------------------- | ------------------- |
| Ingestion des données | Quotidienne |
| Surveillance continue | Toutes les 2 heures |
## **Quelles sources de données Helm utilise-t-il ?**
Pour chaque vulnérabilité dans Helm, vous pouvez voir la ou les sources de données d’où elle provient. Des liens vers le CVE d’origine, ainsi que vers des informations sur l’exploitabilité et les menaces, sont fournis.
### **National Vulnerability Database (NVD)**
La National Vulnerability Database (NVD) est le référentiel le plus complet au monde de données accessibles au public sur la gestion des vulnérabilités. Gérée par le National Institute of Standards and Technology (NIST), la NVD s’appuie sur les travaux fondamentaux de MITRE et d’autres grandes entités de cybersécurité. La base de données répertorie les vulnérabilités identifiées sous le nom de Common Vulnerabilities and Exposures (CVE) et fournit des informations détaillées sur plus de 100 000 CVE documentés, remontant aux années 1990. La NVD fournit non seulement des renseignements essentiels sur les failles et les erreurs de configuration des logiciels, mais aussi des métadonnées cruciales telles que des scores de gravité, des mesures d’impact et d’exploitabilité, ainsi que des étapes de correction, ce qui en fait une ressource indispensable pour les professionnels de la cybersécurité.
Vous pouvez facilement repérer les vulnérabilités provenant de la NVD grâce à l’indicateur de badge **NVD** dans la colonne **Source** .
### Copilote IA
En réponse à l’arriéré de la NVD, MedISAO, en collaboration avec Medcrypt, a expérimenté un copilote IA qui exploite les[ grands modèles de langage (LLM) pour traiter les vulnérabilités, avec des résultats prometteurs](https://www.prunderground.com/medisao-launches-ai-powered-vulnerability-analysis-to-address-national-vulnerability-database-disruptions/00336277/). Cette stratégie vise à combler l’écart jusqu’à ce que la NVD et la CISA résorbent leurs arriérés.
Ce système crée des données de correspondance entre les produits et les versions CPE afin d’assurer un enrichissement rapide et continu des vulnérabilités.
Ce copilote IA recueille des informations dans des bases de données de vulnérabilités telles que la NVD et MITRE, ainsi qu’auprès d’autres sources externes, afin de rester à jour et de mettre continuellement à jour les informations sur les vulnérabilités.
Vulnérabilités traitées par la NVD, la CISA et l’approche LLM de Medcrypt jusqu’au 22 mai 2024
**Sources de données et mises à jour du copilote IA**
Ce copilote IA recueille des informations dans des bases de données de vulnérabilités telles que la NVD, la CISA, CVE.org et MITRE, ainsi qu’auprès d’autres sources externes, afin de rester à jour et de mettre continuellement à jour les informations sur les vulnérabilités.
**Intégration de CVE.org**
Nous ajoutons actuellement CVE.org comme source de données, et cette prise en charge devrait être disponible dans une prochaine version. CVE.org fournit une liste de vulnérabilités en cybersécurité rendues publiques, chacune étant associée à un identifiant CVE unique. Avec plus de 230 000 CVE identifiés, définis et répertoriés, CVE.org collabore avec des membres de la communauté du monde entier pour enrichir le contenu des CVE. CVE.org est désormais chargé d’enrichir les CVE de la NVD avec des informations CPE afin de résorber l’arriéré.
**Prise en charge et intégration**
Avec la prise en charge de Helm, l’outil de gestion des vulnérabilités de Medcrypt, cette approche fondée sur l’IA utilise des données historiques et un analyseur grammatical personnalisé afin de réduire les inexactitudes et d’accroître la fiabilité. Les résultats de ce copilote IA reflètent le flux de données de la NVD, ce qui permet aux outils compatibles avec ce flux d’utiliser facilement les données enrichies.
**À quelle fréquence le flux de données de la NVD est-il mis à jour ?**
Ce flux est mis à jour quotidiennement et est accessible aux membres et partenaires de MedISAO. À ce jour, il a analysé plusieurs milliers de vulnérabilités de plus que la NVD ou la CISA et a été intégré au produit Helm de Medcrypt, améliorant ainsi l’identification des vulnérabilités.
### **Exploit Database (ExploitDB)**
[Exploit Database (ExploitDB](https://www.exploit-db.com/)) est une archive d’exploits publics et des logiciels vulnérables correspondants, qui donne un aperçu des façons dont les vulnérabilités peuvent être exploitées. ExploitDB fournit des informations sur les exploits actifs ainsi que sur Metasploit, une boîte à outils de piratage que des utilisateurs moins expérimentés peuvent employer pour exploiter une vulnérabilité. Pour chaque vulnérabilité dans Helm, des informations sont fournies sur son exploitabilité et les menaces associées, ainsi que sur la source de ces informations.
Tout exploit actif provenant de cette base de données est signalé par un badge **ExploitDB** ou un badge **Metasploit** , selon qu’il s’agit d’un exploit actif seul ou qu’une boîte à outils Metasploit est disponible. Vous pouvez également consulter l’impact de chaque vulnérabilité, qui présente tous les exploits et menaces connus et fournit des liens vers les détails de la source d’origine.
### **Exploit Prediction Scoring System (EPSS)**
L’ [Exploit Prediction Scoring System (EPSS)](https://www.first.org/epss/) est une initiative fondée sur les données qui vise à estimer la probabilité qu’une vulnérabilité logicielle soit exploitée dans la nature. Elle a pour objectif d’aider les entreprises à mieux hiérarchiser les mesures de correction des vulnérabilités. Alors que d’autres normes du secteur permettent de caractériser les propriétés intrinsèques d’une vulnérabilité et d’en mesurer la gravité, elles évaluent moins bien la menace. EPSS comble cette lacune en utilisant les informations actuelles sur les menaces issues des CVE et les données d’exploitation observées dans le monde réel. Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 à 100 %). Plus le score est élevé, plus la probabilité que la vulnérabilité soit exploitée est grande.
Helm fournit des scores EPSS pour toute vulnérabilité associée à un score CVSS v3, car seules les vulnérabilités CVSS v3 ont été évaluées selon la méthodologie EPSS.
### **Top 25 CWE (Common Weakness Enumeration)**
[Top 25 CWE](https://cwe.mitre.org/top25/) est une liste des faiblesses logicielles les plus courantes, répandues et dommageables, que des adversaires peuvent exploiter pour voler des données, prendre le contrôle d’un système ou empêcher des applications de fonctionner, ainsi que des faiblesses logicielles critiques.
Pour établir le [2023 CWE Top 25](https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html) liste, l’équipe CWE s’est appuyée sur les [Common Vulnerabilities and Exposures (CVE®)](https://cve.mitre.org/) données disponibles auprès du National Institute of Standards and Technology (NIST) [U.S. National Vulnerability Database (NVD)](https://nvd.nist.gov/) et les [scores du Common Vulnerability Scoring System (CVSS)](https://nvd.nist.gov/vuln-metrics/cvss) associés à chaque enregistrement CVE, en mettant notamment l’accent sur ceux de la Cybersecurity and Infrastructure Security Agency (CISA) [Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). Une formule a été appliquée aux données afin d’attribuer un score à chaque faiblesse selon sa prévalence et sa gravité. La liste des 25 principales CWE est tenue à jour par la société MITRE.
Toute vulnérabilité considérée comme une menace figurant parmi les 25 principales CWE sera accompagnée d’un **Top CWE** badge dans Helm. Vous pouvez également consulter des informations supplémentaires sur l’impact dans les détails de la vulnérabilité, ainsi que vérifier les sources d’origine.
### **Known Exploited Vulnerabilities (KEV) de la CISA**
Le [catalogue KEV de la CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) répertorie les vulnérabilités dont on sait qu’elles sont activement exploitées dans la nature.
La CISA tient à jour ce catalogue, qui constitue la source officielle des vulnérabilités exploitées dans la nature. Il vise à aider les défenseurs des réseaux et les organisations à mieux gérer les vulnérabilités et à suivre l’évolution des menaces. Les organisations devraient utiliser le catalogue KEV comme élément de leur cadre de priorisation de la gestion des vulnérabilités.
Toute vulnérabilité figurant dans la liste KEV de la CISA sera accompagnée d’un **CISA KEV** badge dans Helm. Vous pouvez également consulter des informations supplémentaires sur l’impact dans les détails de la vulnérabilité, ainsi que vérifier les sources d’origine.
### **Catalogue de la base de connaissances Microsoft (KB)**
Le [catalogue des mises à jour de la base de connaissances Microsoft](https://www.catalog.update.microsoft.com/search.aspx?q=kb) répertorie les correctifs et les mises à jour des produits Microsoft, essentiels au suivi et à la gestion des vulnérabilités des logiciels Microsoft. Microsoft fournit une liste de mises à jour importantes, recommandées et facultatives pouvant être distribuées sur un réseau d’entreprise. Ce catalogue permet de trouver en un seul endroit les mises à jour logicielles, les pilotes et les correctifs provisoires Microsoft.
Les mises à jour importantes apportent des avantages majeurs, tels qu’une sécurité et une fiabilité accrues. Les mises à jour facultatives peuvent, par exemple, inclure des pilotes nouveaux ou mis à jour pour les périphériques que vous avez ajoutés à votre ordinateur.
Toute vulnérabilité pour laquelle un correctif recommandé est disponible sera signalée par un indicateur de correctif disponible. Vous pourrez bientôt également consulter les recommandations de correctifs dans les détails de la vulnérabilité.
## Routage des sources de données
Les composants appartiennent souvent à un ou plusieurs écosystèmes. Ces écosystèmes disposent généralement d’une ou plusieurs sources de référence qui fournissent des données supplémentaires sur les composants. Par exemple, Maven Central et le dépôt NPM fournissent respectivement des informations sur les composants Java et Node.
Les vulnérabilités peuvent être identifiées à l’aide de trois champs : CPE, PURL et SWID. Helm prend en charge PURL et CPE.
### Package URL (PURL)
Helm prend en charge les [Package URL](https://github.com/package-url/purl-spec) (PURL), qui offre un moyen flexible de représenter les métadonnées des composants et leur appartenance à différents écosystèmes. PURL est pris en charge par la spécification SBOM CycloneDX.
Helm utilise PURL de plusieurs façons :
* Faire correspondre les composants pour identifier les vulnérabilités
* Réduire les faux positifs et les faux négatifs
* Identifier les composants obsolètes dans différents écosystèmes
#### Écosystèmes de gestionnaires de paquets pris en charge
Helm prend en charge nativement les [gestionnaires de paquets](/fr/helm/match-unmatched-components/understand-match-sources.md) suivants, et élargit actuellement cette prise en charge :
| Langage | Gestionnaire de paquets | Dépôt de paquets |
| ---------- | ----------------------- | --------------------------------------- |
| C# | NuGet | [NuGet Gallery](https://www.nuget.org/) |
| JavaScript | NPM | [NPM](https://www.npmjs.com/) |
| Python | PyPI | [PyPI](https://pypi.org/) |
| Rust | Cargo | [crates.io](https://crates.io/) |
#### Quand une correspondance PURL est-elle établie ?
Pour toute vulnérabilité détectée à l’aide d’un gestionnaire de paquets, le nom du gestionnaire correspondant apparaît dans son badge. Si un composant est associé à un badge de gestionnaire de paquets, mais ne possède pas de badge **NVD** cela signifie que Helm a identifié votre logiciel dans le gestionnaire de paquets, mais qu’aucune vulnérabilité n’a été signalée dans la NVD.
#### À quoi sert PURL ?
Il est recommandé d’utiliser PURL pour identifier un conteneur, une bibliothèque ou un framework (paquet), ou un paquet de système d’exploitation.
#### Syntaxe PURL
Le standard Package URL (PURL) uniformise la représentation des métadonnées des paquets logiciels afin qu’ils puissent être localisés de manière universelle, quels que soient leur fournisseur, leur projet ou leur écosystème. PURL vise à standardiser les méthodes existantes permettant d’identifier et de localiser de manière fiable les paquets logiciels. Il s’agit d’une chaîne URL utilisée pour identifier et localiser un paquet logiciel de manière largement universelle et uniforme dans différents langages de programmation, gestionnaires de paquets, conventions de empaquetage, outils, API et bases de données.
Comme indiqué ci-dessus, nous prenons actuellement en charge les gestionnaires de paquets PURL suivants : Cargo, NPM, NuGet et PyPI.
#### Format PURL
Un PURL se compose de 7 éléments :
`scheme:type/namespace/name@version?qualifiers#subpath`
Définition de chaque élément :
* `scheme`: schéma URL dont la valeur constante est « pkg ». L’une des principales raisons d’utiliser ce schéma unique est de faciliter l’enregistrement officiel futur du schéma « pkg » pour les Package URL. Obligatoire.
* `type`: « type » ou « protocole » du paquet, par exemple maven, npm, nuget, gem, pypi, etc. Obligatoire.
* `namespace`: préfixe de nom, tel qu’un groupid Maven, le propriétaire d’une image Docker, un utilisateur ou une organisation GitHub. Facultatif et propre au type.
* `name`: nom du paquet. Obligatoire.
* `version`: version du paquet. Facultatif.
* `qualifiers`: données supplémentaires qui précisent les caractéristiques d’un paquet, telles que le système d’exploitation, l’architecture ou la distribution. Facultatif et propre au type.
* `subpath`: sous-chemin supplémentaire dans un paquet, relatif à la racine du paquet. Facultatif.
**Exemples :**
* `pkg:pypi/django@1.11.1`
* `pkg:nuget/EnterpriseLibrary.Common@6.0.1304`
* `pkg:npm/foobar@12.3.1`
### Common Platform Enumeration (CPE)
Le NIST définit CPE comme un système de nommage structuré pour les systèmes informatiques, les logiciels et les packages. Il repose sur la syntaxe générique des identifiants de ressources uniformes (URI) et comprend un format de nom formel, une méthode permettant de vérifier les noms par rapport à un système, ainsi qu’un format de description permettant d’associer du texte et des tests à un nom. La spécification CPE a été conçue pour les systèmes d’exploitation, les applications et les périphériques matériels. Elle est maintenue par le NVD.
#### Quand une correspondance CPE est-elle établie ?
Pour toute vulnérabilité détectée à l’aide d’une correspondance CPE, un badge **CPE** apparaît. Si un composant est associé à un badge CPE, cela signifie qu’au moins une vulnérabilité le concernant a été signalée dans la NVD. Un CPE n’est attribué à un logiciel que lorsqu’une vulnérabilité a été signalée dans la NVD.
#### Syntaxe CPE
Le CPE suit le format suivant : `cpe::::::::::::`
* `cpe_version`: Il s’agit de la version de la définition CPE. À la date de rédaction, la dernière version de la définition CPE est la 2.3.
* `part`: Cette valeur peut être l’une des trois suivantes : a pour les applications (Applications), h pour le matériel (Hardware), o pour les systèmes d’exploitation (Operating systems). On l’appelle parfois type.
* `vendor`: identifie la personne ou l’organisation qui a fabriqué ou créé ce composant.
* `product`: Il s’agit du nom du système, du package ou du composant.
* `version`: Il s’agit de la version du système, du package ou du composant.
* `update`: Indique les informations relatives à toute mise à jour ou à tout service pack, également appelées versions mineures.
* `edition`: Décrit la version de build du système, du package ou du composant, au-delà de sa version.
* `sw_edition` (2.3 uniquement) : Indique la langue du système, du package ou du composant, par exemple en-us pour l’anglais américain.
* `target_sw` (2.3 uniquement) : Indique la langue du système, du package ou du composant, par exemple en-us pour l’anglais américain.
* `target_hw` (2.3 uniquement) : Indique la langue du système, du package ou du composant, par exemple en-us pour l’anglais américain.
* other (2.3 uniquement) : Indique la langue du système, du package ou du composant, par exemple en-us pour l’anglais américain.
#### **Exemples de chaînes CPE**
***Application :***\
Si l’URI est `cpe:/a:microsoft:office:2007:sp2:professional` alors la chaîne CPE est :\
`cpe:2.3:a:microsoft:office:2007:sp2:-:*:professional:*:*:*`
***Système d’exploitation :***\
Si l’URI est\
`cpe:/o:microsoft:windows_7:-:sp1:x64` alors la chaîne CPE est :\
`cpe:2.3:o:microsoft:windows_7:-:sp1:-:*:*:*:x64:*`
***Matériel (non pris en charge dans un SBOM) :***\
Si l’URI est `cpe:/h:3com:3c13612` alors la chaîne CPE est :\
`cpe:2.3:h:3com:3c13612:-:*:*:*:*:*:*:*`
***Que signifie un caractère générique dans une chaîne CPE ?***\
Un caractère générique (\*) indique qu’aucune valeur particulière n’a été fournie pour cette section ; il couvre donc toutes les valeurs applicables dans cette section.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.medcrypt.com/fr/helm/get-started-with-helm/understand-data-sources-and-update-frequency.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
