The Industry Is Exhausted From Fighting Fires

One particular conversation stood out more than almost any other on the show floor. A security leader, someone who has seen it all, when asked what is a key challenge they face with open source security, looked up, and said something that stuck with us: “I’m just tired of getting emergency calls on my time off”.

That sentiment likely wasn’t unique to him. Across the show floor, security professionals are voicing the same frustration: the work never stops, and the remediation never shrinks. Patch this, triage that, respond, repeat. It’s not that teams aren’t working hard but that the model itself keeps generating more work than it resolves.

What gets talked about less, though, is the upstream question: why are teams perpetually in reactive mode in the first place? The answer often starts much earlier in the process than most people think.

When the foundation you’re building on carries unexamined risk from the start, downstream patching can only do so much. The path to fewer emergency calls isn’t necessarily faster response but rather reducing what needs to be responded to in the first place.

“We Don’t Use Open Source” — Said No One, Actually

One of the more revealing patterns at RSAC 2026 was a simple question we kept asking attendees: How do you manage your open source usage?

The initial answers were sometimes surprising. “We don’t really use open source,” was said more than a few times.

Then came the follow-up questions. What languages are your teams coding in? What does your build pipeline look like? What libraries are in your applications?

And then the light bulb moment: “Oh. I guess we do use open source. A lot of it.”

This shows just how deeply open source has become the invisible infrastructure of modern software. It’s everywhere, and it’s often untracked. The problem isn’t that teams are using open source, it’s that many organizations lack full visibility into what they’re running, where it came from, and what known risks it carries.

You can’t secure what you can’t see. And at RSAC 2026, it was clear that a significant portion of the industry is still working on that basic visibility problem.

AI Was Everywhere. The Security Around It? Less So.

No recap of RSAC 2026 would be complete without addressing the elephant (or more accurately, the entire herd of elephants in the room): artificial intelligence (AI).

AI dominated the conference. Vendor booths, session tracks, hallway conversations — it was impossible to go 5 minutes without the topic coming up. That’s not surprising. What was surprising, and a little alarming, was a pattern that emerged when Activators talked with teams who had already rolled out AI agents and tooling inside their organizations.

The sequence went something like this: business needs identified, AI tools adopted, teams integrated and moving fast. And then, somewhere downstream, someone asks: wait, what open source packages is this AI system actually pulling in? Has anyone audited the dependencies in this model pipeline? Do we know what’s running underneath all of this?

The answer, far too often, was no.

Teams are implementing AI at speed and understandably so, given competitive pressures. But the open source software supply chain sitting beneath those AI systems is, in many cases, entirely unexamined. The attack surface that comes with AI-adjacent open source packages is real, it’s growing, and the industry is only beginning to reckon with it.

It was the most energizing topic on the floor. It was also quietly one of the most concerning.

A Different Kind of Conversation: The Curated Catalog

Amid all of this, some of the most meaningful conversations we had at RSAC centered on a different approach entirely with one that starts before the vulnerabilities pile up.

When we talked with attendees about the ActiveState Curated Catalog, something shifted in those conversations. Rather than the familiar back-and-forth about patching strategies and CVE backlogs, people started talking about what it would mean to start from a place of confidence with a pre-vetted, actively maintained collection of 79 million secure open source components in 12+ languages that are known-good from the moment they’re pulled in.

For teams already feeling the weight of reactive security, that idea landed with genuine relief as they saw the path to shrinking the surface area of the problem before it ever reaches the triage queue.

The AI connection was hard to miss, too. As teams grapple with the open source complexity introduced by AI tooling and agent frameworks, the appeal of a curated, verified foundation becomes even more relevant. When you don’t have full visibility into what your AI systems are pulling in, having a trusted catalog to anchor to is exactly the kind of proactive control people are looking for.

The Through-Line: Proactive vs. Reactive

If there’s a single thread connecting all of these conversations, from the burnout, the open source blind spots, to the AI security gap, it’s the tension between reactive and proactive security.

The industry has spent years getting very, very good at responding to problems. Incident response, patch management, and CVE triage are mature disciplines. But the energy at RSAC 2026 suggested that people are starting to recognize the ceiling of the reactive approach. You cannot patch your way to a secure organization. You cannot triage your way out of a software supply chain problem that was baked in before the first line of code was deployed.

The conversations that we’re starting to hear are about what it means to be intentional from the start. Clean, verified, known-good open source as the baseline. Visibility into dependencies before they become vulnerabilities. Security built into the foundation rather than bolted on after the fact.

RSAC 2026 made one thing clear: the industry knows what the problems are. The next question is whether we’re ready to change the patterns that keep creating them.

If you’re ready to break the reactive remediation cycle, let’s talk.