AWS Security Hub Adds an SBOM Inventory Included in Essentials at No Extra Cost: It Shows Only Resources That Amazon Inspector Scans, New SBOMs Can Take Hours to Appear, and the Guide, Not the Announcement, Says Connected Azure Resources Are Covered

On November 6, 2026, AWS announced that AWS Security Hub now provides a software bill of materials (SBOM) inventory: a continuously updated, organization-wide list of the software packages installed on compute resources. Security Hub builds it from the SBOMs that Amazon Inspector already produces for Amazon EC2 instances, Amazon ECR container images and AWS Lambda functions, with no additional configuration. AWS says it is included in Security Hub Essentials at no additional cost, needs no new enablement and is available in every AWS Region where Security Hub is available. “No additional cost” applies to this inventory capability within Essentials; existing service charges still follow their respective pricing, so this is not a zero-cost deployment claim.

The announcement describes what the inventory shows. The SBOM page lists each package with its version, type and the number of resources where it is installed, and the list can be filtered and grouped by package attributes, account and Region. On a resource's detail page, an Installed software tab lists every package on that resource, so that an analyst can judge what the resource does and how critical it is while triaging a finding. The same inventory can be queried through the Security Hub API. The aim is to answer one question quickly: when a new vulnerability is disclosed, which resources contain the affected package.

The Security Hub user guide adds the conditions that decide what you will actually see. The inventory only covers resources that Amazon Inspector scans. If Inspector scans EC2 instances but not Lambda functions, the inventory contains software from EC2 instances only, and if Inspector is not enabled the page shows a message with an Enable Inspector button. "No additional configuration" therefore means no extra setup in Security Hub, and it assumes Inspector coverage is already in place. The guide also says the inventory is not limited to AWS: it covers virtual machines, container images and serverless functions, for example Microsoft Azure virtual machines and Azure Container Registry images, in cloud providers that you connect to Security Hub. The announcement mentions only the three AWS resource types.

Freshness and scope are stated with limits. Security Hub keeps the latest SBOM for each resource and removes a resource's software when the resource is terminated, deleted or leaves Inspector coverage, and it reconciles with Inspector on a schedule. After Inspector generates a new SBOM, the guide says the change can take a few hours to appear, so the inventory is not a live view. Administrator accounts can see software from all enabled accounts in their organization, while member accounts see only their own resources. One counting detail can confuse readers: a package appears once in the table however many resources it is on, and the summary charts count one installation per resource, so chart totals can exceed the number of rows. For example, one package on three resources is one row and three installations.

What the announcement does not say is also useful. It gives no limits on the number of resources or packages, no performance figures, and no statement about how complete an SBOM is for a given image or instance, which depends on what Inspector can detect. It does not say the inventory replaces vulnerability scanning or compliance reporting, and the guide describes it as a way to find resources with a package, understand a resource while triaging, and keep a record of the software supply chain for compliance programs. We did not test it.

Our reading: this is a modest but practical feature for security teams that already use Inspector and Security Hub. It turns scattered per-resource SBOMs into a searchable organization-wide view at no extra charge. Teams should confirm that Inspector covers every resource type they care about, expect a delay of hours, check which accounts their role can see, and treat the inventory as showing which scanned resources have an Inspector-detected package installed, not as proof that every package on every machine has been found.