Réconciliation SBOM et inventaire d'actifs en pratique

La réconciliation SBOM et inventaire d’actifs, c’est le travail quotidien d’associer ce qu’un software bill of materials dit livré à ce qu’un inventaire d’actifs dit en exécution. L’écart entre ces deux réponses est l’endroit où l’exposition réelle se cache, et toute file de CVE qui l’ignore classe d’abord les mauvais constats.

Cet article décrit comment VulnMonitor de CloudKey effectue la réconciliation SBOM et inventaire d’actifs, pour que la file de CVE colle aux systèmes que votre équipe opère réellement.

Ce que donne un SBOM

Un SBOM signé liste les composants et versions d’un artefact de build. Il est autoritaire pour cet artefact à ce moment de build.

Il ne dit pas quels hôtes exécutent cet artefact, dans quel environnement, derrière quels contrôles réseau, avec quels patchs appliqués depuis. Les SBOM seuls ne produisent pas une file CVE actionnable.

Ce que donne un inventaire d’actifs

Un inventaire vivant énumère les hôtes, équipements réseau, endpoints et identités que vous opérez, idéalement avec version, configuration et métadonnées d’atteignabilité.

Il ne dit pas avec confiance cryptographique quel artefact de build a atterri sur quel hôte. La dérive entre l’inventaire et la vérité est l’état par défaut.

Comment fonctionne la réconciliation SBOM et inventaire d’actifs

VulnMonitor effectue une réconciliation SBOM et inventaire d’actifs quotidienne :

• Pour chaque actif de l’inventaire, récupérer le hash SBOM le plus récent du pipeline de build qui a produit son artefact.
• Résoudre le SBOM en graphe de composants.
• Faire correspondre chaque CVE dans NVD au graphe de composants, pondéré par KEV et EPSS comme décrit dans notre article de priorisation.
• Filtrer par atteignabilité : un actif exposé sur Internet pèse plus qu’un interne, un actif à accès privilégié pèse plus qu’un sandboxé.

La sortie est une file CVE classée, restreinte aux actifs que votre équipe opère réellement, avec la chaîne de preuves traçable de bout en bout.

Où la réconciliation échoue, et ce que nous faisons

Trois modes d’échec apparaissent dans presque chaque déploiement :

• Un actif rapporte une version logicielle qui ne correspond à aucun SBOM produit par le pipeline de build. Marqué comme dérive, pas comme bruit.
• Un SBOM manque pour un composant que l’inventaire prouve tourner. Listé comme lacune de preuve, avec un propriétaire de remédiation.
• Un actif correspond à plusieurs SBOM candidats. Classé par horodatage de build, l’ambiguïté est remontée plutôt que tranchée en silence.

Aucun ne se résout par un scan plus profond. Ils se résolvent en fermant la boucle entre build et opérations, ce que le pipeline de réconciliation impose.

Ce que cela change pour votre file

Chaque CVE dans VulnMonitor arrive avec une réponse traçable à trois questions : quel actif est exposé, quel build a produit le composant vulnérable, et quel est le chemin d’atteignabilité qui transforme ce constat en risque.

Si un constat ne répond pas aux trois, c’est une lacune de preuve, pas un item de triage. Mélanger les deux dans la même file est le plus court chemin pour perdre le signal.