Ivan's Cybersecurity Notes

Posted on Oct 6

Считаем staff для своей Product Security Team

#cybersecurity #infosec #management #security

Практическая модель staffing для Product Security, AppSec, DevSecOps, Cloud Security и Security Champions

TL;DR

Я работал с компаниями разного размера и неоднократно видел одну и ту же картину: engineering растёт — developers, QA, DevOps, platform teams, architects, product managers — а безопасность (сука, как же не справедливо) остаётся на одном-двух людях или на маленькой команде, которая должна закрывать почти всё.

Скажу сразу сходу и честно - универсального норматива здесь не существует. Но отраслевые ориентиры есть. Вот их то и разберем!

Мой практический rule of thumb:

Начинать планирование примерно с 1 dedicated Product Security / AppSec FTE на 50 – 75 software engineers, а дальше корректировать число с учётом риска продукта, сложности, автоматизации, compliance и реального scope команды. ЭТО БАЗА!

Для более рискованных сред — payments, FinTech, healthcare, critical infrastructure, safety-relevant products — я бы чаще стремился ближе к пропорции 1:25 – 50. Ну, а в зрелых и хорошо автоматизированных организациях может работать комбинация 1:75 – 100+, но только если Product Security не пытается вручную проверять всё подряд, а часть security ownership находится внутри engineering.

И центральную команду стоит усиливать через Security Champions внутри продуктовых команд. OWASP, например, приводит ориентир 1 champion на 25 разработчиков для крупных организаций; многие зрелые программы используют ещё более плотное покрытие.

ВАЖНО: здесь я говорю именно про Product Security / AppSec / DevSecOps capacity, а не про весь департамент кибербезопасности. ТАК КАК SOC, Incident Response, IAM operations, корпоративная защита endpoints, phishing, GRC и network security — это отдельные staffing-задачи. Простите, пацаны, я только за свою тему:)

Почему я вообще задался этим вопросом

В разных компаниях я видел один и тот же организационный перекос. Например, я встречал такой расклад:

30 разработчиков — и один человек в security.
100+ инженеров — и два специалиста.
150–200 человек, завязанных на software delivery, — и команда из трёх безопасников, которая должна выставлять стандарты, смотреть архитектуру, поддерживать AppSec tooling, разбирать findings, помогать cloud-командам, отвечать на audit-вопросы, обучать разработчиков и ещё подключаться к инцидентам.

При этом в engineering обычно нормально разделены frontend, backend, QA, DevOps, SRE, architecture, product management, design и engineering management.

А security часто остаётся одной общей корзиной. И у меня возник простой вопрос:

Если мы умеем планировать capacity разработки, QA, platform engineering и management span — почему Product Security headcount так часто определяется почти на глаз?

Я посмотрел BSIMM, исследования Security Champions, OWASP guidance и security organization benchmarks. Волшебной цифры там нет, но данных достаточно, чтобы построить полезную модель.

Эта статья — моя попытка собрать её в рабочий вид. Интересно? Погнали!

1. Сначала определимся, кого именно мы считаем

Одна из главных причин путаницы — слово security используется для очень разных функций. Под Product Security в этой статье я понимаю security capability, которая работает непосредственно с software engineering и создаваемым продуктом.

В зависимости от компании сюда могут входить:

Product Security Engineering;
Application Security (AppSec);
DevSecOps / Secure SDLC Engineering;
Cloud / Platform Security;
API Security;
Software Supply Chain Security;
Security Architecture;
Product Vulnerability Management;
Secure Design / Threat Modeling.

Типовая работа:

threat modeling и design review;
проверки authentication и authorization;
secure coding guidance;
API и business-logic security;
SAST, SCA, DAST, secret scanning, IaC и container controls;
CI/CD hardening и release integrity;
cloud, Kubernetes и platform security;
supply-chain controls, SBOM/VEX;
vulnerability triage и remediation ownership;
архитектурные guardrails и reusable secure patterns;
developer enablement и Security Champions;
product-level risk decisions и exceptions.

