AWS Security Hub transforme les SBOM d’Inspector en inventaire logiciel d’organisation
Le 6 novembre 2026, AWS a annoncé que Security Hub fournit désormais un inventaire SBOM, consolidant les nomenclatures logicielles générées par Amazon Inspector pour EC2, ECR et Lambda en une vue organisationnelle à jour en continu. Pour une équipe sécurité, c’est la réponse à la question qui suit chaque CVE critique : où ce paquet est-il installé, et sur combien de ressources.
6 novembre 2026. AWS annonce que Security Hub fournit désormais un inventaire SBOM à l’échelle de l’organisation. Zéro configuration. L’inventaire se construit à partir des SBOM que Amazon Inspector génère déjà pour les instances EC2, les images ECR et les fonctions Lambda. 0 dollar. La fonctionnalité est incluse dans Security Hub Essentials, sans surcoût. Pourquoi c’est important : le SBOM passe du document ponctuel de conformité au registre opérationnel que l’on interroge quand une CVE critique tombe.
Le problème que cet inventaire résout : la question Log4j
Il y a un moment précis où un SBOM cesse d’être un livrable de conformité pour devenir un outil d’urgence. C’est le moment où une CVE critique est publiée et où un RSSI demande : « Où ce paquet est-il installé, et sur combien de ressources ? »
Décembre 2021. La faille Log4Shell dans Log4j oblige des milliers d’équipes à fouiller leurs parcs à la main pour retrouver log4j-core dans des dépendances transitives. La réponse a pris des jours pour certaines organisations — non pas faute de données, mais faute d’un endroit unique où les données étaient déjà rassemblées. Chaque machine savait ce qu’elle exécutait ; personne ne savait le dire d’un coup pour tout le parc.
C’est exactement ce vide que l’inventaire SBOM de Security Hub vient combler. Amazon Inspector produisait déjà des SBOM pour les ressources qu’il scanne. Ce qui manquait, c’était une vue transversale. AWS assemble désormais ces SBOM en un registre organisationnel, mis à jour en continu, sans nouvelle instrumentation.
Ce que fait l’inventaire, concrètement
La page SBOM de Security Hub liste chaque paquet logiciel avec trois attributs : sa version, son type et le nombre de ressources sur lesquelles il est installé. Le filtre et le regroupement se font par attribut de paquet, par compte et par région. C’est la réponse directe à la question Log4j : tapez un nom de paquet, et vous obtenez l’empreinte d’installation dans toute l’organisation.
Sur la page de détail d’une ressource, un onglet Installed software liste chaque paquet présent sur cette machine, son type et sa version. L’objectif affiché par AWS est de permettre de juger la fonction et la criticité d’un paquet pendant qu’on trie une alerte — sans quitter l’outil pour interroger chaque hôte.
L’inventaire est aussi interrogeable par l’API de Security Hub, ce qui ouvre l’automatisation : un runbook qui, à chaque nouvelle CVE, interroge l’API, extrait la liste des ressources concernées et alimente un ticket de remédiation sans intervention manuelle.
# Interroger l'inventaire SBOM via l'API Security Hub
# Liste les paquets et leur empreinte (à adapter à votre SDK préféré)
aws securityhub list-software-packages \
--filter "name=log4j-core" \
--query 'SoftwarePackages[*].{Package:Name,Version:Version,Resources:InstallationCount}'Zéro configuration, mais une condition : Inspector
La promesse « sans configuration supplémentaire » mérite d’être lue précisément. L’inventaire ne demande aucun nouvel agent ni nouveau service : il se peuple automatiquement là où Amazon Inspector est activé. La condition est donc là, discrète mais réelle — pas d’Inspector, pas de SBOM, donc pas d’inventaire.
C’est une nuance qui compte au moment de budgéter. L’inventaire lui-même est inclus dans Security Hub Essentials sans coût additionnel. Mais il repose sur Inspector, un service d’évaluation des vulnérabilités facturé séparément selon la surface scannée (EC2, ECR, Lambda). Une organisation qui active l’inventaire sans avoir déjà déployé Inspector devra l’activer, et donc payer la couverture qui va avec.
La disponibilité suit celle de Security Hub : la fonctionnalité est offerte dans toutes les régions où le service est disponible. Aucune contrainte régionale particulière n’est annoncée au-delà de cette règle.
Ce que ce n’est pas : un inventaire, pas une remédiation
Il faut borner ce que la fonctionnalité fait et ne fait pas. L’inventaire SBOM répond à « où est installé quoi ». Il ne scanne pas les paquets, il ne corrèle pas les versions aux CVE, il ne produit pas de correctif. Ces trois missions restent celles d’Inspector, qui en amont détecte les vulnérabilités et génère les SBOM que Security Hub agrège ensuite.
La complémentarité est la bonne grille de lecture. Inspector détecte une vulnérabilité sur une ressource. Security Hub reçoit le finding et, désormais, sait en même temps quels autres paquets vivent sur cette ressource et combien d’autres ressources embarquent le même paquet. Le tri d’un finding ne se fait plus en aveugle : on sait immédiatement si la faille touche un paquet présent sur 3 machines ou sur 3 000.
Cette distinction est aussi une mise en garde contre un mauvais usage. Un inventaire n’est pas une politique de remédiation. Voir que openssl est installé sur 1 200 ressources ne dit rien du risque réel si ces 1 200 ressources sont déjà sous le correctif. L’inventaire donne la surface, pas le verdict — le verdict reste au croisement de l’inventaire et des findings.
Le contexte réglementaire : le SBOM devient un dû
L’annonce s’inscrit dans un mouvement plus large, que ce blog a déjà documenté : le Cyber Resilience Act (CRA) européen impose aux fabricants de produits numériques de fournir des SBOM pour leurs logiciels. La logique est la même des deux côtés de l’Atlantique — le SBOM passe de bonne pratique volontaire à obligation réglementaire.
AWS ne publie pas cette fonctionnalité pour la conformité seule. Mais elle tombe au bon moment : une organisation qui doit répondre à une exigence de traçabilité logicielle trouve dans l’inventaire Security Hub un moyen de produire la vue d’ensemble, là où la collecte manuelle de SBOM par équipe restait l’alternative coûteuse. Le sous-texte est commercial autant que technique : la conformité devient un argument d’adoption du service managé.
La vraie valeur n’est pourtant pas dans le livrable de conformité. Elle est dans la vitesse de réponse à incident. Un SBOM qu’on ne peut interroger qu’à la demande, par équipe, ne sert à rien le jour où une CVE critique exige une réponse en heures. Un inventaire organisationnel, interrogeable par API, change la nature de la question : de « comment retrouver ce paquet » à « combien de ressources corriger, dans quel ordre ».
Verdict
L’inventaire SBOM de Security Hub est une fonctionnalité de consolidation, pas une révolution technique. AWS n’invente rien : il agrège des SBOM qu’Inspector produisait déjà, et il le fait bien — zéro configuration, API ouverte, coût nul sous Essentials.
Si vous utilisez déjà Amazon Inspector et Security Hub, activez la vue sans hésiter : le coût est nul et le gain opérationnel est immédiat, notamment le jour où une CVE critique vous demande de localiser un paquet en minutes. Si vous n’utilisez pas Inspector, le calcul est différent : l’inventaire est la partie gratuite d’un édifice payant, et la décision doit porter sur la valeur de la couverture Inspector elle-même, pas sur la vue SBOM qu’elle débloque. Si vous opérez hors d’AWS, retenez la leçon de conception plutôt que le produit : l’argument qui compte n’est pas le SBOM, c’est l’inventaire interrogeable en continu — cherchez l’équivalent dans votre propre écosystème. La règle à retenir : un SBOM qui ne se laisse pas interroger d’un coup sur tout le parc ne vaut guère mieux qu’une feuille de calcul.