Référence CRA

Les identifiants de composants

Cible principale :Cyber

Publié le

Tout le dispositif repose sur une opération apparemment triviale : relier un composant de votre SBOM à une vulnérabilité publiée. C’est là que se joue la fiabilité de l’ensemble, et c’est là que la plupart des dispositifs échouent.

Les identifiants disponibles

PURL — package URL

Identifiant canonique par écosystème, de la forme pkg:type/namespace/name@version?qualifiers.

pkg:maven/org.example/http-client@5.3.1
pkg:npm/%40scope/package@1.2.3
pkg:pypi/requests@2.32.3
pkg:golang/github.com/example/mod@v1.4.0
pkg:deb/debian/openssl@3.0.11-1~deb12u2?arch=amd64

À privilégier systématiquement. Le PURL est déterministe : il décrit sans ambiguïté un paquet dans un écosystème donné, ce qui rend la corrélation exacte.

CPE — common platform enumeration

Identifiant historique du NVD, de la forme cpe:2.3:a:vendor:product:version:....

Nécessaire pour interroger le NVD, mais structurellement imprécis : le couple « fournisseur / produit » est saisi manuellement, avec des variantes orthographiques, des homonymies et des CPE manquants. C’est la cause numéro un des faux positifs et des faux négatifs.

SWID

Étiquettes d’identification logicielle normalisées, peu répandues hors de certains environnements d’entreprise.

Empreintes cryptographiques

SHA-256 ou équivalent, calculées sur l’artefact. Elles n’identifient pas un composant dans un référentiel, mais elles lient l’inventaire à l’objet réel — ce qui est indispensable pour qu’un SBOM soit une preuve et pas une déclaration.

OmniBOR / GitOID

Identifiants dérivés du contenu source, permettant une traçabilité fine jusqu’au fichier. Émergent, à surveiller pour les cas où la granularité fichier est nécessaire.

Le problème d’appariement

Trois défaillances typiques :

Défaillance Exemple Conséquence
Faux positif par homonymie Deux produits de fournisseurs différents portant le même nom Alerte sur un composant que vous n’avez pas
Faux négatif par CPE manquant Une vulnérabilité publiée sans CPE, ou avec un CPE erroné Vulnérabilité réelle non détectée
Faux positif par version Une correction rétroportée par une distribution sans changement de numéro amont Alerte sur une version en réalité corrigée

Le troisième cas est particulièrement pénible : les distributions Linux corrigent massivement par rétroportage, en conservant le numéro de version amont. Un scanner qui ne connaît pas la distribution signale des centaines de vulnérabilités déjà corrigées.

Comment fiabiliser

  1. Exiger un purl valide sur chaque composant, et faire échouer la construction en dessous d’un seuil de couverture.
  2. Interroger les bases par écosystème — OSV en premier lieu — plutôt que de tout corréler par CPE.
  3. Renseigner les métadonnées de distribution lorsque le composant vient d’un paquet système, pour que l’outil applique la bonne base de correctifs.
  4. Conserver les empreintes, pour pouvoir vérifier a posteriori qu’un SBOM décrit bien l’artefact livré.
  5. Documenter les exceptions d’appariement en VEX plutôt qu’en supprimant l’alerte : une alerte supprimée disparaît, une alerte documentée reste traçable.

Le lien avec les faux positifs

La qualité des identifiants détermine directement le volume de bruit que subiront les équipes. C’est un investissement d’infrastructure, pas un réglage d’outil : voir Maîtriser les faux positifs.