Но это не весь cybersecurity department.

Что я обычно считал бы отдельными функциями

Функция	Основной scope
Product Security / AppSec	Product, code, architecture, SDLC, APIs, cloud delivery, engineering risk
SOC / Security Operations	Production monitoring, alert triage, detection, escalation
Incident Response / DFIR	Containment, investigation, forensics, recovery
IAM Operations	Workforce identity, provisioning, access reviews, privileged access
Corporate / Enterprise Security	Endpoints, EDR, email, network controls, corporate infrastructure
GRC / Compliance	Controls, evidence, regulatory requirements, audits, policies
Security Awareness	Общая security-гигиена сотрудников, phishing, базовое обучение

В маленькой компании часть ролей неизбежно совмещается. Это нормально. Но «мы маленькие, поэтому роли совмещены» и «мы делаем вид, что этой работы не существует» — две разные вещи.

Исследования IANS хорошо показывают эту эволюцию: по мере зрелости security-функция распадается на отдельные SecOps, IAM, GRC, Architecture & Engineering и leadership-направления, а не остаётся одной универсальной командой.

2. Что реально показывают отраслевые данные

BSIMM16: хороший reality check

Building Security In Maturity Model (BSIMM) здесь особенно полезен, потому что он описывает реальные Software Security Initiatives, а не теоретическую идеальную оргструктуру. BSIMM16, опубликованный Black Duck в 2026 году, включает 111 организаций, которые защищают около 91 200 приложений, создаваемых 223 700 разработчиками.

Официальные источники:

Sammy Migues, много лет руководивший технической частью BSIMM, отдельно разобрал population BSIMM16. Средние значения по 111 организациям получились такие:

33,5 AppSec team members;
2 038 developers;
820 applications.

Если просто разделить средние значения, получается примерно:

1 специалист central AppSec team на ~61 разработчика.

Но читать эту цифру как норматив было бы ошибкой.

Куда интереснее другой вывод BSIMM: зрелые программы не пытаются решить масштаб бесконечным ростом central AppSec team. Они создают leverage через engineering integration и Security Champions.

Источник: Katilyst / Sammy Migues — BSIMM16 and Security Champions

Coalfire: ещё одна хорошая точка опоры

В AppSec Champions Report Coalfire исследовал зрелые AppSec-программы и получил ориентир:

примерно 1 full-time AppSec staff member на 50 developers.

То же исследование показывает, насколько сильно зрелая модель зависит от champions и постоянного взаимодействия с engineering.

Источники:

Если два независимых массива данных дают центр примерно в районе 1:50–1:60, для меня этого достаточно, чтобы использовать его как planning anchor, но не как закон.

3. Мой практический benchmark

Для software product company я бы интерпретировал dedicated Product Security / AppSec staffing примерно так:

Соотношение	Моя интерпретация
1 : 25 – 50	Сильное покрытие; уместно для high-risk, regulated, safety-relevant или сложных продуктов
1 : 40 – 75	Здоровый planning range для многих зрелых product organizations
1 : 75 – 100	Lean; нужны сильная automation, ясный ownership и Security Champions
1 : 100 – 150+	Может работать на масштабе, но только если central team сильно leveraged, а engineering реально владеет частью security activities

Неправильный вывод выглядел бы так:

«BSIMM показал 1:61 — значит всем компаниям нужен ровно один безопасник на 61 разработчика».

Нормальный вывод:

1:50–75 — хорошая начальная точка для разговора. Дальше корректируем под риск и operating model.

Сам headcount ничего не гарантирует. Команда из четырёх инженеров, которая построила automation, secure defaults, ownership, reusable controls и сильную сеть champions, может работать эффективнее восьми человек, которые вручную занимаются scanner triage и перекладывают findings из одного тикета в другой.

4. Простая формула, которой я пользуюсь для first-pass оценки

Когда мне нужно быстро оценить порядок staffing, я использую такую эвристику:

Product Security FTE ≈ Software Engineers / 60 × Risk Multiplier

