TL;DR
Security architects at mid-to-large enterprises face a widening gap between the volume of security-relevant changes shipping every sprint and their team’s capacity to review them. The industry-standard 1:100 AppSec-to-developer ratio was already strained before AI coding tools compressed sprint cycles and pushed PR volumes up by nearly 100%. Closing the change coverage gap requires a structural shift from manual, periodic reviews to change-native governance that assesses every ticket, design doc, and pull request automatically, with company-specific context and a traceable decision record.
Your security architect reviewed three tickets today. Fifteen new ones landed in the queue since yesterday morning. A PR that modified authentication token logic merged three days ago, and nobody on the team caught it. The Jira ticket didn’t have the right labels, so it slipped through.
By end of day, the backlog grew by twelve net items. And your architect knows, in their own words, that “at least half of those were either ignored or forgot.”
The change coverage gap is real. And for security teams at companies with 80 or more engineers, it’s getting worse every quarter.
Where Does the 50% Number Come From?
The math is brutal and surprisingly simple.
The industry benchmark for AppSec-to-developer ratios sits at roughly 1:100. One security professional for every hundred engineers writing code. At that ratio, reviewing every change is physically impossible. As one AppSec leader put it: “A team of 5 cannot analyze every line of code written by 5,000 developers. That’s not failure; that’s math.”
In Gist Security’s discovery conversations with CISOs and security architects across financial services, insurance, healthcare, and logistics, the pattern shows up consistently. Two people assigned to reviews with 80+ in the backlog. Security assessments averaging seven days per review. Four architects reviewing hundreds of tickets each per month, and still losing ground.
So where does 50% come from? One enterprise customer reported that manual processes “covered just about half” of tickets. And “just about half” tracks with what other security architects tell us directly.
Which Changes Are Most Dangerous When They Slip Through?
The big, obvious launches rarely fall through the cracks. New products get attention. Major migrations get executive oversight. The dangerous ones are the mid-risk changes that fly under the radar.
A vendor integration that quietly expands data sharing scope three months after the original risk assessment. A helper function that modifies authentication logic buried inside a routine sprint. A new data flow that introduces PII handling without triggering a privacy review because the Jira ticket was categorized as a “minor enhancement.”
One CISO on a Gist discovery call described a pattern that should worry every security leader: “People brought in a vendor or started a POC, started building something. They didn’t even involve security.”
And the gap compounds. When an unreviewed change ships, the decisions behind it vanish. No one documented the threat model. No one recorded the risk acceptance. No one noted what mitigations were required. So when an auditor asks, “Show me where you assessed data minimization, retention, and access controls for that feature,” the team scrambles to reconstruct evidence from Jira comments, Confluence pages, and email threads that were never meant to serve as governance records.
Can You Just Hire More Architects to Fix the Gap?
A reasonable question, and the answer is: not really.
Security architects with the right mix of technical depth and domain context are scarce. The cybersecurity talent gap remains at roughly 3.5 million unfilled roles globally, and AppSec specialists sit near the top of the scarcity list. Even when you can hire, each new architect needs about six months of ramp time to learn the company’s systems, policies, and risk tolerances.
But the deeper problem is consistency. When humans perform threat models manually, results vary by reviewer expertise, available time, and familiarity with the specific technology stack. As one senior cybersecurity manager on a Gist discovery call explained: “Because it’s a manual process, it is prone to human error. As we have several different architects doing these reviews, there’s occasionally either a lack of consistency or technical gaps.”
Another architect was more blunt: “I have 10 tools and get totally 10 different threat models. So how do you know that what you did is actually correct?”
Hiring more people adds capacity, but it doesn’t solve the consistency problem. And at the rate development velocity is accelerating, capacity alone can’t keep up anyway.
How Is AI-Accelerated Development Making the Gap Worse?
Security teams were already drowning before AI coding tools hit mainstream adoption. Now the water’s rising faster.
Developers using AI assistants like Copilot, Cursor, and Claude Code are merging significantly more pull requests than they did a year ago. CSO Online (citing Faros AI research) reported in February 2026 that AI-assisted developers merge 98% more PRs. And research from multiple sources finds that roughly 30% of AI-generated code contains vulnerabilities.
So the equation has shifted. More code, produced faster, with less time for review, and a higher baseline vulnerability rate. The old model (security teams structured for 50 changes per month) can’t absorb a world where AI-assisted teams ship hundreds of changes per sprint.
Google disclosed that 25% of its code is now AI-generated. If a company operating at that scale reached those numbers that fast, mid-market and enterprise teams aren’t far behind. And every one of those AI-generated changes needs the same security scrutiny as human-written code, sometimes more, because AI tools lack context about your company’s specific threat landscape, compliance requirements, and architectural constraints.
The coverage gap was already unsustainable. AI development velocity turned it into a compounding risk.
What Does Closing the Coverage Gap Actually Require?
Closing the gap requires a structural change in how security governance works, not just faster manual reviews or better triage spreadsheets.
The shift is from periodic, human-dependent review to change-native governance, where every organizational change (every ticket, every design document, every pull request) gets assessed automatically against your company’s actual policies and risk tolerances.
What does that look like in practice? A change-native platform connects to your existing stack (Jira, ServiceNow, Confluence, SharePoint, GitHub, GitLab) and scores every change on security relevance, urgency, and risk dimensions before development begins. High-risk changes get flagged for human review. Routine changes get assessed and documented automatically. And every assessment produces a traceable record of what was found, what was decided, and what mitigations were required.
Gist Security built its platform around exactly this model.
The result isn’t replacing your architects. It’s giving them coverage across every change while they focus their expertise on the genuinely complex decisions that deserve human judgment.
And because Gist prices per change-maker (developer, DevOps, IT staff) rather than per assessment, there’s no financial penalty for reviewing more changes. You get full coverage at a predictable cost.
Start With the Changes You’re Missing Today
If your security architecture team reviews fewer than half the changes that ship each sprint, you already have a coverage gap. You may not see it in a dashboard because no dashboard tracks “changes we never looked at.” But your auditor will find it. Or worse, an attacker will.
The first step is measuring the gap. How many tickets entered your queue last month? How many got a security review before merge? What percentage of design documents received a threat model? If you can answer those questions honestly, you already know the scope of the problem.
The second step is deciding whether to keep solving it with headcount, or to make governance change-native so that every change gets assessed automatically, with your policies, your context, and a defensible audit trail.
Gist Security was built for security architects and CISOs who are done watching changes slip through the cracks. If you want to see how it works on your own data, the fastest path is a hands-on proof of concept with your actual artifacts.
FAQ
Divide the number of changes that received a security review before merge by the total number of security-relevant changes in the same period. Most teams we’ve talked to discover their coverage rate sits between 30% and 60%, depending on team size and development velocity. Gist helps close the gap by automatically assessing every change request against your company’s policies.
High-risk changes (new products, major migrations) attract executive attention and dedicated review cycles. Mid-risk changes, like a vendor integration scope change or a helper function that touches auth logic, often lack the labels or triage triggers that route them to security. Gist’s change tracking scores every ticket on five risk dimensions, so mid-risk changes get flagged automatically.
Yes. AI-assisted developers merge significantly more pull requests, and research shows roughly 30% of AI-generated code contains vulnerabilities. More code produced faster, with a higher baseline vulnerability rate, means security teams fall further behind. Automated, change-native governance is the only way to match that velocity.
The industry benchmark hovers around 1:100, meaning one security professional for every hundred developers. At companies with 80+ engineers, security architects typically manage backlogs of dozens or hundreds of open review requests, with average review cycles of seven days or longer.
Gist connects to your existing tools (Jira, Confluence, GitHub, ServiceNow, and more) and automatically assesses every change for security, privacy, and compliance risk. High-risk changes get routed for human review with full context. Routine changes get documented automatically. And every decision, approval, and exception feeds into an audit-ready evidence ledger.
Change-native governance means security, privacy, and compliance assessments happen automatically when changes occur, not on a periodic schedule and not only when someone remembers to request a review. Governance follows the change, not the calendar.
