AWS re:Inforce 2026 was the first edition where supply chain security stopped being a parallel track and started bleeding into every other one. The networking sessions talked about signed IaC. The identity sessions talked about workload identity for build agents. The incident response sessions leaned on SBOM-driven scoping. The quiet message was that the supply chain is not a specialty anymore, it is a default concern, and AWS is rebuilding portions of its security toolchain around that assumption.
These are field notes from three days in Philadelphia, focused on the sessions that produced something actionable for enterprise customers. We cover the Inspector and ECR announcements, the customer stories that were genuinely instructive, and the gaps that the AWS team acknowledged in the hallway conversations. The notes are opinionated because the sessions were.
What did Inspector and ECR announce?
Inspector and ECR announced deeper provenance integration and a new container-scoped policy engine. Inspector v2 now correlates CVE findings with reachability data derived from the container image layers, so a Log4j finding in a base image that the application does not actually import is flagged at a lower severity than one in a directly called dependency. ECR gained a native SBOM generation pipeline that runs on push and supports both CycloneDX 1.7 and SPDX 3.0 output.
The policy engine is the interesting piece. Previously, blocking a vulnerable image at push time required a custom Lambda, an EventBridge rule, and a lot of IAM. The new policy engine supports declarative policies attached to the registry, so rules like "reject images with critical CVEs whose CVSS vector indicates network reachability" can be expressed in a dozen lines of YAML. Early customers reported a meaningful reduction in custom glue code, though the policy language is still limited compared with open-source equivalents like OPA.
What did the customer sessions reveal about signing at scale?
The customer sessions revealed that signing at scale is less about the cryptography and more about the key management story. Every customer on stage had converged on workload identity, specifically AWS OIDC federated to a transparency-log-backed signer, and had abandoned attempts to use long-lived keys. The crypto was solved years ago; the operational challenge was rotating trust anchors without breaking builds.
One particularly good session from a large e-commerce retailer walked through their migration from GPG-signed artifacts to Sigstore with a registry-side verification policy. The interesting detail was the rollout strategy: they ran both systems in parallel for eight months, with a dashboard that showed the gap between "signed with GPG" and "signed with Sigstore" for every service. The gap was the migration backlog, and watching it close gave the team confidence to flip the enforcing policy. That kind of operational transparency is underrated.
How is SBOM adoption trending in the field?
SBOM adoption is trending toward "every build produces an SBOM" but "every team knows what to do with one" is still a minority position. Several sessions discussed the gap. Generating SBOMs is now cheap, most build tools can emit them, and CycloneDX 1.7 tooling is mature enough for production. The hard part is wiring the SBOM into downstream decision-making: vulnerability tracking, license compliance, TPRM, and incident scoping.
The sessions that resonated were the ones that walked through the wiring. A healthcare customer showed a pipeline where every Kubernetes deployment referenced the SBOM of its image, the SBOM was stored in a central graph database, and incident response queries ran against that graph. When a new zero-day landed, the team could answer "which of our services are affected, and which of those actually expose the vulnerable code path?" in under ten minutes. That is the capability worth optimizing for, not SBOM generation itself.
What about the workload identity sessions?
The workload identity sessions pushed hard on IAM Roles Anywhere and EKS Pod Identity as the foundation for a build-to-deploy trust chain. The pattern is that every build agent gets a short-lived credential from OIDC, every artifact it produces is signed with a key bound to that credential, and every deployment target verifies the signature against the attestation log before running. No long-lived secrets anywhere in the chain.
The gap is that the pattern assumes a cloud-native build environment, and plenty of enterprises still have on-prem builders for good reasons. AWS acknowledged this in the hallway and pointed at IAM Roles Anywhere as the bridge. In practice, customers reported that IAM Roles Anywhere works well for steady-state loads but trips over the certificate rotation cadence, which needs more tooling before it is genuinely painless.
What was the quiet gap in the conference?
The quiet gap was AI-generated code. Several sessions gestured at coding agents and AI-assisted development, but none went deep on the supply chain implications. When we asked product managers in the hallway about reachability analysis for AI-generated dependencies, or about SBOMs that tag which components were added by an agent, the answers were a mix of "we are thinking about it" and "we expect the ecosystem to solve it." That is a gap that the independent tooling space, including the Safeguard platform, is filling, and it is worth tracking how AWS native tooling catches up over the next year.
How Safeguard Helps
Safeguard closes the gap re:Inforce surfaced by wiring SBOMs into the decision-making chain that matters. We ingest ECR-generated SBOMs on push, enrich them with reachability analysis so you know which CVEs are actually callable, and score every supplier through the TPRM module. Griffin AI flags AI-introduced components in your build pipeline and attaches agent attribution to the SBOM. Policy gates in CI, integrated with the new ECR policy engine, block deployments that fail your bar, and the incident response graph answers the "which services are affected" question in minutes rather than hours. You get the benefits the conference showcased without building the plumbing yourself.