The ratio security leaders keep quoting is roughly 100 developers for every 1 security professional, with about 10 DevOps engineers in between — a heuristic traced to Verica's James Wickett around 2019 that has been repeated in SD Times pieces and conference talks ever since. It's not a census figure, but every practitioner recognizes the shape of it: a five-person AppSec team supporting an 800-engineer org, a single security architect covering twelve product lines. Meanwhile the workload keeps growing. A typical enterprise application carries 200 to 500 direct and transitive dependencies, and industry SCA data consistently shows 5 to 15% of them carrying a known CVE at any given moment — meaning a mid-size team can easily be staring at hundreds of open findings with no realistic path to triaging them all by hand. The instinct is to ask for more headcount. The budget answer is almost always no. This piece lays out a framework — built on two real OWASP projects (the DevSecOps Maturity Model and the Security Champions Guidebook), reachability-based prioritization, and policy-as-code enforcement — for scaling the impact of the team you already have, rather than the team you wish you had.
Why doesn't hiring solve the AppSec capacity problem?
Hiring doesn't solve it because the ratio is structural, not a temporary staffing gap. Even organizations that double their AppSec headcount in a year still add developers faster — a 100:1 ratio doesn't close by hiring two more engineers into a five-person team when the developer org itself is growing. The deeper issue is throughput: a human reviewing SCA and SAST output one ticket at a time cannot keep pace with continuous CI pipelines producing findings on every commit, across every repo, all day. James Wickett's framing of the ratio was explicitly a call to stop treating security as a gate staffed by scarce specialists and start treating it as a property the pipeline enforces automatically. Teams that keep hiring into the old model — one analyst manually reviewing every finding — hit a wall where mean time to remediate keeps climbing even as the roster grows, because the bottleneck was never headcount, it was a workflow that doesn't scale with commit volume.
What does a maturity model actually buy a small team?
A maturity model buys a small team a map of where to invest next instead of chasing whichever finding is loudest that week. OWASP's DevSecOps Maturity Model (DSOMM) is a free, actively maintained framework that scores a program across dimensions like build, deployment, and operations security, from ad hoc to optimized. Its value for a lean team is prioritization discipline: rather than trying to run every practice at once, DSOMM makes it explicit that, say, automated dependency scanning in CI is a lower-maturity, higher-leverage investment than manual penetration testing on every release, and should come first. Pair it with the OWASP Security Champions Guidebook, which documents how to formally recruit and train developer liaisons — one champion per team, trained on the org's specific risk patterns — so that a five-person AppSec team gains eyes and judgment embedded in twenty engineering teams without adding a single security hire.
How does a security champions program multiply a small team?
A champions program multiplies a small team by moving triage and first-pass remediation decisions to the people who already own the code, rather than routing every finding through a central queue. The OWASP Security Champions Guidebook frames this as decentralizing security ownership: champions get focused training on the vulnerability classes relevant to their stack, direct access to the AppSec team for escalation, and enough context to decide "this SQL injection finding is real, fix it now" without waiting for a security engineer to confirm it. The multiplier effect is real but bounded — champions are not replacement AppSec engineers, and a program without executive sponsorship, dedicated time allocation, and a clear escalation path tends to decay within a year as champions get pulled back onto feature work. Done well, though, it turns twenty scattered engineering teams into twenty first-line responders, freeing the core team for the findings that actually need specialist judgment.
How does prioritization cut the backlog down to a size a small team can handle?
Prioritization cuts the backlog by proving which of hundreds of flagged CVEs are actually exploitable in your running application, instead of treating every SCA hit as equally urgent. The established technique combines call-graph reachability analysis with exploitability signals — EPSS, the FIRST.org project that scores 30-day exploitation probability, and CISA's Known Exploited Vulnerabilities (KEV) catalog, which lists CVEs already seen exploited in the wild. Safeguard's own reachability engine applies this combination — static, dynamic, and configuration reachability layered with EPSS, KEV, and runtime/business context into a single 0–100 priority score — and documents shrinking a typical mid-size team's active urgent queue from 200–500 open CVEs down to roughly 20–60 per week, a 60–80% reduction, without suppressing anything actually reachable. That's the difference between a five-person team drowning in a 400-item backlog and the same team clearing a 40-item one every sprint.
What kind of automation actually removes work instead of just reporting it?
The automation that removes work is the kind that acts, not the kind that adds another dashboard to check. Cross-scanner deduplication — collapsing the same underlying issue reported by both a SAST and an SCA engine into one correlated finding, the way Safeguard's AutoTriage does, while explicitly never suppressing malware or secrets findings — cuts the raw volume a human ever has to look at. Policy-as-code guardrails go further: instead of a human deciding whether a build should ship with a KEV-listed critical vulnerability, a YAML policy blocks it automatically at the CI or registry stage, the way Safeguard's guardrails enforcement can gate on SBOM, CVE, and provenance checks at up to six points in the pipeline. The highest-leverage layer is auto-remediation — Griffin-style AI-generated pull requests that pin a dependency to the last safe version and update the lockfile — because it turns a finding into a merged fix without a ticket ever sitting in anyone's queue.
How should a two-person AppSec team sequence all of this?
Sequence it by fixing the highest-volume manual step first, then layering enablement on top, rather than trying to stand up every capability simultaneously. Start with automated, continuous SCA and SAST in CI so nothing depends on someone remembering to run a scan — this is DSOMM's baseline maturity level. Next, add reachability-based prioritization so the team's limited attention goes to the 10–20% of findings that are actually reachable and exploitable, not the full raw list. Then recruit two or three security champions in the highest-risk product teams using the OWASP guidebook's structure, giving the core team delegated first-line triage. Finally, turn on policy-as-code guardrails and auto-fix for the well-understood, low-risk categories — dependency version pins, missing SBOM attestations — so routine remediation stops consuming human cycles at all. Each layer is cheap relative to a headcount request, and each one compounds: less noise means champions triage faster, and automated fixes mean the core team only sees what genuinely needs a human decision.