Число 60 я беру не случайно — оно находится примерно посередине между ориентирами BSIMM16-derived data и Coalfire.

Дальше добавляется risk multiplier.

Среда	Стартовый multiplier
Internal tools / low-risk простой SaaS	0.8
Типовой коммерческий software product	1.0
Sensitive-data / B2B SaaS	1.2
FinTech / payments / healthcare	1.5
Safety-critical / critical infrastructure / heavily regulated	1.5 – 2.0

Пример 1 — обычный SaaS

180 developers:

180 / 60 × 1.0 = 3

Стартовая оценка: ~3 Product Security FTE.

Пример 2 — sensitive B2B product

180 developers:

180 / 60 × 1.2 = 3.6

Стартовая оценка: ~4 FTE.

Пример 3 — payments / FinTech

180 developers:

180 / 60 × 1.5 = 4.5

Стартовая оценка: ~4–5 FTE.

Пример 4 — safety-critical / highly regulated

180 developers:

180 / 60 × 1.8 = 5.4

Стартовая оценка: ~5 – 6+ FTE, а иногда и больше, если команда владеет deep assurance, product incident readiness, специализированным testing или regulatory evidence.

Это не индустриальный стандарт, и я бы точно не записывал эту формулу в policy как обязательный норматив. Это capacity-planning heuristic — быстрый способ понять, не выглядит ли предложенная модель очевидно недоукомплектованной ещё до более глубокого анализа.

5. Headcount сам по себе ничего не решает: смотрим на engineering reality

Две компании с 200 developers могут требовать совершенно разного количества Product Security staff. После baseline-расчёта я бы задал четыре группы вопросов.

Product complexity

Сколько у компании:

repositories;
services;
APIs;
mobile applications;
cloud accounts/subscriptions;
Kubernetes clusters;
production environments;
privileged workflows;
external integrations;
third-party components;
customer-facing administrative functions?

Delivery velocity

Сколько production releases в день/неделю?
Сколько независимых product teams?
Могут ли команды деплоиться автономно?
Насколько сложен CI/CD?
Как часто меняется architecture?

Risk profile

Payments?
PII / PHI?
Multi-tenancy?
Financial transactions?
Physical devices?
Remote commands?
Critical infrastructure?
Safety impact?

Security maturity

Есть ли reusable secure patterns?
Централизованы и tuned ли SAST/SCA/secrets/IaC/container scanning?
Нормальный ли asset inventory?
Есть ли ownership mapping?
Deduplicated ли findings?
Исправляют ли dev teams проблемы напрямую?
Реально ли работает Security Champions program?

Формула даёт baseline. Эти вопросы показывают, надо ли двигать его вверх или вниз.

6. Как я бы строил Product Security для 150 – 200 developers

Для 150 – 200 разработчиков я обычно ожидал бы 3 – 5 dedicated Product Security people в нормальной коммерческой software-компании — при условии, что SOC, IAM, GRC и corporate security живут отдельно.

Практическая структура может выглядеть так.

1. Product Security Lead / Head / Manager

Этот человек владеет системой, а не каждым отдельным ticket.

Фокус:

strategy и roadmap;
risk model;
architecture и high-risk decisions;
standards и guardrails;
stakeholder management;
metrics и executive reporting;
exception governance;
Security Champions program;
приоритизация и capacity decisions.

В команде из трёх человек такой Lead, на мой взгляд, всё ещё должен быть технически сильным и при необходимости hands-on.

2. Senior Product Security / AppSec Engineer

Основной scope:

threat modeling;
architecture review;
API security;
authN/authZ;
business logic;
secure code review;
validation critical vulnerabilities;
developer consultation;
remediation design.

3. DevSecOps / Cloud / Platform Security Engineer

Основной scope:

CI/CD security;
SAST/SCA/secrets integrations;
policy-as-code;
IaC security;
cloud IAM и exposure;
Kubernetes и containers;
software supply chain;
build/release integrity;
automation.

4–5. Дополнительная Product Security / AppSec / Cloud Security capacity

