> 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/manage-vulnerabilities/identify-and-prioritize-exploitable-vulnerabilities/understand-issue-severity-level/understand-the-cvss-vulnerability-scoring-system.md). # Comprendre le système de notation CVSS des vulnérabilités Helm renvoie le [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) afin de fournir des scores numériques correspondant aux niveaux critique, élevé, moyen et faible, pour vous permettre de comprendre le niveau de risque lié aux vulnérabilités auxquelles vous êtes actuellement exposé. Comme les anciens dispositifs peuvent n’avoir qu’un score CVSS v2, tandis que les dispositifs plus récents peuvent n’avoir qu’un score v3, Helm fournit les scores CVSS v2 et v3, ce qui vous permet d’évaluer les risques sur l’ensemble de votre parc, des dispositifs anciens aux plus récents. Ce score intègre plusieurs facteurs qui évaluent la possibilité d’exploiter une vulnérabilité. ## Score de base Pour les scores CVSS v3, vous pouvez utiliser plusieurs calculateurs afin de comprendre comment le score CVSS d’une vulnérabilité donnée a été calculé : * [Calculateur NIST pour CVSS 3.1](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?version=3.1) * [Calculateur NIST pour CVSS 3.0](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?version=3.0) * [Calculateur NIST pour CVSS 2](https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator?calculator) Survolez chaque valeur de classification des métriques pour obtenir plus d’informations sur la manière de déterminer celle qui s’applique à votre situation. Pour vous faciliter la tâche, les définitions des métriques et des valeurs sont également fournies ci-dessous. ## Recalculer les scores des vulnérabilités CVSS 3.x Vous pouvez recalculer les scores de toutes les vulnérabilités associées à une [version de produit](/fr/helm/manage-vulnerabilities/rescore-vulnerabilities-in-bulk-or-individually.md) ou [recalculer le score de vulnérabilités individuelles](/fr/helm/manage-vulnerabilities/rescore-vulnerabilities-in-bulk-or-individually.md). ### Score CVSS de base Chaque vulnérabilité de la NVD est initialement assortie d’un score CVSS de base. Vous **ne pouvez pas modifier** ce score de base, mais vous pouvez modifier les scores temporel et environnemental en tenant compte de la situation propre à votre dispositif. Par défaut, chaque métrique de ces deux sections est définie sur « Non défini (X) », ce qui a l’incidence la plus importante sur le score CVSS. Toutes les définitions sont extraites du [calculateur CVSS 3.1](https://www.first.org/cvss/calculator/3.1).
Comment lire une chaîne de vecteur CVSS 3.1 ? Pour CVSS 3.1, chaque section d’une chaîne de vecteur, séparée par une barre oblique (/), correspond à l’une des sous-catégories des catégories Base et Temporel. Ainsi, une chaîne telle que celle-ci : CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L/E:X/RL:O/RC:X indique que le vecteur d’attaque est Réseau, que la complexité de l’attaque est Élevée, que les privilèges requis sont Aucun, que l’interaction de l’utilisateur est Requise, que la portée est Inchangée, et que les incidences sur la confidentialité, l’intégrité et la disponibilité sont Faibles. Elle indique également que la maturité du code d’exploitation est Non définie, que le niveau de correction est Correctif officiel et que le degré de confiance du rapport est Non défini.
#### Métriques d’exploitabilité
Vecteur d’attaque (AV) Cette métrique décrit le contexte dans lequel l’exploitation de la vulnérabilité est possible. Le score de base augmente à mesure que l’attaquant peut se trouver à distance (logique et physique) du composant vulnérable pour l’exploiter. * **Réseau (AV:N) :** Le composant vulnérable est relié à la pile réseau, et l’éventail des attaquants possibles dépasse celui des autres options indiquées, jusqu’à inclure l’ensemble d’Internet. Une telle vulnérabilité est souvent qualifiée d’« exploitable à distance » : l’attaque peut être exploitée au niveau du protocole depuis un ou plusieurs sauts réseau (par exemple, à travers un ou plusieurs routeurs). * **Adjacent (AV:A) :** Le composant vulnérable est relié à la pile réseau, mais l’attaque est limitée au niveau du protocole à une topologie logiquement adjacente. Cela peut signifier que l’attaque doit être lancée depuis le même réseau physique partagé (par exemple, Bluetooth ou IEEE 802.11) ou logique (par exemple, un sous-réseau IP local), ou depuis un domaine administratif sécurisé ou autrement limité (par exemple, MPLS ou un VPN sécurisé vers une zone réseau administrative). * **Local (AV:L) :** Le composant vulnérable n’est pas relié à la pile réseau, et l’attaquant doit pouvoir lire, écrire ou exécuter. L’attaquant peut soit exploiter la vulnérabilité en accédant localement au système cible (par exemple, au moyen d’un clavier ou d’une console) ou à distance (par exemple, via SSH), soit s’appuyer sur l’interaction d’une autre personne pour effectuer les actions nécessaires à l’exploitation (par exemple, en incitant un utilisateur légitime à ouvrir un document malveillant). * **Physique (AV:P) :** L’attaque exige que l’attaquant touche ou manipule physiquement le composant vulnérable. L’interaction physique peut être brève ou prolongée.
Complexité de l’attaque (AC) Cette métrique décrit les conditions indépendantes de la volonté de l’attaquant qui doivent être réunies pour exploiter la vulnérabilité. Ces conditions peuvent nécessiter la collecte d’informations supplémentaires sur la cible ou la présence de circonstances particulières liées au calcul. L’évaluation de cette métrique exclut toute exigence d’interaction de l’utilisateur pour exploiter la vulnérabilité. Si une configuration particulière est requise pour que l’attaque réussisse, les métriques de base doivent être évaluées en supposant que le composant vulnérable se trouve dans cette configuration. * **Faible (AC:L) :** Il n’existe ni conditions d’accès spécialisées ni circonstances atténuantes. Un attaquant peut s’attendre à réussir de manière répétée contre le composant vulnérable. * **Élevée (AC:H) :** La réussite de l’attaque dépend de conditions indépendantes de la volonté de l’attaquant. Autrement dit, l’attaque ne peut pas être menée avec succès à volonté : l’attaquant doit investir une quantité mesurable d’efforts dans la préparation ou l’exécution de l’attaque contre le composant vulnérable avant de pouvoir espérer réussir. Par exemple, l’attaque peut nécessiter que l’attaquant recueille des informations sur l’environnement dans lequel se trouve la cible ou le composant vulnérable, prépare l’environnement cible afin d’améliorer la fiabilité de l’exploitation, ou s’interpose sur le chemin réseau logique entre la cible et la ressource demandée par la victime afin de lire et/ou de modifier les communications réseau (par exemple, lors d’une attaque de l’intercepteur).
Privilèges requis (PR) Cette métrique décrit le niveau de privilèges que l’attaquant doit détenir avant de pouvoir exploiter la vulnérabilité. * **Aucun (PR:N) :** L’attaquant n’est pas autorisé avant l’attaque et n’a donc besoin d’aucun accès aux paramètres ou aux fichiers pour mener l’attaque. * **Faibles (PR:L) :** L’attaquant dispose de privilèges autorisés (c’est-à-dire requis) qui lui confèrent des capacités utilisateur de base, lesquelles ne peuvent normalement affecter que les paramètres et les fichiers appartenant à un utilisateur. Un attaquant disposant de privilèges faibles peut également être en mesure de n’avoir un impact que sur des ressources non sensibles. * **Élevés (PR:H) :** L’attaquant dispose de privilèges autorisés (c’est-à-dire requis) lui conférant un contrôle important (par exemple, des privilèges d’administration) sur le composant vulnérable, et lui permettant d’affecter les paramètres et les fichiers de l’ensemble du composant.
Interaction de l’utilisateur (UI) Cette métrique indique si une personne autre que l’attaquant doit intervenir pour que la compromission réussisse du composant vulnérable. Elle détermine si la vulnérabilité peut être exploitée uniquement à la volonté de l’attaquant, ou si un autre utilisateur (ou un processus déclenché par un utilisateur) doit intervenir d’une manière ou d’une autre. * **Aucune (UI:N) :** Le système vulnérable peut être exploité sans aucune interaction d’un utilisateur. * **Requise (UI:R) :** L’exploitation réussie de cette vulnérabilité nécessite qu’un utilisateur effectue une action avant que celle-ci puisse être exploitée.
Périmètre (S) Une attaque réussie affecte-t-elle un composant autre que le composant vulnérable ? Si c’est le cas, le score de base augmente et les métriques de confidentialité, d’intégrité et d’authentification doivent être évaluées par rapport au composant affecté. * **Inchangé (S:U) :** Une vulnérabilité exploitée ne peut affecter que les ressources gérées par la même autorité de sécurité. Dans ce cas, le composant vulnérable et le composant affecté sont identiques ou sont tous deux gérés par la même autorité de sécurité. * **Modifié (S:C) :** Une vulnérabilité exploitée peut affecter des ressources au-delà du périmètre de sécurité géré par l’autorité de sécurité du composant vulnérable. Dans ce cas, le composant vulnérable et le composant affecté sont différents et gérés par des autorités de sécurité différentes.
#### Métriques d’impact
Confidentialité (C) Cette métrique mesure l’impact d’une vulnérabilité exploitée avec succès sur la confidentialité des ressources informationnelles gérées par un composant logiciel. La confidentialité consiste à limiter l’accès aux informations et leur divulgation aux seuls utilisateurs autorisés, ainsi qu’à empêcher l’accès des utilisateurs non autorisés ou la divulgation à leur intention. * **Aucune (C:N) :** La confidentialité du composant affecté n’est pas compromise. * **Faible (C:L) :** La confidentialité est partiellement compromise. L’attaquant accède à certaines informations protégées, mais ne contrôle pas les informations obtenues, ou bien l’ampleur ou le type de perte est limité. La divulgation des informations n’entraîne pas de conséquence directe et grave pour le composant affecté. * **Élevée (C:H) :** La confidentialité est totalement compromise, et toutes les ressources du composant affecté sont divulguées à l’attaquant. Il peut également s’agir de l’accès à certaines informations protégées seulement, lorsque leur divulgation a un impact direct et grave.
Intégrité (I) Cette métrique mesure l’impact d’une vulnérabilité exploitée avec succès sur l’intégrité. L’intégrité désigne la fiabilité et l’exactitude des informations. * **Aucune (I:N) :** L’intégrité du composant affecté n’est pas compromise. * **Faible (I:L) :** La modification des données est possible, mais l’attaquant ne contrôle pas les conséquences d’une modification, ou l’ampleur des modifications est limitée. La modification des données n’a pas de conséquence directe et grave pour le composant affecté. * **Élevée (I:H) :** L’intégrité est totalement compromise, ou la protection est totalement perdue. Par exemple, l’attaquant peut modifier tout ou partie des fichiers protégés par le composant affecté. Il peut également ne pouvoir modifier que certains fichiers, mais ces modifications malveillantes auraient des conséquences directes et graves pour le composant affecté.
Disponibilité (A) Cette métrique mesure l’impact d’une vulnérabilité exploitée avec succès sur la disponibilité du composant affecté. Elle désigne la perte de disponibilité du composant lui-même, par exemple un service en réseau (Web, base de données, messagerie électronique). La disponibilité étant liée à l’accessibilité des ressources informationnelles, les attaques qui consomment de la bande passante réseau, des cycles processeur ou de l’espace disque affectent toutes la disponibilité du composant concerné. * **Aucune (A:N) :** La disponibilité du composant affecté n’est pas compromise. * **Faible (A:L) :** Les performances sont réduites ou la disponibilité des ressources est interrompue. Même si la vulnérabilité peut être exploitée à plusieurs reprises, l’attaquant ne peut pas refuser complètement le service aux utilisateurs légitimes. Les ressources du composant affecté sont soit partiellement disponibles en permanence, soit entièrement disponibles seulement par intermittence ; toutefois, dans l’ensemble, il n’en résulte aucune conséquence directe et grave pour le composant affecté. * **Élevée (A:H) :** La disponibilité est totalement perdue, ce qui permet à l’attaquant de bloquer entièrement l’accès aux ressources du composant affecté. Cette perte est soit maintenue (tant que l’attaquant poursuit l’attaque), soit persistante (la situation perdure après la fin de l’attaque). L’attaquant peut également réduire la disponibilité sans la supprimer totalement, mais cette perte entraîne une conséquence directe et grave pour le composant affecté (par exemple, l’attaquant ne peut pas interrompre les connexions existantes, mais peut empêcher l’établissement de nouvelles connexions ; il peut exploiter à plusieurs reprises une vulnérabilité qui, à chaque attaque réussie, ne divulgue qu’une faible quantité de mémoire, mais qui finit par rendre un service totalement indisponible).
### CVSS 3.1 : score temporel Les métriques temporelles mesurent l’état actuel des techniques d’exploitation ou de la disponibilité du code d’exploitation, l’existence de correctifs ou de solutions de contournement, ainsi que le niveau de confiance accordé à la description d’une vulnérabilité.
Maturité du code d’exploitation (E) Cette métrique mesure la probabilité que la vulnérabilité fasse l’objet d’une attaque. Elle est généralement fondée sur l’état actuel des techniques d’exploitation, la disponibilité du code d’exploitation ou l’existence d’exploitations actives « dans la nature ». * **Non définie (E:X) :** Il s’agit de la valeur par défaut. L’attribution de cette valeur indique que les informations disponibles ne suffisent pas pour choisir l’une des autres valeurs. Elle n’a aucun effet sur le score temporel global ; autrement dit, elle a le même effet sur le score que la valeur Élevée. * **Existence d’un exploit non démontrée (E:U) :** Aucun code d’exploitation n’est disponible, ou l’exploitation est théorique. * **Code de preuve de concept (E:P) :** Un code d’exploitation de preuve de concept est disponible, ou la démonstration de l’attaque n’est pas réalisable sur la plupart des systèmes. Le code ou la technique ne fonctionne pas dans toutes les situations et peut nécessiter des modifications importantes de la part d’un attaquant compétent. * **Exploit fonctionnel disponible (E:F) :** Un code d’exploitation fonctionnel est disponible. Il fonctionne dans la plupart des situations où la vulnérabilité est présente. * **Élevée (E:H) :** Il existe du code d’exploitation autonome fonctionnel, ou aucune exploitation n’est nécessaire (déclenchement manuel) et les détails sont largement disponibles. Le code d’exploitation fonctionne dans toutes les situations ou est actuellement diffusé par un agent autonome (tel qu’un ver ou un virus). Les systèmes connectés au réseau sont susceptibles de faire l’objet de tentatives d’analyse ou d’exploitation. Le développement de l’exploitation a atteint le stade d’outils automatisés fiables, largement disponibles et faciles à utiliser.
Niveau de correction (RL) Cette métrique est un facteur important pour établir les priorités. En général, une vulnérabilité n’est pas corrigée au moment de sa publication initiale. Des solutions de contournement ou des correctifs à chaud peuvent fournir une correction provisoire jusqu’à la publication d’un correctif officiel ou d’une mise à niveau. Chacune de ces étapes fait baisser le score temporel, reflétant la diminution de l’urgence à mesure que la correction devient définitive. * **Non défini (RL:X) :** Il s’agit du paramètre par défaut. Attribuer cette valeur indique que les informations sont insuffisantes pour choisir l’une des autres valeurs et n’a aucun effet sur le score temporel global ; autrement dit, son effet sur le score est le même que celui de la valeur Indisponible. * **Correctif officiel (RL:O) :** Une solution complète du fournisseur est disponible. Le fournisseur a publié un correctif officiel ou une mise à niveau est disponible. * **Correctif temporaire (RL:T) :** Un correctif officiel, mais temporaire, est disponible. Cela inclut les cas où le fournisseur publie un correctif à chaud, un outil ou une solution de contournement temporaire. * **Solution de contournement (RL:W) :** Une solution non officielle, qui ne provient pas du fournisseur, est disponible. Dans certains cas, les utilisateurs de la technologie concernée créent leur propre correctif ou fournissent des étapes permettant de contourner la vulnérabilité ou d’en atténuer autrement les effets. * **Indisponible (RL:U) :** Aucune solution n’est disponible, ou il est impossible d’en appliquer une.
Niveau de confiance du rapport (RC) Cette métrique mesure le degré de confiance dans l’existence de la vulnérabilité et la crédibilité des détails techniques connus. Parfois, seule l’existence de vulnérabilités est rendue publique, sans détails précis. Par exemple, un impact peut être jugé indésirable, sans que sa cause profonde soit connue. Des recherches ultérieures peuvent corroborer la vulnérabilité et indiquer où elle pourrait se trouver, sans toutefois apporter de certitude. Enfin, la vulnérabilité peut être confirmée par une reconnaissance de l’auteur ou du fournisseur de la technologie concernée. L’urgence est plus élevée lorsqu’il est certain que la vulnérabilité existe. Cette métrique indique également le niveau de connaissances techniques dont disposent les attaquants potentiels. * **Non défini (RC:X) :** Attribuer cette valeur indique que les informations sont insuffisantes pour choisir l’une des autres valeurs et n’a aucun effet sur le score temporel global ; autrement dit, son effet sur le score est le même que celui de la valeur Confirmé. * **Inconnu (RC:U) :** Des rapports font état d’impacts indiquant la présence d’une vulnérabilité. Ils indiquent que la cause de la vulnérabilité est inconnue, ou divergent quant à sa cause ou à ses impacts. Les auteurs des rapports ne sont pas certains de la nature réelle de la vulnérabilité et les rapports sont peu fiables ; il est également difficile de déterminer si un score de base fixe peut s’appliquer compte tenu des divergences décrites. Par exemple, un rapport de bogue signale un plantage intermittent, impossible à reproduire, accompagné d’indices de corruption de la mémoire, ce qui laisse supposer un déni de service ou des impacts potentiellement plus graves. * **Raisonnable (RC:R) :** Des détails importants ont été publiés, mais les chercheurs ne sont pas entièrement certains de la cause profonde ou n’ont pas accès au code source pour confirmer toutes les interactions susceptibles d’entraîner le résultat. Il existe toutefois une confiance raisonnable dans la reproductibilité du bogue et la possibilité de vérifier au moins un impact (des exploits de démonstration peuvent le montrer). Par exemple, une analyse détaillée d’une vulnérabilité explique comment reproduire les résultats, éventuellement de façon obscurcie ou en laissant cette tâche au lecteur. * **Confirmé (RC:C) :** Il existe des rapports détaillés ou une reproduction fonctionnelle est possible (des exploits fonctionnels peuvent le démontrer). Le code source est disponible pour vérifier indépendamment les affirmations de la recherche, ou l’auteur ou le fournisseur du code concerné a confirmé la présence de la vulnérabilité.
### CVSS 3.1 : score environnemental Ces métriques permettent à l’analyste d’ajuster le score CVSS en fonction de l’importance de l’actif informatique concerné pour l’organisation de l’utilisateur, en tenant compte des contrôles de sécurité complémentaires ou de remplacement en place, ainsi que de la confidentialité, de l’intégrité et de la disponibilité. Il s’agit des équivalents modifiés des métriques de base ; leurs valeurs sont attribuées en fonction de l’emplacement du composant dans l’infrastructure de l’organisation. #### Métriques d’exploitabilité
Vecteur d’attaque (MAV) Cette métrique reflète le contexte dans lequel l’exploitation de la vulnérabilité est possible. Le score environnemental augmente à mesure que l’attaquant peut se trouver à distance (logique et physique) du composant vulnérable pour l’exploiter. * **Non défini (MAV:X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Réseau (MAV:N) :** Le composant vulnérable est connecté à la pile réseau et l’ensemble des attaquants potentiels dépasse les autres options répertoriées, pouvant s’étendre à l’ensemble d’Internet. Une telle vulnérabilité est souvent qualifiée d’« exploitable à distance » ; on peut considérer qu’elle est exploitable au niveau du protocole depuis un ou plusieurs sauts réseau. * **Réseau adjacent (MAV:A) :** Le composant vulnérable est connecté à la pile réseau, mais l’attaque est limitée, au niveau du protocole, à une topologie logiquement adjacente. Cela peut signifier que l’attaque doit être lancée depuis le même réseau physique partagé (par exemple, Bluetooth ou IEEE 802.11) ou le même réseau logique (par exemple, un sous-réseau IP local), ou depuis un domaine administratif sécurisé ou autrement limité (par exemple, MPLS ou un VPN sécurisé). * **Local (MAV:L) :** Le composant vulnérable n’est pas connecté à la pile réseau et le chemin d’attaque repose sur des capacités de lecture, d’écriture ou d’exécution. L’attaquant exploite la vulnérabilité soit en accédant au système cible localement (par exemple, au clavier ou à la console), soit à distance (par exemple, via SSH) ; ou bien il compte sur l’interaction d’une autre personne pour effectuer les actions nécessaires à l’exploitation (par exemple, en incitant un utilisateur légitime à ouvrir un document malveillant). * **Physique (MAV:P) :** L’attaque exige que l’attaquant touche ou manipule physiquement le composant vulnérable. L’interaction physique peut être brève ou prolongée.
Complexité de l’attaque (MAC) Cette métrique décrit les conditions indépendantes de la volonté de l’attaquant qui doivent être réunies pour exploiter la vulnérabilité. Ces conditions peuvent nécessiter la collecte d’informations supplémentaires sur la cible ou la présence de circonstances particulières liées au calcul. L’évaluation de cette métrique exclut toute exigence d’interaction de l’utilisateur pour exploiter la vulnérabilité. Si une configuration particulière est requise pour que l’attaque réussisse, les métriques de base doivent être évaluées en supposant que le composant vulnérable se trouve dans cette configuration. * **Non défini (MAC:X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Faible (MAC:L) :** Aucune condition d’accès particulière ni circonstance atténuante n’existe. L’attaquant peut s’attendre à réussir de manière reproductible contre le composant vulnérable. * **Élevée (MAC:H) :** La réussite de l’attaque dépend de conditions indépendantes de la volonté de l’attaquant. Autrement dit, l’attaque ne peut pas réussir à la demande : l’attaquant doit consacrer des efforts mesurables à la préparation ou à l’exécution de l’attaque contre le composant vulnérable avant de pouvoir espérer réussir. Par exemple, l’attaquant peut devoir recueillir des informations sur l’environnement où se trouve la cible ou le composant vulnérable, préparer cet environnement pour rendre l’exploitation plus fiable, ou s’interposer dans le chemin réseau logique entre la cible et la ressource demandée par la victime afin de lire et/ou modifier les communications réseau (par exemple, lors d’une attaque de l’homme du milieu).
Privilèges requis (MPR) Cette métrique décrit le niveau de privilèges que l’attaquant doit détenir avant de pouvoir exploiter la vulnérabilité. * **Non défini (MPR:X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Aucun (MPR:N) :** L’attaquant n’est pas autorisé avant l’attaque et n’a donc besoin d’aucun accès aux paramètres ou aux fichiers pour mener l’attaque. * **Faible (MPR:L) :** L’attaquant dispose d’autorisations (c’est-à-dire qu’il doit disposer) lui conférant les capacités de base d’un utilisateur, qui ne lui permettraient normalement d’agir que sur les paramètres et les fichiers appartenant à un utilisateur. Un attaquant disposant de privilèges faibles peut également être en mesure de causer un impact uniquement sur des ressources non sensibles. * **Élevé (MPR:H) :** L’attaquant dispose d’autorisations (c’est-à-dire qu’il doit disposer) lui conférant un contrôle important (par exemple, administratif) sur le composant vulnérable, susceptible d’affecter les paramètres et les fichiers à l’échelle du composant.
Interaction de l’utilisateur (MUI) Cette métrique indique si une personne autre que l’attaquant doit intervenir pour que la compromission réussisse du composant vulnérable. Elle détermine si la vulnérabilité peut être exploitée uniquement à la volonté de l’attaquant, ou si un autre utilisateur (ou un processus déclenché par un utilisateur) doit intervenir d’une manière ou d’une autre. * **Non défini (MUI:X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Aucune (MUI:N) :** Le système vulnérable peut être exploité sans aucune interaction de la part d’un utilisateur. * **Requise (MUI:R) :** L’exploitation réussie de cette vulnérabilité nécessite qu’un utilisateur effectue une action avant que celle-ci puisse être exploitée.
Périmètre (MS) Une attaque réussie affecte-t-elle un composant autre que le composant vulnérable ? Si c’est le cas, le score de base augmente et les métriques de confidentialité, d’intégrité et d’authentification doivent être évaluées par rapport au composant affecté. * **Non défini (MS:X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Inchangé (MS:U) :** Une vulnérabilité exploitée ne peut affecter que les ressources gérées par la même autorité de sécurité. Dans ce cas, le composant vulnérable et le composant affecté sont identiques, ou sont tous deux gérés par la même autorité de sécurité. * **Modifié (MS:C) :** Une vulnérabilité exploitée peut affecter des ressources situées au-delà du périmètre de sécurité géré par l’autorité de sécurité du composant vulnérable. Dans ce cas, le composant vulnérable et le composant affecté sont distincts et gérés par des autorités de sécurité différentes.
#### Métriques d’impact
Impact sur la confidentialité (MC) Cette métrique mesure l’impact d’une vulnérabilité exploitée avec succès sur la confidentialité des ressources informationnelles gérées par un composant logiciel. La confidentialité consiste à limiter l’accès aux informations et leur divulgation aux seuls utilisateurs autorisés, ainsi qu’à empêcher l’accès des utilisateurs non autorisés ou la divulgation à leur intention. * **Non défini (MC:X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Aucun (MC:N) :** Il n’y a aucune perte de confidentialité au sein du composant affecté. * **Faible (MC:L) :** Il y a une certaine perte de confidentialité. L’accès à certaines informations à diffusion restreinte est obtenu, mais l’attaquant ne contrôle ni les informations obtenues ni l’ampleur ou la nature de la perte, qui reste limitée. La divulgation des informations n’entraîne pas de perte directe et grave pour le composant affecté. * **Élevé (MC:H) :** La confidentialité est totalement compromise, de sorte que toutes les ressources du composant affecté sont divulguées à l’attaquant. Il est également possible que l’accès obtenu ne porte que sur certaines informations à diffusion restreinte, mais que leur divulgation ait des conséquences directes et graves.
Impact sur l’intégrité (MI) Cette métrique mesure l’impact d’une vulnérabilité exploitée avec succès sur l’intégrité. L’intégrité désigne la fiabilité et l’exactitude des informations. * **Non défini (X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Aucun :** Il n’y a aucune perte d’intégrité au sein du composant affecté. * **Faible :** La modification des données est possible, mais l’attaquant ne contrôle pas les conséquences d’une modification, ou l’ampleur des modifications est limitée. La modification des données n’a pas d’impact direct et grave sur le composant affecté. * **Élevé :** L’intégrité est totalement compromise, ou la protection est entièrement perdue. Par exemple, l’attaquant peut modifier tout ou partie des fichiers protégés par le composant affecté. Il est également possible que seuls certains fichiers puissent être modifiés, mais qu’une modification malveillante ait des conséquences directes et graves pour le composant affecté.
Impact sur la disponibilité (MA) Cette métrique mesure l’impact d’une vulnérabilité exploitée avec succès sur la disponibilité du composant affecté. Elle désigne la perte de disponibilité du composant lui-même, par exemple un service en réseau (Web, base de données, messagerie électronique). La disponibilité étant liée à l’accessibilité des ressources informationnelles, les attaques qui consomment de la bande passante réseau, des cycles processeur ou de l’espace disque affectent toutes la disponibilité du composant concerné. * **Non défini (MA:X) :** La valeur attribuée à la métrique de base correspondante est utilisée. * **Aucun (MA:N) :** Il n’y a aucun impact sur la disponibilité au sein du composant affecté. * **Faible (MA:L) :** Les performances sont réduites ou la disponibilité des ressources est interrompue. Même si la vulnérabilité peut être exploitée à plusieurs reprises, l’attaquant ne peut pas empêcher complètement les utilisateurs légitimes d’accéder au service. Les ressources du composant affecté sont soit partiellement disponibles en permanence, soit entièrement disponibles seulement par intermittence ; dans l’ensemble, cela n’entraîne pas de conséquences directes et graves pour le composant affecté. * **Élevé (MA:H) :** La disponibilité est totalement perdue : l’attaquant peut empêcher complètement l’accès aux ressources du composant affecté. Cette perte est soit maintenue (tant que l’attaquant poursuit l’attaque), soit persistante (la situation perdure même après la fin de l’attaque). L’attaquant peut également réduire la disponibilité sans la supprimer complètement, mais cette perte a des conséquences directes et graves pour le composant affecté (par exemple, l’attaquant ne peut pas interrompre les connexions existantes, mais peut empêcher l’établissement de nouvelles connexions ; l’attaquant peut exploiter à répétition une vulnérabilité qui, à chaque attaque réussie, ne divulgue qu’une faible quantité de mémoire, mais qui, après plusieurs exploitations, rend le service totalement indisponible).
#### Modificateurs du sous-score d’impact
Exigence de confidentialité (CR) Cette métrique mesure le degré de confiance dans l’existence de la vulnérabilité et la crédibilité des détails techniques connus. Parfois, seule l’existence de vulnérabilités est rendue publique, sans détails précis. Par exemple, un impact peut être jugé indésirable, sans que sa cause profonde soit connue. Des recherches ultérieures peuvent corroborer la vulnérabilité et indiquer où elle pourrait se trouver, sans toutefois apporter de certitude. Enfin, la vulnérabilité peut être confirmée par une reconnaissance de l’auteur ou du fournisseur de la technologie concernée. L’urgence est plus élevée lorsqu’il est certain que la vulnérabilité existe. Cette métrique indique également le niveau de connaissances techniques dont disposent les attaquants potentiels. * **Non défini (CR:X) :** L’attribution de cette valeur indique que les informations sont insuffisantes pour choisir l’une des autres valeurs et n’a aucun effet sur le score environnemental global ; elle a le même effet sur le calcul du score que l’attribution de la valeur Moyenne. * **Faible (CR:L) :** Une perte de confidentialité n’aurait probablement qu’un effet négatif limité sur l’organisation ou les personnes qui lui sont associées (par exemple, les employés ou les clients). * **Moyenne (CR:M) :** L’attribution de cette valeur à la métrique n’aura aucune influence sur le score. * **Élevée (CR:H) :** La perte de confidentialité est susceptible d’avoir des effets néfastes catastrophiques sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients).
Exigence d’intégrité (IR) Ces métriques permettent à l’analyste de personnaliser le score CVSS en fonction de l’importance de l’intégrité de l’actif informatique concerné pour l’organisation de l’utilisateur, par rapport aux autres impacts. Cette métrique modifie le score environnemental en repondérant la métrique d’impact d’intégrité modifiée par rapport aux autres impacts modifiés. * **Non définie (IR:X) :** L’attribution de cette valeur indique que les informations sont insuffisantes pour choisir l’une des autres valeurs et n’a aucun effet sur le score environnemental global ; autrement dit, elle a le même effet sur le score que l’attribution de la valeur Moyenne. * **Faible (IR:L) :** La perte d’intégrité est susceptible d’avoir des effets néfastes limités sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients). * **Moyenne (IR:M) :** L’attribution de cette valeur à la métrique n’aura aucune influence sur le score. * **Élevée (IR:H) :** La perte d’intégrité est susceptible d’avoir des effets néfastes catastrophiques sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients).
Exigence de disponibilité (AR) Ces métriques permettent à l’analyste de personnaliser le score CVSS en fonction de l’importance de la disponibilité de l’actif informatique concerné pour l’organisation de l’utilisateur, par rapport aux autres impacts. Cette métrique modifie le score environnemental en repondérant la métrique d’impact de disponibilité modifiée par rapport aux autres impacts modifiés. * **Non définie (AR:X) :** L’attribution de cette valeur indique que les informations sont insuffisantes pour choisir l’une des autres valeurs et n’a aucun effet sur le score environnemental global ; autrement dit, elle a le même effet sur le score que l’attribution de la valeur Moyenne. * **Faible (AR:L) :** La perte de disponibilité est susceptible d’avoir des effets néfastes limités sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients). * **Moyenne (AR:M) :** L’attribution de cette valeur à la métrique n’aura aucune influence sur le score. * **Élevée (AR:H) :** La perte de disponibilité est susceptible d’avoir des effets néfastes catastrophiques sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients).
## CVSS 2.1 ### Score CVSS de base Chaque vulnérabilité dans le NVD est initialement assortie d’un score CVSS de base. Le groupe de métriques de base décrit les caractéristiques d’une vulnérabilité qui restent constantes dans le temps et d’un environnement utilisateur à l’autre. Les métriques Vecteur d’attaque, Complexité de l’accès et Authentification indiquent comment la vulnérabilité est exploitée et si des conditions supplémentaires sont nécessaires à son exploitation. Les trois métriques d’impact mesurent les effets directs qu’aurait l’exploitation d’une vulnérabilité sur un actif informatique. Ces impacts sont définis séparément comme le degré de perte de confidentialité, d’intégrité et de disponibilité. Par exemple, une vulnérabilité peut entraîner une perte partielle d’intégrité et de disponibilité, sans perte de confidentialité. Vous **ne pouvez pas modifier** ce score de base, mais vous pouvez modifier les scores temporel et environnemental en évaluant la situation propre à votre dispositif. Par défaut, chaque métrique de ces deux sections est définie sur Non définie (X), ce qui a l’incidence la plus importante sur le score CVSS. Toutes les définitions sont tirées du [calculateur CVSS v2 de first.org](https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator?calculator). Le score CVSS de base est divisé en métriques d’exploitabilité et d’impact. Les métriques d’exploitabilité comprennent le vecteur d’attaque, la complexité de l’accès et l’authentification, tandis que les métriques d’impact comprennent l’impact sur la confidentialité, l’intégrité et la disponibilité.
Lire une chaîne de vecteur CVSS 2 Pour CVSS 2, chaque section d’une chaîne de vecteur, séparée par une barre oblique (/), correspond à l’une des sous-catégories des catégories Base, Supplémentaire, Environnement et Menace. Ainsi, une chaîne telle que celle-ci : AV:N/AC:H/Au:N/C:P/I:P/A:P/E:POC/RL:OF/RC:UC indique que le **Vecteur d’attaque** est **Réseau**, **Complexité de l’accès** est **Élevée**, **Authentification** est **Aucune**, et que l’ **Impact sur la confidentialité** est **Partiel**, **Impact sur l’intégrité** est **Partiel**, et **Impact sur la disponibilité** est **Partiel**. Cela indique également que **Facilité d’exploitation** est **Code de preuve de concept**, **Niveau de correction** est **Correctif officiel**, et **Niveau de confiance du rapport** est **Non confirmé**. Notez que, CVSS 2 étant la première norme de notation de la gravité CVSS, sa version n’est pas indiquée.
#### Métriques d’exploitabilité
Vecteur d’accès (AV) * **Local (AV:L) :** Pour exploiter une vulnérabilité avec un accès local uniquement, l’attaquant doit disposer d’un accès physique au système vulnérable ou d’un compte local (shell). Parmi les exemples de vulnérabilités exploitables localement figurent les attaques sur les périphériques, telles que les attaques DMA via FireWire/USB, ainsi que les élévations de privilèges locales (par exemple, sudo). * **Réseau adjacent (AV:A) :** Pour exploiter une vulnérabilité avec un accès réseau adjacent, l’attaquant doit avoir accès au domaine de diffusion ou au domaine de collision du logiciel vulnérable. Les réseaux locaux incluent notamment le sous-réseau IP local, Bluetooth, IEEE 802.11 et le segment Ethernet local. * **Réseau (AV:N) :** Une vulnérabilité exploitable via le réseau signifie que le logiciel vulnérable est lié à la pile réseau et que l’attaquant n’a besoin ni d’un accès au réseau local ni d’un accès local. Une telle vulnérabilité est souvent qualifiée d’« exploitable à distance ». Le débordement de tampon RPC est un exemple d’attaque réseau.
Complexité d’accès (AC) * **Élevée (AC:H) :** Des conditions d’accès particulières sont nécessaires. Par exemple, dans la plupart des configurations, l’attaquant doit déjà disposer de privilèges élevés ou usurper l’identité de systèmes supplémentaires, en plus du système à l’origine de l’attaque (par exemple, détournement DNS). L’attaque repose sur des méthodes d’ingénierie sociale que des personnes averties détecteraient facilement. Par exemple, la victime doit effectuer plusieurs actions suspectes ou inhabituelles. En pratique, la configuration vulnérable est très rare. En présence d’une condition de concurrence, la fenêtre est très étroite. * **Moyenne (AC:M) :** Les conditions d’accès sont relativement particulières. En voici quelques exemples : l’attaquant est limité à un groupe de systèmes ou d’utilisateurs disposant d’un certain niveau d’autorisation, éventuellement non fiables. Des informations doivent être recueillies avant de pouvoir lancer une attaque réussie. La configuration concernée n’est pas celle par défaut et est peu courante (par exemple, une vulnérabilité présente lorsqu’un serveur authentifie les comptes utilisateur au moyen d’un mécanisme particulier, mais absente avec un autre mécanisme d’authentification). L’attaque nécessite un peu d’ingénierie sociale, susceptible de tromper occasionnellement des utilisateurs prudents (par exemple, des attaques par hameçonnage qui modifient la barre d’état d’un navigateur Web pour afficher un lien trompeur, ou la nécessité de figurer dans la liste de contacts d’une personne avant de lui envoyer un exploit par messagerie instantanée). * **Faible (AC:L) :** Aucune condition d’accès particulière ni circonstance atténuante n’est nécessaire. En voici quelques exemples : le produit concerné est généralement accessible à un large éventail de systèmes et d’utilisateurs, éventuellement anonymes et non fiables (par exemple, un serveur Web ou de messagerie accessible depuis Internet). La configuration concernée est la configuration par défaut ou est omniprésente. L’attaque peut être effectuée manuellement et nécessite peu de compétences ou de recherches d’informations supplémentaires. La « condition de concurrence » est facile à remporter (autrement dit, il s’agit techniquement d’une condition de concurrence, mais elle est facile à gagner).
Authentification (Au) * **Multiple (Au:M) :** L’exploitation de la vulnérabilité exige que l’attaquant s’authentifie au moins deux fois, même s’il utilise les mêmes identifiants à chaque fois. Par exemple, l’attaquant doit s’authentifier auprès d’un système d’exploitation et fournir également des identifiants pour accéder à une application hébergée sur ce système. * **Unique (Au:S) :** Une seule authentification est nécessaire pour accéder à la vulnérabilité et l’exploiter. * **Aucune (Au:N) :** Aucune authentification n’est nécessaire pour accéder à la vulnérabilité et l’exploiter.
#### Métriques d’impact
Impact sur la confidentialité (C) * **Aucun (C:N) :** La confidentialité du système n’est pas affectée. * **Partiel (C:P) :** Une quantité considérable d’informations est divulguée. L’accès à certains fichiers système est possible, mais l’attaquant ne contrôle pas les données obtenues, ou la portée de la perte est limitée. Par exemple, une vulnérabilité peut divulguer uniquement certaines tables d’une base de données. * **Complet (C:C) :** Toutes les informations sont divulguées, ce qui entraîne la révélation de tous les fichiers système. L’attaquant peut lire toutes les données du système (mémoire, fichiers, etc.).
Impact sur l’intégrité (I) * **Aucun (I:N) :** L’intégrité du système n’est pas affectée. * **Partiel (I:P) :** La modification de certains fichiers ou informations du système est possible, mais l’attaquant ne contrôle pas les éléments qui peuvent être modifiés, ou la portée de ses actions est limitée. Par exemple, des fichiers système ou applicatifs peuvent être écrasés ou modifiés, mais l’attaquant ne contrôle pas les fichiers concernés, ou ne peut modifier des fichiers que dans un contexte ou un périmètre limité. * **Complet (I:C) :** L’intégrité du système est totalement compromise. La protection du système est entièrement perdue, ce qui entraîne la compromission de l’ensemble du système. L’attaquant peut modifier n’importe quel fichier sur le système cible.
Impact sur la disponibilité (A) * **Aucun (A:N) :** La disponibilité du système n’est pas affectée. * **Partiel (A:P) :** Les performances sont réduites ou la disponibilité des ressources est interrompue. Par exemple, une attaque par inondation sur le réseau peut limiter le nombre de connexions réussies à un service Internet. * **Complet (A:C) :** La ressource concernée est totalement arrêtée. L’attaquant peut rendre la ressource entièrement indisponible.
### CVSS 2 : score temporel La menace posée par une vulnérabilité peut évoluer au fil du temps. Trois facteurs de ce type pris en compte par CVSS sont : la confirmation des détails techniques d’une vulnérabilité, l’état de sa remédiation et la disponibilité d’un code ou de techniques d’exploitation. Les métriques temporelles étant facultatives, elles comprennent chacune une valeur qui n’a aucun effet sur le score. Cette valeur est utilisée lorsque l’utilisateur estime que la métrique concernée ne s’applique pas et souhaite la « passer ».
Exploitabilité (E) * **Non défini (E:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Existence d’un exploit non démontrée (E:U) :** Aucun code d’exploitation n’est disponible, ou l’exploit est entièrement théorique. * **Code de preuve de concept (E:POC) :** Un code d’exploitation de preuve de concept ou une démonstration d’attaque, qui n’est pas pratique pour la plupart des systèmes, est disponible. Le code ou la technique ne fonctionne pas dans toutes les situations et peut nécessiter des modifications substantielles de la part d’un attaquant expérimenté. * **Exploit fonctionnel disponible (E:F) :** Un code d’exploitation fonctionnel est disponible. Il fonctionne dans la plupart des situations où la vulnérabilité est présente. * **Élevé (E:H) :** La vulnérabilité peut être exploitée par un code mobile autonome fonctionnel, ou aucun exploit n’est nécessaire (déclenchement manuel) et les détails sont largement disponibles. Le code fonctionne dans toutes les situations ou est activement diffusé par un agent mobile autonome (tel qu’un ver ou un virus).
Niveau de correction (RL) * **Non défini (RL:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Correctif officiel (RL:OF) :** Une solution complète du fournisseur est disponible. Le fournisseur a publié un correctif officiel ou une mise à niveau est disponible. * **Correctif temporaire (RL:TF) :** Un correctif officiel mais temporaire est disponible. Cela inclut les cas où le fournisseur publie un correctif provisoire, un outil ou une solution de contournement. * **Solution de contournement (RL:W) :** Une solution non officielle, qui ne provient pas du fournisseur, est disponible. Dans certains cas, les utilisateurs de la technologie concernée créent leur propre correctif ou fournissent des étapes permettant de contourner la vulnérabilité ou d’en atténuer autrement les effets. * **Indisponible (RL:U) :** Aucune solution n’est disponible, ou il est impossible d’en appliquer une.
Niveau de confiance du rapport (RC) * **Non défini (RC:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Non confirmé (RC:UC) :** Il existe une seule source non confirmée, ou éventuellement plusieurs signalements contradictoires. La validité des signalements est peu fiable. Une rumeur apparue dans les milieux clandestins de pirates informatiques en est un exemple. * **Non corroboré (RC:UR) :** Plusieurs sources non officielles sont disponibles, parmi lesquelles peuvent figurer des entreprises indépendantes spécialisées en sécurité ou des organismes de recherche. À ce stade, les détails techniques peuvent être contradictoires ou une autre ambiguïté peut subsister. * **Confirmé (RC:C) :** La vulnérabilité a été reconnue par le fournisseur ou l’auteur de la technologie concernée. Elle peut également être considérée comme « confirmée » lorsque son existence est établie par un événement externe, par exemple la publication d’un code d’exploitation fonctionnel ou de preuve de concept, ou une exploitation à grande échelle.
### CVSS 2 : score environnemental Les différences entre les environnements peuvent avoir une incidence considérable sur le risque qu’une vulnérabilité représente pour une organisation et ses parties prenantes. Le groupe de métriques environnementales CVSS prend en compte les caractéristiques d’une vulnérabilité liées à l’environnement informatique de l’utilisateur. Les métriques environnementales étant facultatives, elles comprennent chacune une valeur qui n’a aucun effet sur le score. Cette valeur est utilisée lorsque l’utilisateur estime que la métrique concernée ne s’applique pas et souhaite la « passer ». Le score environnemental CVSS est divisé en modificateurs généraux et en modificateurs du sous-score d’impact. Les modificateurs généraux comprennent le potentiel de dommages collatéraux et la distribution des cibles, tandis que les modificateurs du sous-score d’impact comprennent les exigences de confidentialité, d’intégrité et de disponibilité. #### **Modificateurs généraux**
Potentiel de dommages collatéraux (CDP) * **Non défini (CDP:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Aucun (CDP:N) :** Il n’existe aucun risque de perte de vies humaines, de dommages matériels, de perte de productivité ou de revenus. * **Faible (perte légère) (CPD:L) :** L’exploitation réussie de cette vulnérabilité peut entraîner de légers dommages corporels ou matériels. Elle peut aussi entraîner une légère perte de revenus ou de productivité pour l’organisation. * **Faible à moyen (CDP:LM) :** L’exploitation réussie de cette vulnérabilité peut entraîner des dommages corporels ou matériels modérés. Elle peut aussi entraîner une perte modérée de revenus ou de productivité pour l’organisation. * **Moyen à élevé (CDP:MH) :** L’exploitation réussie de cette vulnérabilité peut entraîner des dommages corporels ou matériels importants, ou des pertes importantes. Elle peut aussi entraîner une perte importante de revenus ou de productivité. * **Élevé (perte catastrophique) (CDP:H) :** L’exploitation réussie de cette vulnérabilité peut entraîner des dommages corporels ou matériels catastrophiques, ou des pertes catastrophiques. Elle peut aussi entraîner une perte catastrophique de revenus ou de productivité.
Distribution des cibles (TD) * **Non défini (CDP:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Aucune \[0 %] (TD:N) :** Aucun système cible n’existe, ou les cibles sont si spécialisées qu’elles ne se trouvent qu’en laboratoire. En pratique, 0 % de l’environnement est exposé au risque. * **Faible \[0–25 %] (TD:L) :** Des cibles sont présentes dans l’environnement, mais en petit nombre. Entre 1 % et 25 % de l’environnement total est exposé au risque. * **Moyenne \[26–75 %] (TD:M) :** Des cibles sont présentes dans l’environnement, mais en nombre moyen. Entre 26 % et 75 % de l’environnement total est exposé au risque. * **Élevée \[76–100 %] (TD:H) :** Des cibles sont présentes dans l’environnement en nombre important. Entre 76 % et 100 % de l’environnement total est considéré comme exposé au risque.
#### **Modificateurs du sous-score d’impact**
Exigence de confidentialité (CR) * **Non défini (CR:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Faible (CR:L) :** Une perte de confidentialité n’aurait probablement qu’un effet négatif limité sur l’organisation ou les personnes qui lui sont associées (par exemple, les employés ou les clients). * **Moyen (CR:M) :** La perte de confidentialité est susceptible d’avoir des effets négatifs graves sur l’organisation ou sur les personnes qui lui sont associées (par exemple, ses employés ou ses clients). * **Élevée (CR:H) :** La perte de confidentialité est susceptible d’avoir des effets néfastes catastrophiques sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients).
Exigence d’intégrité (IR) * **Non défini (IR:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Faible (IR:L) :** La perte d’intégrité est susceptible d’avoir des effets néfastes limités sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients). * **Moyen (IR:M) :** La perte d’intégrité est susceptible d’avoir des effets négatifs graves sur l’organisation ou sur les personnes qui lui sont associées (par exemple, ses employés ou ses clients). * **Élevée (IR:H) :** La perte d’intégrité est susceptible d’avoir des effets néfastes catastrophiques sur l’organisation ou sur les personnes qui lui sont associées (p. ex., ses employés ou ses clients).
Exigence de disponibilité (AR) * **Non défini (AR:ND) :** L’attribution de cette valeur à la métrique n’aura aucune incidence sur le score. Elle indique à l’équation d’ignorer cette métrique. * **Faible (AR:L) :** La perte de disponibilité est susceptible d’avoir des effets négatifs limités sur l’organisation ou sur les personnes qui lui sont associées (par exemple, ses employés ou ses clients). * **Moyen (AR:M) :** La perte de disponibilité est susceptible d’avoir des effets négatifs graves sur l’organisation ou sur les personnes qui lui sont associées (par exemple, ses employés ou ses clients). * **Élevé (AR:H) :** La perte de disponibilité est susceptible d’avoir des effets négatifs catastrophiques sur l’organisation ou sur les personnes qui lui sont associées (par exemple, ses employés ou ses clients).
\
--- # 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/manage-vulnerabilities/identify-and-prioritize-exploitable-vulnerabilities/understand-issue-severity-level/understand-the-cvss-vulnerability-scoring-system.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.