National Harbor drew thousands of security practitioners to Gartner's Security & Risk Summit this year, and ActiveState was there across the full program. Our CEO Abby Kearns and CRO Steve Ruggieri joined me on the floor, in the sessions, and in back-to-back analyst briefings across two days. Between the keynotes, breakout sessions, and one-on-ones, we came away with a clearer picture of where enterprise security thinking is right now and, maybe more importantly, where it is not.

A few honest observations before diving in: the show covers a wide range of content across maturity levels, and we only saw a slice of it. What we did see skewed toward security fundamentals and organizational basics. That is not necessarily a critique. If a significant portion of the attending audience is still working through foundational questions, that tells you something real about the state of the market. The problems we spend our days thinking about, specifically what happens to open source software governance when AI-generated code enters the picture at scale, are not yet center stage for every security organization. Some are still building the runway.

Here is what resonated, what surprised us, and what we think it means for where security and engineering leaders should be focusing right now.

Trust Is Becoming a Procurement Criterion

One of the more structured sessions we attended walked through Gartner's emerging Vendor Trust Index framework, a methodology for evaluating cybersecurity vendors across six dimensions: market relevance, financial stability, contract practices, customer experience, cybersecurity response, and offering alignment.

The headline number: Gartner predicts that 40% of organizations will exit a vendor due to trust failures by 2028. That is not a soft warning. It reflects a real shift in how security leaders are approaching their vendor portfolios. After years of stack sprawl and vendor consolidation cycles that never quite delivered, buyers are increasingly asking a different set of questions: How long has this company been in market? How do they behave at renewal? What happens when something goes wrong?

The criteria that came up most often in that framework are worth noting for anyone currently evaluating a software supply chain security partner. Time in market matters. Financial transparency matters. And the renewal experience, how a vendor treats you once they have your signature, is emerging as a leading indicator of long-term trust.

For organizations starting to think seriously about open source software governance, this framing has practical implications. A vendor that cannot demonstrate a continuous, multi-year track record of building and remediating open source components from source is asking you to extend trust they have not yet earned.

AI Security Is Splitting Into Two Tracks. Most Teams Are Running One.

The session on securing AI that enterprises build and employees use laid out a framework that we found useful. The presenter made a clear distinction between AI governance, managing the model lifecycle, usage policies, and data exposure, and runtime enforcement, detecting and stopping AI-generated behavior that goes wrong in production. Both tracks are necessary. Most organizations are still on the governance track, figuring out what their employees are using and how to create some structure around it.

A line that landed: agent proliferation is becoming the new CSV file problem. Employees are creating overlapping AI agents without coordination, accumulating risk in unstructured repositories, and in some cases uploading significant volumes of organizational data on personal licenses. The security implication is not just data loss. It is an expanding open source software dependency footprint that exists entirely outside any governance process the security team has established.

This connects directly to a pattern we have been calling out for some time. When non-technical employees, marketers, operations staff, analysts, use AI tools to build internal agents and automations, they are pulling open source software dependencies into the organization through a door that security has no visibility into. The developer governance programs most security teams are focused on were designed for software engineers making intentional dependency decisions. They were not designed for an army of citizen developers who do not know what a dependency is.

The analyst conversations we had throughout the week reinforced this directionally. The question of who is accountable for AI-suggested dependencies is landing with security leadership in a way it was not twelve months ago. The tooling conversation has not caught up to the accountability conversation yet, and that gap is widening.

AI Security Builds on Security Fundamentals. It Does Not Replace Them.

The strategic trends session offered a useful longer view. A Gartner analyst walked through seven years of top strategic technology trends, examining which had delivered on their promise and which were still works in progress. The clearest signal for security practitioners came not from any single emerging technology but from a pattern across several of them: the organizations managing AI risk most effectively are not treating it as a separate security domain. They are applying existing security discipline to a new class of inputs and outputs.

That framing matters because a lot of the AI security conversation right now assumes that new tools require entirely new security thinking. What the trends data actually shows is that AI controls are built on the same foundations that govern every other part of the SDLC. The architecture is moving toward smaller, purpose-built models running in confidential computing environments, and the governance requirements that apply to those environments are extensions of what good security programs already do, not replacements for them.

For security leaders feeling pressure to stand up a separate AI security program from scratch, that is actually a useful reframe. The gap is not a missing category of tooling. It is the application of existing governance discipline to a new and faster-moving intake layer. That includes the open source software those models and agents depend on, which is growing in volume and variety faster than most programs were designed to handle.

What This Means Right Now

Gartner's Security & Risk Summit reflects the center of gravity of enterprise security practice. What we heard confirmed a few things we already believed and sharpened a few that we had been watching.

The trust conversation is accelerating. Vendors who cannot demonstrate continuous, transparent, contractually committed security operations are going to lose ground to those who can. The AI governance conversation is real and growing, but it is still catching up to the actual risk. Most organizations are focused on what their employees are using, not yet on what those tools are pulling into codebases and infrastructure on their behalf. And the gap between what AI-assisted development teams are introducing into environments and what security teams can actually see and control is not closing on its own.

For security and engineering leaders thinking about where to focus: the organizations that will be best positioned over the next 12 to 24 months are the ones treating open source software governance as an automated, auditable, contractually committed function rather than a scanning exercise. The difference between those two postures is not a matter of degree. It is the difference between a documented defense and a documented liability.

Learn more about how ActiveState approaches open source software governance at the point of origin.