Large engineering organizations like to believe their biggest problems are technical. If only someone would approve the budget for the latest tool, everything would be solved. Lately, the prevailing bet is that the silver bullet is vibe coding powered by your favorite flavor of LLM. But the pathologies of large organizations are rarely technical in nature.
In my experience, they are process-oriented problems and can manifest at two different ends of the spectrum. On one end you have teams caught in analysis paralysis, endlessly cycling through meetings, reviews, and consensus-driven design with little to show for it. On the other end, you have the “leap before you look” folks with an execution bias that leads to a lot of self-inflicted wounds due to a lack of introspection.
Somewhere around the moment an organization crosses 5,000 active committers, the nature of security transformation changes entirely. Tooling stops being the limiting factor. Budget stops being the limiting factor. Even talent stops being the limiting factor. What becomes scarce is alignment.
The reality is that by the time a company reaches this size, it already has a functioning security posture, a defined risk tolerance, and a security organization built roughly along familiar staffing ratios. A common pattern is one security professional for every 100 engineers, meaning a company with 5,000 developers likely has a 50-person security team attempting to influence thousands of software decisions per day. The question is not whether security exists. The question is whether it scales.
This article outlines the lessons learned from rolling out developer security programs inside organizations of this scale and why the path to success looks very different from what most CISOs expect.
Most security rollouts fail for a surprisingly simple reason: they are designed like software deployments instead of cultural changes. Security leaders often begin with the assumption that the right combination of tools (e.g., SAST, SCA, container scanning, secrets detection) will produce improved outcomes if deployed widely enough. But tooling adoption is the easy part.
The hard part is prioritization inside engineering organizations. Developers already have more work than they can complete in a sprint. Product deadlines dominate backlog prioritization. Feature velocity is visible and rewarded. Security fixes often appear abstract and externally imposed. When a security program lands inside that environment, the default response is predictable: security tickets get created, they enter the backlog, and they quietly accumulate.
Nothing about scanning coverage changes this reality. In fact, the more findings you surface without clear ownership, the worse the situation becomes. Security teams often believe they are reducing risk by increasing visibility, but in practice they are sometimes amplifying unmanaged risk. Because everyone knows the problems exist, but nobody really owns them.
Large engineering organizations operate under a set of structural constraints that smaller companies rarely encounter. First, there is SDLC fragmentation. A company with thousands of engineers almost certainly runs multiple development lifecycles simultaneously. Some teams deploy daily. Others deploy quarterly. Some rely on legacy systems built a decade ago that everyone is afraid to touch for fear that they will stop working entirely and become their personal problem. Second, there is technology heterogeneity. A typical enterprise environment may include dozens of programming languages, multiple CI/CD systems, several infrastructure platforms, and a mix of cloud-native and legacy workflows.
Security tooling that works elegantly in one environment may be nearly impossible to deploy in another. Third, there is limited central enforcement power and no single system that captures the full scope of an organization's application and cloud attack surface.
Even if the CISO technically reports to the CIO or CTO, security teams rarely control the backlog priorities of product engineering groups. They influence them, but they do not own them. This creates a fundamental tension.
And the most dangerous security problems are often the ones that require architectural change, dependency upgrades, or major refactoring. The kinds of work engineers instinctively avoid because they do not fit neatly inside two-week sprint planning.
Tasks estimated above roughly 13 story points often get deferred indefinitely. These are projects masquerading as tickets. The result is a growing backlog of security work that everyone understands intellectually but no one feels empowered or incentivized to prioritize.
One of the most common mistakes security leaders make is assuming that tool coverage equals progress. Running scanners across every repository may generate impressive dashboards, but without ownership those dashboards become little more than risk catalogs. Real progress begins with a different question:
Who is responsible for fixing what?
Security programs that scale begin by identifying influencers inside the engineering organization. Not the formal managers. Not the architects on the org chart. But the developers whose opinions actually shape engineering behavior. Every large engineering organization has them. These are the culture-carrying engineers and developers others consult before making architectural decisions. A surprisingly effective approach is a training-of-trainers model:
Within a few weeks, security practices propagate across thousands of engineers without requiring the security team to directly train everyone. At scale, influence spreads through peer credibility.
Most enterprise security programs begin with a pilot. This is sensible in theory. But the way pilots are chosen often guarantees misleading results.
Security leaders frequently select one of two kinds of teams:
Both produce artificially positive outcomes. High-performing teams already maintain strong engineering hygiene. Their dependency updates are current. Their CI/CD pipelines are modern. Their architecture is actively maintained. Deploying security tooling there produces impressive metrics, but also a dangerous illusion that rollouts will scale smoothly. The reality appears later. When the rollout reaches legacy services, understaffed teams, or systems that have not been meaningfully updated in years.
A better pilot selection approach intentionally includes representative complexity:
The goal of a pilot is to discover friction early.
Successful developer security programs tend to follow a consistent rollout pattern. It rarely happens intentionally, but experienced CISOs eventually converge on the same model.
Treat it as a learning exercise.
Next comes developer engagement. Findings are presented in ways that engineers can actually act upon. False positives are aggressively removed. Documentation improves. Remediation examples are shared. This phase also introduces intrinsic motivation. Developers rarely respond well to top-down enforcement. But they do respond to problem-solving challenges. Some organizations successfully gamify remediation work, allowing teams to compete based on the number of security issues resolved per sprint. When engineers begin fixing issues voluntarily, you know the program is starting to work.
Only after developers trust the system do enforcement mechanisms appear. These usually take the form of guardrails. Examples include:
The emphasis remains on preventing new risk, rather than punishing historical debt. The “why” needs to be there alongside the “what” so that we’re not just playing an advanced or accelerated version of whack-a-mole with vulnerabilities and misconfigurations.
The final phase introduces leadership visibility. Metrics appear in engineering leadership dashboards:
At this point, security becomes part of engineering performance discussions. And that is when the cultural shift becomes palpable and durable.
The fastest way to derail a security rollout is premature enforcement. Common early mistakes include:
These actions feel decisive, but they often create a backlash. When engineers suddenly find their deployments blocked by tools they did not ask for, they quickly discover workarounds. They disable scanners and fork pipelines. They ignore alerts. The result is worse security and a damaged relationship between engineering and security teams. Adoption must come before enforcement. Trust must come before control.
Security dashboards often focus on the wrong numbers. Counts of vulnerabilities, scans completed, or repositories analyzed provide visibility but say little about behavioral change.
More meaningful indicators include:
Even well-designed rollouts encounter turbulence. Experienced security leaders recognize the warning signs early:
When this happens, the instinct is often to tighten enforcement, but that is almost always the wrong move. Instead, successful CISOs pause and ask three questions:
The last question leads to one of the most important principles in large-scale security programs:
The Pareto Principle applies here: in most environments, roughly 20% of vulnerabilities account for 80% of real organizational risk. Security programs that focus on those high-impact issues dramatically reduce risk while minimizing developer friction. Programs that attempt to fix everything simultaneously collapse under their own weight.
A long-term developer security program ultimately moves upstream. Instead of reacting to vulnerability reports, organizations begin preventing them during design and development.
One of the most effective tools for this transformation is threat modeling. Many developers encounter security only when a scanner flags an issue. They learn the rule but not the reasoning. Threat modeling changes that dynamic.
It helps developers understand:
When engineers understand the “why”, they stop seeing security fixes as external demands and they begin designing systems that avoid those problems entirely. Pairing junior developers with experienced engineers accelerates this learning even further. Senior developers naturally pass down habits such as documentation discipline, automated testing, and secure infrastructure configuration. Security becomes less about scanning code and more about how engineers think while writing it.
After watching dozens of developer security programs succeed or fail, one principle consistently determines the outcome: security must reduce developer cognitive load, not increase it.
If tools generate overwhelming noise, engineers disengage. If remediation guidance is unclear, engineers postpone fixes. If enforcement arrives before trust, engineers bypass controls. But when security tools:
developers respond the way they always do and they solve the problem.
And when enough of them begin solving it, something remarkable happens. Security becomes a habit.
And in an organization with 5,000 committers, habits are what ultimately determine the security posture of the entire company.
These lessons heavily influenced the design philosophy behind modern developer security platforms like Aikido. A system built to surface meaningful risk while minimizing the cognitive burden on developers.
https://www.aikido.dev/blog/rolling-out-developer-security-in-a-5-000-engineer-organization