Lysbor

Glossaire de la sécurité des dépendances

Les sigles que vous croiserez dans un rapport de vulnérabilités, un audit NIS2 ou une discussion avec votre RSSI, expliqués en une phrase, puis en détail, puis avec une image.

copyleft
Famille de licences (GPL, AGPL…) qui obligent à redistribuer votre code sous la même licence si vous distribuez le logiciel.
Utiliser une bibliothèque GPL dans un logiciel vendu ou distribué peut vous obliger à en publier le code source. Les licences permissives (MIT, Apache, BSD) n'imposent pas cette contrainte. Lysbor signale les composants copyleft pour que la décision soit prise en connaissance de cause.
Pour se représenter la chose : C'est une recette libre à condition que tout plat qui l'utilise soit lui aussi une recette libre.
CVE
Identifiant public unique d'une vulnérabilité connue (Common Vulnerabilities and Exposures).
Chaque faille rendue publique reçoit un numéro du type CVE-2024-12345. Il permet à tous les outils et à tous les éditeurs de parler de la même faille. D'autres identifiants existent (GHSA pour GitHub, PYSEC pour Python…) : Lysbor les regroupe quand ils désignent la même faille.
Pour se représenter la chose : C'est le numéro de rappel d'un produit : un seul numéro, reconnu partout.
CVSS
Score de 0 à 10 qui mesure la gravité technique d'une vulnérabilité (Common Vulnerability Scoring System).
Le score combine la facilité d'exploitation (à distance ? sans compte ? sans action de l'utilisateur ?) et l'impact (vol de données, altération, indisponibilité). 9 à 10 : critique, 7 à 8,9 : élevée, 4 à 6,9 : moyenne, moins de 4 : faible. Le score mesure la gravité potentielle, pas la probabilité qu'on vous attaque : pour cela, voir EPSS et KEV.
Pour se représenter la chose : C'est la puissance d'une tempête annoncée, pas la probabilité qu'elle passe chez vous.
EPSS
Probabilité qu'une vulnérabilité soit exploitée dans les 30 prochains jours (Exploit Prediction Scoring System).
Calculée chaque jour par le FIRST à partir des attaques réellement observées. Une CVE avec un CVSS de 9 mais un EPSS de 0,1 % est rarement attaquée. Une CVE de CVSS 7 avec un EPSS de 60 % l'est massivement. Lysbor l'utilise pour trier ce qu'il faut corriger en premier.
Pour se représenter la chose : C'est la météo : la probabilité de pluie demain, mise à jour tous les jours.
KEV
Catalogue des vulnérabilités dont l'exploitation active est confirmée (Known Exploited Vulnerabilities, CISA).
L'agence américaine CISA y inscrit les failles utilisées dans de vraies attaques, avec une date limite de correction pour les administrations. Une vulnérabilité KEV n'est plus un risque théorique : elle doit passer devant toutes les autres.
Pour se représenter la chose : Ce n'est plus une alerte météo, c'est le cambrioleur déjà dans la rue.
MTTR
Délai moyen entre la détection d'une vulnérabilité et sa correction (Mean Time To Remediate).
C'est l'indicateur de résultat le plus parlant pour un auditeur : il montre que les failles ne restent pas ouvertes. Lysbor le calcule par sévérité à partir des dates de première détection et de disparition de chaque vulnérabilité.
NIS2
Directive européenne qui impose aux entreprises essentielles et importantes de maîtriser la sécurité de leur chaîne d'approvisionnement.
Son article 21 demande notamment la sécurité de la chaîne d'approvisionnement et une gestion documentée des vulnérabilités. En France, la transposition passe par la loi relative à la résilience des infrastructures critiques, dont l'ANSSI est l'autorité de référence. Le rapport PDF de Lysbor sert de preuve : inventaire, vulnérabilités, décisions, délais.
OSV
Base de données ouverte des vulnérabilités des paquets open source, maintenue par Google (Open Source Vulnerabilities).
Lysbor synchronise chaque heure les avis OSV pour les écosystèmes suivis (npm, PyPI, Maven, Go, Debian, Alpine…). Toutes les comparaisons de versions sont faites localement : vos inventaires ne sont jamais envoyés à un tiers.
purl
Identifiant standard d'un paquet : écosystème, nom et version (package URL).
Exemple : pkg:npm/lodash@4.17.21. Il permet de comparer sans ambiguïté un composant de votre SBOM avec les bases de vulnérabilités. Un composant sans purl ne peut pas être analysé.
SARIF
Format standard des rapports d'outils d'analyse de code et de configuration (Static Analysis Results Interchange Format).
Semgrep, Trivy, CodeQL, gitleaks, ZAP… produisent tous du SARIF. Lysbor l'ingère pour afficher, à côté des vulnérabilités de dépendances, les problèmes de code, de configuration et les secrets exposés.
SBOM
Inventaire des composants logiciels d'une application (Software Bill Of Materials).
Liste de toutes les bibliothèques et paquets tiers qu'une application embarque, avec leur version. C'est le point de départ de toute analyse : on ne peut pas surveiller ce qu'on n'a pas inventorié. Formats standards : CycloneDX et SPDX.
Pour se représenter la chose : C'est la liste des ingrédients sur un paquet alimentaire : sans elle, impossible de savoir si un ingrédient rappelé est dans votre produit.
SLA
Délai de correction que l'organisation s'engage à respecter selon la sévérité (Service Level Agreement).
Valeurs par défaut dans Lysbor : critique 7 jours, élevée 30 jours, moyenne 90 jours, faible 180 jours. Une vulnérabilité au-delà de son délai est « en retard » et remonte en tête des tableaux de bord et des synthèses.
VEX
Document qui indique, pour chaque vulnérabilité, si votre produit est réellement affecté (Vulnerability Exploitability eXchange).
Un SBOM liste les composants. Un VEX dit lesquels des vulnérabilités connues vous concernent vraiment, et pourquoi les autres ne s'appliquent pas (code non utilisé, protection en place…). Lysbor le génère à partir de vos décisions d'acceptation de risque.
Pour se représenter la chose : Le SBOM est la liste des ingrédients. Le VEX est la note du chef qui dit « oui il y a des arachides, mais elles sont dans un emballage séparé ».

Pour aller plus loin : les guides pratiques.