При росте компании дополнительные IC снимают execution-нагрузку и позволяют senior staff заниматься architecture, secure defaults и automation вместо постоянной жизни в backlog.

Моя быстрая оценка для 150 – 200 developers

Dedicated Product Security staff	Что я бы подумал
1	Сильнейший key-person risk и почти гарантированный bottleneck
2	Очень lean; жизнеспособно только при узком scope и сильном engineering ownership
3	Нижняя граница убедительной central function
4–5	Здоровый уровень для многих software product companies
5–8	Более логично для high-risk / regulated / сложных environments

НО ЕЩЕ РАЗ: это Product Security scope. Если на этих же людей повесили SOC, IAM operations, corporate endpoints, phishing, GRC, audit evidence и incident response, цифра перестаёт что-либо означать — мы уже считаем другую организацию.

7. Security Champions — главный force multiplier

Central AppSec team не масштабируется линейно вслед за development. Стандарт OWASP прямо пишет: AppSec engineers не могут быть единственной security-точкой для всех development teams. Security Champions — один из способов распределить знания и ownership.

Источники:

OWASP приводит 1 champion на 25 developers как пример разумного ratio для large organizations.

Источник: OWASP — Anticipate Personnel Changes

BSIMM16-derived data показывает, что зрелые программы могут идти ещё плотнее. По анализу Sammy Migues, среди организаций с champions programs небольшие компании имели в среднем примерно 1 champion на 6 developers, крупные — около 1:17.

Это не значит, что всем срочно нужен ratio 1:6. Для меня вывод другой:

Зрелые Product Security programs распределяют security capability внутрь engineering, а не пытаются централизовать каждое решение.

Для 200 developers вполне рабочая модель может выглядеть так:

3 – 5 dedicated Product Security specialists + 10 – 20 активных Security Champions

Champions — обычно не дополнительные security hires. Это могут быть developers, QA, DevOps/SRE, architects или product engineers, которые сохраняют основную роль, но получают security training, защищённое время, escalation path и формальное признание своей дополнительной ответственности.

OWASP отдельно подчёркивает, что champion может быть developer, tester, product manager или другой member delivery team — важнее genuine interest, support и возможность развиваться.

8. Developer, который выучил security, или security engineer, который выучил development?

Я не думаю, что здесь вообще нужен религиозный спор. Оба пути работают (ИМХО).

Сильный developer может стать отличным Security Champion, AppSec engineer или Product Security engineer, если глубоко изучит:

threat modeling;
exploitability и abuse cases;
authentication / authorization;
secure architecture;
cloud/platform risk;
vulnerability classes;
risk prioritization.

Сильный security engineer может быть не менее эффективен, если хорошо понимает:

software architecture;
APIs;
programming fundamentals;
CI/CD;
cloud platforms;
developer workflows;
release engineering;
product trade-offs.

Общее требование одно:

Product Security должна работать внутри engineering reality.

Человек, который понимает vulnerabilities, но не понимает delivery, будет создавать friction. Человек, который понимает delivery, но плохо мыслит как adversary, будет пропускать риск.

Самые сильные Product Security engineers обычно приходят к T-shaped profile: глубокое security core + достаточное понимание software engineering и platform engineering, чтобы controls были применимы в реальной жизни.

9. Не превращайте Product Security в «отдел всего, где встречается слово security»

Это один из самых быстрых способов уничтожить маленькую Product Security team. Компания нанимает трёх человек и называет их «Security». А дальше очередь постепенно превращается в:

AppSec findings;
cloud misconfigurations;
firewall changes;
endpoint alerts;
phishing incidents;
access requests;
audit evidence;
vulnerability scanning;
pen tests;
IAM reviews;
policies;
incident response;
security awareness;
customer questionnaires;
architecture review.

Три Product Security engineer на 180 developers могут быть нормальной структурой. Три «security people» на 180 developers плюс весь enterprise security scope (AD, линуха, почтовик, файерволы, внутренние порталы, анти-спам, антивирус, расдача прав и т.д. и т.п.) — уже совсем другая математика.

