AWS Security Hub turns Inspector’s SBOMs into an org-wide software inventory
On November 6, 2026, AWS announced that Security Hub now provides an SBOM inventory, consolidating the software bills of materials that Amazon Inspector generates for EC2, ECR, and Lambda into a continuously updated, organization-wide view. For security teams, it answers the question that follows every critical CVE: where is this package installed, and on how many resources.
November 6, 2026. AWS announces that Security Hub now provides an SBOM inventory across the organization. Zero configuration. The inventory is assembled from the SBOMs that Amazon Inspector already generates for EC2 instances, ECR container images, and Lambda functions. Zero cost. The feature ships inside Security Hub Essentials at no extra charge. Why it matters: the SBOM moves from a point-in-time compliance artifact to the operational register you query when a critical CVE lands.
The problem this solves: the Log4j question
There is a specific moment when an SBOM stops being a compliance deliverable and becomes an emergency tool. It is the moment a critical CVE is published and a CISO asks: “Where is this package installed, and on how many hosts?”
December 2021. The Log4Shell flaw in Log4j forced thousands of teams to hand-search their estates for log4j-core hiding in transitive dependencies. The answer took days at some organizations — not for lack of data, but for lack of a single place where the data was already gathered. Every machine knew what it ran; nobody could say it for the whole estate in one shot.
That is exactly the gap the Security Hub SBOM inventory closes. Amazon Inspector was already producing SBOMs for the resources it scans. What was missing was the cross-cutting view. AWS now stitches those SBOMs into an organization-wide register, updated continuously, with no new instrumentation.
What the inventory does, concretely
The SBOM page in Security Hub lists every software package with three attributes: its version, its type, and the number of resources it is installed on. You can filter and group by package attribute, by account, and by region. This is the direct answer to the Log4j question: type a package name and get its install footprint across the whole organization.
On a resource’s detail page, an Installed software tab lists every package on that machine, its type, and its version. The goal AWS states is to let you judge a package’s function and criticality while triaging a finding — without leaving the tool to query each host individually.
The inventory is also queryable through the Security Hub API, which opens the door to automation: a runbook that, on every new CVE, queries the API, extracts the list of affected resources, and files a remediation ticket with no manual step in between.
# Query the SBOM inventory through the Security Hub API
# (adapt the SDK to your language of choice)
aws securityhub list-software-packages \
--filter "name=log4j-core" \
--query 'SoftwarePackages[*].{Package:Name,Version:Version,Resources:InstallationCount}'Together, those three surfaces — the package list, the per-resource tab, and the API — map to three moments of an incident. The package list answers “how big is this?” the moment a CVE lands. The per-resource tab answers “what else runs next to it?” while you triage. And the API answers “can I automate this?” for the second and third time the same package shows up, because a one-off lookup that becomes a recurring ritual should become a runbook.
Zero configuration, but one condition: Inspector
The “no additional configuration” promise deserves a careful read. The inventory needs no new agent or new service: it populates automatically wherever Amazon Inspector is enabled. The condition is therefore there, discreet but real — no Inspector, no SBOM, and thus no inventory.
That nuance matters at budgeting time. The inventory itself is included in Security Hub Essentials at no additional cost. But it rides on Inspector, a vulnerability-assessment service billed separately by scanned surface (EC2, ECR, Lambda). An organization that turns on the inventory without already having deployed Inspector will have to enable it — and pay for the coverage that comes with it.
Availability follows Security Hub: the feature is offered in every Region where the service is available. No regional constraint is announced beyond that rule.
What it is not: an inventory, not remediation
It is worth bounding what the feature does and does not do. The SBOM inventory answers “what is installed where.” It does not scan packages, does not correlate versions to CVEs, and does not produce fixes. Those three jobs remain with Inspector, which upstream detects vulnerabilities and generates the SBOMs that Security Hub then aggregates.
Complementarity is the right frame. Inspector detects a vulnerability on a resource. Security Hub receives the finding and, now, also knows which other packages live on that resource and how many other resources carry the same package. Finding triage is no longer blind: you immediately know whether the flaw touches a package present on 3 machines or 3,000.
The distinction is also a caution against misuse. An inventory is not a remediation policy. Seeing openssl on 1,200 resources says nothing about real risk if those 1,200 resources are already patched. The inventory gives you the surface, not the verdict — the verdict still lives at the intersection of the inventory and the findings.
The regulatory backdrop: SBOMs are becoming a requirement
The announcement lands in a broader movement this blog has already documented: the EU’s Cyber Resilience Act (CRA) obliges manufacturers of digital products to provide SBOMs for their software. The pattern repeats in the United States, where the 2021 cybersecurity executive order already pushed federal suppliers toward SBOMs as a baseline. The logic is the same on both sides of the Atlantic — the SBOM moves from voluntary best practice to a regulatory obligation.
AWS is not shipping this feature for compliance alone. But the timing is right: an organization that must answer a software-traceability requirement finds in the Security Hub inventory a way to produce the whole view, where per-team manual SBOM collection remained the expensive alternative. The subtext is commercial as much as technical: compliance becomes an argument for adopting the managed service.
The real value is not in the compliance deliverable, though. It is in incident-response speed. An SBOM you can only query on demand, team by team, is useless on the day a critical CVE demands an answer in hours. An organization-wide, API-queryable inventory changes the nature of the question: from “how do we find this package” to “how many resources to fix, in what order.”
Verdict
The Security Hub SBOM inventory is a consolidation feature, not a technical revolution. AWS is not inventing anything: it aggregates SBOMs that Inspector already produced, and it does it well — zero configuration, an open API, and no cost under Essentials.
If you already run Amazon Inspector and Security Hub, enable the view without hesitation: the cost is zero and the operational gain is immediate, especially on the day a critical CVE asks you to locate a package in minutes. If you do not use Inspector, the calculus is different: the inventory is the free part of a paid edifice, and the decision should rest on the value of the Inspector coverage itself, not on the SBOM view it unlocks. If you operate outside AWS, take the design lesson rather than the product: what matters is not the SBOM but the continuously queryable inventory — look for the equivalent in your own ecosystem. The rule to remember: an SBOM you cannot query across the whole estate in one shot is barely better than a spreadsheet.