Quick answer: An AppSec program (application security program) is the organized set of people, processes and tooling that reduces security risk in the software an organization builds and buys. Programs that scale share three features: a hub-and-spoke operating model (a small central team setting standards and running platforms, with security champions embedded in engineering), a maturity framework such as OWASP SAMM to sequence investment, and a handful of outcome metrics reported to the board rather than scanner counts.
Most application security programs were not designed; they accreted. A pen-test function became a SAST rollout, which became a DevSecOps initiative, which became a team of six trying to serve 1,200 developers across three clouds. The result is familiar to anyone who has run one: the central team becomes a bottleneck, engineering treats it as a gatekeeper to route around, and the board hears about vulnerability counts it cannot interpret.
The question that practitioners argue about most, and that the AppSec World agenda returns to every year, is how AppSec should actually operate: centralized or embedded, gatekeeper or enabler, a security team that owns risk or an engineering function that does. This article sets out a practical answer for enterprises of a few hundred to several thousand engineers, drawing on OWASP SAMM, BSIMM, the OWASP Security Champions Guide, and the patterns that recur in programs that have survived their third reorganization.
What does an application security program actually cover?
OWASP SAMM 2.0 is the most useful map of the territory because it is vendor-neutral and prescriptive. It defines five business functions, each with three security practices:
- Governance — Practices: Strategy & Metrics, Policy & Compliance, Education & Guidance · What it means in an enterprise: Who owns the program, what the rules are, how developers learn them
- Design — Practices: Threat Assessment, Security Requirements, Security Architecture · What it means in an enterprise: Threat modeling, requirements in backlogs, paved-road architectures
- Implementation — Practices: Secure Build, Secure Deployment, Defect Management · What it means in an enterprise: Pipeline gates, secrets handling, how findings are tracked and fixed
- Verification — Practices: Architecture Assessment, Requirements-driven Testing, Security Testing · What it means in an enterprise: Reviews, abuse-case tests, SAST/DAST/SCA/pen testing
- Operations — Practices: Incident Management, Environment Management, Operational Management · What it means in an enterprise: Response, hardening, decommissioning and data protection in production
The lesson most teams learn late: the Verification column is where almost all early budget goes (tools that find things), while the Governance and Implementation columns (ownership, defect management, paved roads) are what determine whether anything gets fixed. If your program has four scanners and no defect management policy, SAMM will score it low, and correctly.
BSIMM, the other widely used reference, is descriptive rather than prescriptive: it catalogs what roughly a hundred real firms do across 120-plus activities. It is useful for benchmarking ("firms like us typically do X") and less useful for deciding what to do next. Use SAMM to plan and BSIMM to compare.
The OWASP Top 10 2025 edition (OWASP Top 10:2025) is worth reading for program owners, not only developers. Beyond the updated risk list, which adds Software Supply Chain Failures at A03 and Mishandling of Exceptional Conditions at A10, it includes a chapter on establishing a modern application security program, and OWASP continues to describe the Top 10 as an awareness document rather than a standard to certify against. Use it that way in your program: as the shared vocabulary for developer training and secure coding standards, mapped to the SAMM practices that address each category, and never as the full scope of what your testing should cover.
Centralized or embedded: which AppSec operating model works?
Neither extreme survives contact with scale. The three models, honestly described:
- Centralized — How it works: One AppSec team owns tooling, reviews, pen tests and sign-off for all engineering · Where it breaks: Becomes a bottleneck past roughly 100 developers per AppSec engineer; engineering routes around it; security owns risk it cannot control
- Fully embedded — How it works: Security engineers report into each product line; no central function · Where it breaks: Inconsistent standards, duplicated tooling, no leverage, security staff drift into feature work
- Hub and spoke (federated) — How it works: Small central team sets policy, runs shared platforms and the champions program; embedded champions and, in larger orgs, product security engineers in each domain · Where it breaks: Requires sustained investment in the champions network and clear RACI; fails when the hub keeps doing reviews it should have delegated
Hub and spoke is where most large enterprises end up, and the Secure by Design movement championed by CISA and the UK's NCSC pushes the same direction: security is a property of the product, owned by the people who build it, with the central team providing defaults, paved roads and assurance rather than permission.
A useful test for whether your hub has actually delegated: count the manual approvals in your release process that require an AppSec engineer. If the answer is more than zero for routine changes, the central team is still a gatekeeper regardless of what the org chart says.
How do you run a security champions program that lasts?
A security champions program recruits developers inside each engineering team to act as the first line of security expertise: triaging findings, running threat modeling sessions, reviewing designs, and translating central policy into local practice. It is the mechanism that makes the hub-and-spoke model function.
The OWASP Security Champions Guide sets out ten principles, including starting with a clear vision, securing management support, nominating a dedicated program captain, trusting your champions, creating a community, rewarding responsibility and anticipating personnel change. Translated into operational decisions:
- Make the role formal. A written role description, a named captain in the central team who owns the program, and explicit time allocation agreed with engineering managers. Programs that rely on volunteers' spare time typically fade within a year.
- Protect the time. Allocations in the range of 10-20% of a champion's week are common in programs that endure; whatever you choose, write it into the engineering manager's headcount plan so it survives a deadline.
- Give champions leverage, not homework. Access to tooling consoles, authority to triage and close findings for their team, a direct line to the central team, and a say in policy. If the champion's job is forwarding tickets, nobody good will take it.
- Build the community. Regular guild meetings, a shared channel, internal CTFs, conference attendance. The community is what retains people when their day job gets busy.
- Recognize it in careers. Champion work should appear in performance reviews and promotion criteria. Reward responsibility, as the guide puts it, rather than hoping goodwill is enough.
- Plan for turnover. Expect to lose a quarter of champions a year to role changes; keep a bench and an onboarding path.
What ratio of security engineers to developers is realistic?
Benchmarks from BSIMM participants have historically put the central software security group at well under 2% of the development population, often closer to 1%, with satellite groups (champions) adding a comparable number again. Whatever your ratio, the architectural point is that the central team cannot grow linearly with engineering, so its job is leverage: platforms, defaults, automation and champions, not reviews.
Which application security metrics should go to the board?
Boards and regulators want to know three things: is risk going down, are we meeting our own commitments, and are we covered. Scanner counts answer none of them. A board-level AppSec metric set that works:
- Is risk going down? — Metric: Open high-risk findings (KEV, high-EPSS, reachable, exposed) per 100 production services, trended quarterly · Why it works: Normalized for growth; focuses on exploitable risk
- Are we meeting commitments? — Metric: Percentage of P0/P1 findings remediated within SLA, by business unit · Why it works: Creates ownership; comparable across units
- How fast do we fix? — Metric: Mean time to remediate per risk tier · Why it works: Direct answer to the regulator's question
- Are we covered? — Metric: Percentage of production services with SAST, SCA and secrets scanning in the pipeline, and with a named owner · Why it works: Coverage gaps are the risk you do not know about
- Is the culture changing? — Metric: Percentage of teams with an active champion; percentage of new features threat-modeled · Why it works: Leading indicators
- Are we exposed to third parties? — Metric: Percentage of critical vendors supplying SBOMs; time to answer "are we affected" in the last incident · Why it works: Supply chain is now A03 in the OWASP Top 10:2025
Keep operational metrics (scanner findings, false-positive rates, tool coverage by language) for the program team. Report six numbers to the board, every quarter, with the same definitions. Consistency matters more than sophistication; a board that sees the same six metrics for two years can tell whether the program is working.
In practice: rebuilding a program after a merger
Scenario. A regional bank acquires a fintech. Day one: 1,400 engineers, two AppSec teams totaling nine people, three SAST tools, two ticketing systems, one bank-side mandatory pre-release security review that the fintech's teams regard as absurd.
Quarter 1: assess and decide the model. A SAMM assessment scores both organizations. The bank is stronger on Governance and Verification; the fintech is stronger on Implementation (paved-road pipelines, fast defect management). Leadership chooses hub and spoke: a central team of nine sets policy and runs platforms, and every product domain gets at least one champion within six months.
Quarter 2: replace the gate with a paved road. The mandatory review is retired for changes that pass pipeline policy (no KEV-listed reachable dependency, no verified secrets, SAST criticals triaged). Reviews are retained only for new internet-facing services and changes touching authentication or payments. Champions take over triage for their teams.
Quarter 3: consolidate and measure. Tooling is consolidated to one SAST and one SCA platform; findings from both flow into a single risk view with ownership. The six board metrics are defined and reported for the first time; coverage turns out to be 71%, which becomes the headline fix.
Twelve months on. The central team is still nine people. Champions number 38. SLA attainment for P1 findings is reported per business unit, and the two laggard units have engineering-director-level remediation plans. Nothing about this required new headcount; it required an operating model.
For the tooling layer that makes a single risk view possible, see our article on application security posture management. For how to set the fix tiers and SLAs the metrics depend on, see our guide to vulnerability prioritization. For the governance question every program faces in 2027, see our piece on securing AI-generated code.
Key takeaways
- Use OWASP SAMM to plan and BSIMM to benchmark; most programs are over-invested in finding and under-invested in fixing and governing.
- Hub and spoke is the operating model that scales: a small central team providing defaults, platforms and assurance, with champions embedded in engineering.
- Security champions need formal roles, protected time, real authority and career recognition, or the program fades within a year.
- Replace manual security gates with pipeline policy for routine changes; reserve human review for high-risk changes.
- Report six stable outcome metrics to the board every quarter; keep scanner counts for the program team.
Join your peers at AppSec World 2027
AppSec World is the global application security forum: one meeting place for AppSec, product security and engineering leaders, with content by practitioners for practitioners and no product pitches. Join us in 2027 in New York, May 5, San Francisco, May 20, Melbourne, June 3, Sydney, June 10 and London, October 27.
Not ready to register? Sign up for updates and we will let you know when agendas and speakers are announced.