IANS хорошо показывает появление специализации по мере роста компании. В 2025 benchmark midsize organizations обычно имеют примерно 3–15 total security FTE, large enterprises — 15 – 49, Fortune-scale — 50+, и по мере роста появляются отдельные SecOps, IAM, GRC, Architecture & Engineering и leadership layers.

Источник: IANS — 2025 Security Organizational Design Benchmark

Это benchmark всей security organization, а не Product Security ratio. Я привожу его именно для того, чтобы не смешивать два разных измерения.

10. Четыре условных размера компании

Вот таблица, с которой я бы начинал разговор о capacity.

Software engineers	Типовой commercial product	Higher-risk product	Возможная central structure
30	1 сильный generalist / lead	1 – 2	AppSec + DevSecOps combined; external testing при необходимости
100	2	3–4	Lead + AppSec / DevSecOps split
200	3 – 4	5 – 7	Lead + AppSec + DevSecOps/Cloud + дополнительная execution capacity
500	7 – 9	10 – 15+	Director/Head, несколько IC, specialization, champion program

Эти цифры не означают «X людей гарантированно хватит». Это sanity check.

На 500 developers меня уже намного сильнее интересует operating model: product-aligned security engineers, architecture ownership, automation, vulnerability operations, champions и service boundaries.

При 30 developers один действительно сильный senior generalist может создать огромный leverage, если environment относительно простой, а engineering leadership не пытается outsource весь risk в security.

11. Когда нужен отдельный manager / director?

Чистого people manager я бы не нанимал слишком рано. Моя базовая логика такая.

1–2 Product Security people

Чаще полезнее сильный hands-on Lead / Head, а не manager, который уже полностью ушёл от техники.

3–5 people

Имеет смысл Lead / Manager / Head of Product Security, но я всё ещё хочу видеть сильное technical judgment.

6–10+ people

Полноценный Head / Director of Product Security становится естественным. Ниже могут появляться team leads / domain owners.

Несколько специализированных направлений

Если внутри функции уже есть:

AppSec;
Product Security Engineering;
DevSecOps;
Cloud / Platform Security;
Product Security Architecture;
Vulnerability Management;

то Director/VP layer плюс technical leads — уже не overhead, а нормальная оргструктура.

В safety-critical или heavily regulated industries отдельно могут появляться assurance, product incident response, compliance engineering и специализированные testing/validation groups.

12. Более правильная модель: три слоя вместо одной цифры

Если сократить всю статью до одной архитектуры, я бы рисовал её так.

№ Layer 1 — Dedicated Product Security specialists

Глубокая экспертиза и ownership.

Rule of thumb: старт примерно с 1:50–75 developers, с risk adjustment.

№# Layer 2 — Security Champions внутри engineering

Локальный контекст и first-line security capability.

Rule of thumb: примерно один champion на engineering squad / 10–25 developers, в зависимости от структуры и maturity.

№# Layer 3 — Automation и secure defaults

То, что делает первые два слоя масштабируемыми:

paved roads / golden paths;
secure templates;
reusable libraries;
CI/CD policies;
automated scanning;
centralized secrets;
baseline cloud controls;
guardrails;
self-service checks;
actionable dashboards.

Нельзя бесконечно компенсировать слабый Layer 3 наймом людей в Layer 1. И нельзя заменить Layer 1 объявлением всех разработчиков Security Champions. Модель работает именно потому, что три слоя усиливают друг друга.

13. Как я бы оценивал security team на интервью

Вот где эта тема становится полезной не только для руководителя, но и для кандидата. На интервью на senior Product Security role я бы не ограничивался вопросом:

«Сколько у вас безопасников?»

Я бы спросил следующее.

Scope

How many engineers and product teams does Product Security support?

Responsibility boundary

What is actually owned by Product Security, and which functions are separate — SecOps, IAM, GRC, corporate security, cloud security, incident response?

Champions

Do you have a Security Champions program? How active is it?

Automation

Which controls are centralized and automated today, and which activities still depend on manual security review?

Operating model

