Cybersecurity has been a recognized discipline for 30 years. There are frameworks, certifications, and entire executive functions dedicated to it, as well as more tools than most organizations know what to do with.
And yet, when a critical CVE drops in 2026, the first question in organizations everywhere is still the same one it was in 1995: who owns this?
We’ve been talking to senior security and technology leaders across regulated industries about exactly this question. None of them felt like they’d solved it, and the reasons why follow a consistent pattern.
Security Was Designed as a Checkpoint, Not a Function
The original model was logical: developers build, security reviews, and software ships.
When releases happened quarterly, that model held. As release cycles compressed from months to weeks to continuous deployment, the checkpoint model hasn’t evolved in turn. It became more stressed: security teams that were never resourced to be inside the build process were suddenly expected to review everything, constantly, at speed.
The result is that security has become the team that says no. Not because of culture or attitude, but because the model left them no other option. They sit downstream of every decision and upstream of every release. They own the risk without the resources to fix it.
Workarounds That Almost Work
When the model breaks down, organizations improvise. In conversations with security leaders, we’ve heard a consistent set of workarounds, each reasonable but not a complete solution.
An interesting one I’ve heard is embedding a security engineer directly inside engineering sprints. The logic is sound. If security can’t review everything at the end, put someone in the room at the beginning. In practice, it works for the teams that have the dedicated resource. Unfortunately it doesn’t solve the problem as each sec engineer has varying levels of influence in the projects they enter, and everyone else still hits the checkpoint at the end. Embedded security engineers, however skilled, can’t scale across a 500-developer organization. They become a bottleneck with a different job title.
Another approach: homegrown package databases. Security teams maintain their own inventory of approved open source components, update manually, and distribute to developers through internal tooling. One leader described spending years building exactly this, a trusted internal list that developers were supposed to pull from instead of going directly to public registries. The problem that arose quickly however was maintenance. The moment the list fell a version behind, developers found a way around it. Shadow dependencies entered the environment anyway, and the list became a compliance artifact rather than effective operational control.
A third pattern we hear every day: executive mandates. A security incident, or a near miss, triggers a directive from the top. Ownership gets assigned. Accountability gets documented. For a while, it holds. Then the incident fades, the mandate gets deprioritized against shipping commitments, and the ownership question quietly reverts to unanswered. As one security leader put it: “We cannot tell them what tools to use.” Policy authority and resource authority stays in separate hands.
What all three workarounds share is that they depend on humans doing consistently, at scale, what the infrastructure could be doing. We’re trying to reframe this as a process of maturation, rather than a failure of culture.
Accountability Follows Authority, and Security Rarely Has Both
Here’s the structural gap that decades of security culture investment has never closed: engineering owns the codebase, the pipeline, and the developers. Security owns the policy, but policy without resource authority is just a list of requirements someone else has to execute.
When a vulnerability needs remediation, security identifies it and flags it. Engineering prioritizes it, against everything else in their sprint. If security and engineering are measured in different outcomes, compliance versus velocity, the same issue gets triaged very differently depending on who’s in the room.
Across every conversation we had, this dynamic showed up in some form. Security sets policy, Engineering controls tooling and pipeline decisions, and the gap between those two never closes. The question of “who ultimately decides if, when, and how to fix this” stalls remediation every time.
Organizations can mandate shared responsibility all they want, but when there’s no clear ownership of a problem, no one fully solves for it.
Open Source Complicated It. AI Made It Structural.
For most of the last 20 years, the ownership question was bounded by human behavior. A human developer made a decision to pull in a library, would check it over, and the decision was traceable.
AI coding assistants have created an exponential effect though. When an AI agent autonomously selects and incorporates open source packages as it generates code, the traditional accountability chain breaks entirely. The answer to “who chose this library?” is sometimes “the AI did, and nobody reviewed it before it hit the pipeline.”
As a result, modern applications don’t use a handful of open source dependencies. They use hundreds, each with their own transitive dependencies, license conditions, and vulnerability histories.
In every organization we spoke with, their open source footprint was expanding faster than governance was keeping up. Embedded security engineers can’t watch what AI is doing; homegrown package lists can’t update fast enough; executive mandates don’t cover what AI introduced between the last sprint and this one.
More policy and better training can’t fix that. Only tooling where enforcement is automatic, at the point where the decision is first being made, changes the outcome.
Real Ownership Comes From Defaults, Not Policies
The security industry has spent 30 years trying to solve ownership through people and process: threat modeling workshops, shift-left programs, SLA mandates, escalation paths. These efforts move the needle, but don’t solve the problem, because they rest on the same assumption: that the right humans, properly informed, consistently make the right calls under deadline pressure.
The reality is that they don’t reliably, especially at the volume of code AI now produces.
We’re finding the organizations that make the most progress with this aren’t the ones who create the most thorough policies. They’re the ones that make the secure choice the path of least resistance. This means approved open source components are enforced at the point of ingestion, before anything reaches the pipeline. Remediation happens automatically, on a contractual timeline, instead of entering a backlog someone has to fight through. Governance that runs in the background, invisible to developers, so the secure path and the fast path are the same path.
When the right choice is also the easy choice, ownership stops being a cultural negotiation. It becomes a default.
What Security and Engineering Leaders Actually Need to Ask
If you are a security leader, the more useful question isn’t “how do I get engineering to take this more seriously?” It’s “how do I minimize manual review?” Every manual follow-up, every escalation, every exception review is a signal that your governance model depends on humans doing things that infrastructure could be doing instead.
If you are an engineering leader, the better question isn’t “how do I keep security from slowing us down?” It’s “how do I make sure my team never has to stop for a security fire drill?” Sprint interruptions, late-breaking CVE blocks, and release delays are what will continue to happen when open source governance isn’t embedded in your workflows before code ships.
Both questions have the same answer: a shared operating model for open source that gives security the enforcement it needs and gives engineering the autonomy it wants, without requiring either team to win an argument every time something goes wrong.
Ownership confusion isn’t going to be negotiated away, but it can be engineered away.
ActiveState gives security and engineering teams a shared foundation for open source governance, so security stops being the blocker and engineering stops being the bottleneck. Contact us to learn more about how we can help your teams.
Frequently Asked Questions:
Why does the question of who owns security risk keep going unanswered in large organizations?
The root cause is a structural mismatch between authority and accountability. Security teams own the policy: they can define what must be remediated and by when. But engineering teams own the codebase, the pipeline, and the developers who do the actual remediation work. When those two forms of authority live in separate hands and are measured against different outcomes — compliance versus velocity — the same vulnerability gets triaged very differently depending on who is in the room. Policy without resource authority is a list of requirements someone else has to execute. Until the authority to define the requirement and the authority to act on it are connected by a shared operating model, ownership confusion is the default state.
Why don't common workarounds like package allowlists and executive mandates solve the problem?
Each workaround addresses one dimension of the problem while leaving the others intact. Embedding security engineers inside engineering sprints works for teams that have the dedicated resource, but a single security engineer cannot scale governance across a 500-developer organization. They become a bottleneck with a different job title. Homegrown package lists give security teams an approved inventory to point developers toward, but the moment the list falls a version behind, developers find a way around it and shadow dependencies enter the environment anyway. Executive mandates create accountability after an incident but tend to fade as urgency decreases and shipping commitments increase. What all three share is that they depend on humans doing consistently, at scale, what infrastructure could be doing instead.
How have AI coding assistants made the ownership problem worse?
Before AI tools, the accountability chain was traceable: a human developer made a decision to pull in a library, and that decision was logged, reviewable, and assigned to someone. When an AI agent autonomously selects and incorporates open source packages as it generates code, the answer to “who chose this dependency?” is sometimes “the AI did, and nobody reviewed it before it hit the pipeline.” The result is that modern applications are accumulating open source dependencies, each with their own transitive dependencies, license conditions, and vulnerability histories, faster than any governance model built around human-speed, human-driven decisions can keep pace with.
What does it mean to make the secure choice the path of least resistance?
It means moving enforcement upstream of the decision point, so the right choice is the default rather than the result of a review process. In practice this looks like approved open source components being enforced at the point of ingestion before anything reaches the build pipeline, remediation happening automatically on a contractual timeline rather than entering a backlog that security and engineering have to negotiate through, and governance running in the background, invisible to developers, so the secure path and the fast path are the same path. When security is built into the defaults rather than layered on top of existing workflows as a checkpoint, ownership stops being a cultural negotiation and becomes a structural outcome.
How should security leaders and engineering leaders reframe the questions they're asking?
Security leaders tend to ask how to get engineering to take security more seriously. The more useful question is: how do we minimize the number of decisions that require human follow-up at all? Every manual escalation, exception review, and ownership negotiation is a signal that the governance model depends on humans doing what infrastructure could be doing instead. Engineering leaders tend to ask how to keep security from slowing the team down. The better question is: how do we make sure the team never has to stop for a security fire drill? Sprint interruptions, late-breaking CVE blocks, and release delays are the cost of open source governance that isn’t embedded in workflows before code ships. Both questions have the same answer: a shared operating model where security gets the enforcement it needs and engineering gets the autonomy it wants, without requiring either team to win an argument every time something needs to be fixed.
The Curated Catalog addresses all 4. Open source components are built from verified sources in SLSA Level 3 infrastructure, so a package published via a stolen token without matching provenance would not be admitted. Every transitive dependency is scanned before admission, meaning plain-crypto-js with its obfuscated postinstall hook would fail malware analysis. Components are delivered as verified binary artifacts without arbitrary postinstall execution in developer environments. And because the protection is pre-admission rather than post-installation, the self-erasing cleanup is irrelevant. The component never reached the developer.
