Industry Analysis

RSA Conference 2026: Supply Chain Themes

RSA Conference 2026 centered on AI governance, software supply chain regulation, and vendor consolidation. Here is the analyst view of what mattered.

Shadab Khan
Security Engineer
8 min read

RSA Conference 2026 at Moscone Center landed in the middle of an unusually active year for regulation, AI adoption, and enterprise security consolidation. The keynote stage reflected all three. Where past RSAs often treated software supply chain as a sidebar to broader cybersecurity conversations, 2026 saw it woven into nearly every major theme — regulatory sessions, board-level risk talks, AI governance panels, and even identity-focused keynotes circled back to the question of what you ship, how you ship it, and whether your attestations mean anything.

Here is the analyst take on what mattered for security leaders and the practitioners who have to translate those themes into a working program.

What were the dominant themes at RSA 2026?

Three kept recurring across keynotes, panels, and vendor messaging: AI-driven development at enterprise scale, the compliance implications of shipping software in a regulated economy, and vendor platform consolidation.

The AI thread dominated. The conference's keynote lineup included coverage of how AI is reshaping both the attacker and defender sides of the industry, and supply chain came up repeatedly in that context — not just as a place where AI causes new risks, but as the primary surface where AI governance decisions become real. If your developers are using coding assistants that suggest dependencies, your supply chain policy is your AI policy.

The compliance thread reflected the regulatory climate. The EU's Cyber Resilience Act, updated SEC disclosure guidance, and continued pressure from executive orders in the US on software assurance for federal suppliers combined to make "how do we demonstrate software integrity to auditors" one of the most common hallway questions.

The consolidation thread showed up in the Expo. The pattern that started at Black Hat — vendors converging on similar platform messaging — continued here at larger scale. Buyers expressed real fatigue with the breadth of overlapping claims, and a visible market shift toward "fewer platforms, deeper integrations" was evident in booth conversations.

How is AI changing the supply chain security conversation?

It has moved from novelty to operational concern. The 2024 and 2025 editions of RSA treated AI-assisted development as an emerging topic worth a handful of sessions. In 2026, it was a through-line.

The specific sub-themes that drew the most engagement: how to govern AI coding assistants in regulated environments, how to validate AI-generated code before it enters production, and how to secure the AI supply chain itself — the models, the training data, and the agent frameworks that consume external tools and APIs.

The governance conversation was especially pragmatic. Several sessions walked through concrete policy frameworks that mature organizations are adopting: treating AI-suggested dependencies as untrusted inputs requiring the same scrutiny as manually-added ones, requiring human approval for any AI-initiated pull request that touches build configuration or production infrastructure, and maintaining an audit log of which suggestions were accepted and why. None of this is exotic. It is the same rigor organizations have long applied to third-party contractors, now extended to machine collaborators.

The validation conversation was more technical. Speakers covered static analysis approaches for AI-generated code, the limits of LLM-based security review, and the growing importance of reachability analysis as a way to prioritize vulnerabilities in a codebase where code volume is growing faster than review capacity.

What was the regulatory and compliance storyline?

That supply chain transparency is rapidly becoming non-optional. The Cyber Resilience Act's timelines, the SEC's ongoing enforcement of cyber disclosure rules, and federal procurement requirements in multiple jurisdictions have converged to a point where organizations cannot plausibly treat SBOMs, VEX, and software attestations as "nice to have."

The sessions on this topic were the most densely attended of the conference. Practitioners came with specific questions: what level of SBOM granularity satisfies CRA requirements, how to produce VEX at scale without burying the security team, how to handle third-party components whose upstream suppliers are not yet CRA-ready. The answers were not always satisfying, but the direction was clear.

A recurring message from the regulatory panels: compliance and security are no longer easily separable in supply chain. The same artifacts — SBOMs, provenance attestations, VEX documents, vulnerability reports — serve both purposes. Organizations that invest in the operational capability to produce and consume these artifacts well are addressing both needs simultaneously. Organizations that continue treating compliance as a quarterly scramble produce artifacts that are technically compliant but operationally useless.

How did the vendor landscape look in 2026?

Crowded, convergent, and visibly consolidating. Walking the North and South Expo halls, the messaging repetition was striking — dozens of vendors offering what they describe as unified platforms for code-to-cloud application security, supply chain security, or software risk management.

Three observations held up. First, the feature sets really have converged. A buyer evaluating five vendors in this category will find that the marketing promises are nearly identical. The differentiation is in the depth of specific capabilities, the quality of the underlying analysis, and the integration ecosystem — none of which are easy to assess from a booth demo.

Second, the reachability conversation has matured. A year ago, "reachability" was a buzzword several vendors had bolted onto basic scanning. In 2026, a few vendors can now demonstrate genuine call-graph analysis, with concrete evidence of which findings were suppressed and why. Buyers are beginning to ask for that evidence during POCs, and vendors who cannot produce it are visibly losing deals.

Third, the mid-market vendors are under pressure. The platform plays at the top of the market are deepening their moats, and the developer-focused tools at the low end are growing fast. Vendors that sit in between — too expensive for small teams, not integrated enough for enterprises — had the quietest booths.

Which sessions produced the most practitioner signal?

The keynotes produced useful context but the real signal was in the practitioner tracks and the smaller sessions. A few areas worth revisiting when recordings publish.

The CRA implementation sessions, where speakers from European manufacturers walked through concrete case studies of how they are adapting their SDLC to produce CRA-compliant documentation. These talks were heavy on operational detail — which tools they adopted, where the gaps were, what the audit process actually looked like — and valuable in a way the keynote-level discussions were not.

The AI code assistant governance panels, which brought together representatives from regulated industries who are actively deploying these tools and struggling with the same questions. Even where the answers were incomplete, the problem framing was sharper than in public-facing coverage.

The sessions on upstream incident response, where speakers from organizations that were affected by major supply chain incidents over the past year walked through their detection, analysis, and remediation process. These were among the most concrete sessions at the conference and deserve wider attention than RSA's attendance numbers alone will give them.

What should security leaders take back to their teams?

Three calibrations. First, the pace of regulation is now faster than the pace of typical security program maturation. Waiting for requirements to settle before investing in SBOM tooling, VEX workflows, and provenance infrastructure is a losing strategy — the requirements are continuing to sharpen, and organizations that build the capability early will convert compliance deadlines into operational routine rather than emergency projects.

Second, AI code generation has moved beyond "emerging risk" and into the core of how supply chain security programs need to operate. If your team's policies still treat AI-assisted development as an edge case, they are already behind. The organizations that will handle this well are the ones that have unified their dependency policy, AI governance, and SDLC controls into a single framework rather than bolting AI rules onto an existing process.

Third, reachability is the capability that separates useful supply chain security from noise. Teams drowning in CVE lists, VEX paperwork, and alert fatigue need a way to focus on what actually runs in their environments. This is not optional anymore; it is the thing that makes the rest of the program tractable.

How Safeguard.sh Helps

Safeguard.sh is built around the themes that defined RSA Conference 2026. Our platform produces and consumes SBOMs, VEX documents, and provenance attestations in the formats that emerging regulations require — so your compliance artifacts are a byproduct of your operational security rather than a separate scramble. Our reachability engine answers the question RSA keynotes kept asking: of the vulnerabilities in your dependency tree, which ones can actually be exploited in your environment? And because Safeguard treats AI-generated code and AI-suggested dependencies as first-class inputs to the supply chain, your team can enforce a consistent policy whether the change came from a human developer or a coding assistant. For security leaders returning from RSA with a long list of priorities, Safeguard.sh is the operational layer that makes those priorities executable.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.