Is Product Security expected to approve everything, or do engineering teams own defined security outcomes?

Success criteria

What would you expect this team to improve over the next 12 months: coverage, architecture, vulnerability backlog, developer enablement, cloud controls, compliance, or something else?

Эти вопросы говорят о компании намного больше, чем job title. Три Product Security engineer на 180 developers могут быть вполне здоровой structural model.

Три человека, которые одновременно должны обслуживать 180 developers и SIEM, EDR, IAM, audit evidence, phishing, pentesting, architecture и cloud security, — уже warning sign.

14. Red flags, которые меня бы напрягли

Headcount важен, но эти признаки мне нравятся ещё меньше:

у Product Security нет понятных service boundaries;
каждый scanner finding вручную проходит через security;
engineering воспринимает security только как approval gate;
нет asset/repository ownership model;
security standards существуют только в документах;
нет champions или другой embedded capability;
один человек является единственным экспертом одновременно по AppSec, cloud, CI/CD и incident response;
security отвечает за remediation, но не может влиять на product priorities;
эффективность измеряется количеством findings, а не risk reduction / coverage;
каждая новая product team почти линейно увеличивает ручную нагрузку security.

Последний пункт особенно показателен. Зрелая Product Security function при росте должна становиться более leveraged, а не просто более перегруженной.

15. Мой итоговый rule of thumb

Если меня попросить назвать одну цифру, которую можно держать в голове, я отвечу так:

Планируйте примерно 1 dedicated Product Security / AppSec professional на 50 – 75 software engineers; для high-risk products смещайтесь к 1:25 – 50 и обязательно усиливайте central team Security Champions внутри engineering.

Для 150 – 200 developers я обычно хотел бы видеть примерно:

3 –5 dedicated Product Security specialists

с более плотным staffing для payments, healthcare, critical infrastructure, safety-relevant и heavily regulated environments.

И я бы обычно считал отдельно capacity для SOC, Incident Response, IAM operations, GRC и corporate security.

Но сама цифра — не цель. Цель — иметь достаточно capability, чтобы:

понимать material product risk;
строить secure defaults;
влиять на architecture до релиза;
автоматизировать повторяемые controls;
помогать engineering, не превращаясь в bottleneck;
сохранять ownership самых серьёзных risk decisions;
вовремя замечать, когда operating model перестал масштабироваться.

Поэтому для меня главный вопрос не:

«Сколько у нас security people?»

А грамотно так:

Хватает ли нам Product Security capacity, engineering leverage и ownership, чтобы удерживать риск управляемым по мере роста продукта?

Источники

Black Duck — BSIMM16 Report https://www.blackduck.com/resources/analyst-reports/bsimm.html
Black Duck — BSIMM16 release: 111 organizations, ~91,200 applications, 223,700 developers https://news.blackduck.com/2026-02-04-Black-Duck-Releases-BSIMM16-Revealing-AI-and-Regulatory-Compliance-Reshaping-Application-Security-Processes
Sammy Migues / Katilyst — BSIMM16 Security Champions analysis https://www.katilyst.com/post/bsimm16-security-champions-blog
Coalfire — AppSec Champions Report https://coalfire.com/insights/resources/reports/appsec-champions-report
Coalfire — AppSec Champions Report PDF https://assets.coalfire.com/prod/resources/reports/appsec-champions-report.pdf
OWASP Developer Guide — Security Champions Program https://devguide.owasp.org/en/08-culture-process/02-security-champions/01-security-champions-program/
OWASP Security Champions Guide https://securitychampions.owasp.org/
OWASP — Anticipate Personnel Changes (пример 1 champion / 25 developers) https://securitychampions.owasp.org/principles/10_Anticipate_personnel_changes/
IANS — The Evolution of Security Organization Design

https://www.ians.com/blog/ians-research/the-evolution-of-security-organization-design-a-maturity-roadmap-for-cisos
IANS — 2025 Security Organizational Design Benchmark Report

https://www.ians.com/insights/ciso-leadership/2025-security-organizational-design-benchmark-report

Об авторе

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.