Build1 publisher3 min readPublished
AWS gives software supply chain its own Security Hub category, with two vendors in it
Security Hub Extended now pipes Chainguard and Socket findings into the same OCSF stream as endpoint and identity signals. Two curated partners is a category, not a market.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Security Hub Extended now offers Supply Chain Security as its tenth category, with Chainguard and Socket as the curated partners.
- AWS states that when both partners are activated through Security Hub Extended, their findings flow into Security Hub in OCSF (Open Cybersecurity Schema Framework) alongside everything else, so supply chain risk is correlated and prioritized next to endpoint, identity and cloud signals, and then routes out to downstream tools already integrated.
- AWS says most customers it spoke to at Black Hat had supply chain risk on their risk register but had not operationalized a solution, because doing so meant a standalone deployment, a new contract, a new console, and integration work their security team could not prioritize.
- AWS cites SolarWinds (compromised build system), Log4j (a single transitive dependency vulnerability at global scale) and the xz utils backdoor (a maintainer-compromise attack executed over years) as demonstrating different dimensions of software supply chain risk.
- Since February, AWS grew Security Hub Extended from 14 curated partners across 9 categories to 23 partners across 10 categories.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
AWS has added Supply Chain Security as the tenth category in Security Hub Extended, with Chainguard and Socket as the curated partners [1]. The consequence for operators is the plumbing rather than the vendors: AWS says findings from both land in Security Hub in OCSF alongside endpoint, identity and cloud signals, get correlated and prioritized there, and then route out to whatever downstream tools you have already wired up [2].
That relocation is the thing to evaluate. Dependency findings have historically lived in a build-tool console owned by a platform team; if they now arrive in the same queue as cloud and identity findings, ownership, on-call routing and suppression rules all change with them. AWS's stated reason for the category is friction, not capability. It says customers had supply chain risk on the register but had not operationalized anything because doing so meant a standalone deployment, a new contract, a new console, and integration work security teams could not prioritize [3]. It cites SolarWinds, Log4j and the xz utils backdoor as the three shapes of the problem [4].
The program itself has grown. Since February, Security Hub Extended went from 14 partners across 9 categories to 23 across 10 [5], which is nine additional partners and one additional category [6]. At Black Hat this month, 14 of those partners demoed live at the AWS booth [7], roughly 61 percent of the roster [8], four gave theater talks and ten appeared on SecurityLive [9]. AWS says the most common question at the booth was when Supply Chain Security was arriving [10].
Commercially, every Extended offering is pay-as-you-go on one bill with no required long-term commitment [11], and Private Offers cover the committed-term path: deeper discounts, spend aggregated across partners onto a single AWS bill, monthly or annual payment [12].
On substance, the two partners are doing different jobs. Chainguard rebuilds open source dependencies from source in a hardened, verified build process, and anything whose source it cannot verify never appears in its repository [13]. Chainguard's own research, as cited by AWS, claims rebuilding from source would have stopped 98 percent of known malicious packages from reaching production [14]; by that same accounting, 2 percent would still get through [15]. Socket analyzes what a package actually does and blocks malicious dependencies at install time rather than after a CVE is published days or weeks later, with reachability analysis to indicate which vulnerabilities are exploitable from your code [16]. Socket bills per distinct package checked rather than per build run [17].
If you already pay for software composition analysis, that second description should prompt an audit. Reachability analysis and dependency inventory are not novel line items, and AWS's own pitch for Socket is that database-keyed alerting is too slow [16] - which is an argument against a class of tool many teams are still renewing. The useful question is not whether to add supply chain findings to Security Hub, but which existing subscription you would cancel to pay for them. Install-time behavioral blocking and a rebuilt-from-source registry are distinguishable capabilities. A second CVE list is not.
Worth watching: whether OCSF normalization preserves enough context for an install-time block to be actionable in Security Hub rather than arriving as a low-signal finding; whether a two-partner category grows or stays a duopoly of AWS's choosing; and whether Private Offer aggregation genuinely consolidates spend or simply relocates it onto the AWS invoice.