DEV Community: Ivan's Cybersecurity Notes

Учимся триажить баги и оценивать их влияние на продукт. Или о том как Product Security превращает finding в риск-решение

Ivan's Cybersecurity Notes — Sat, 31 Oct 2026 23:00:00 +0000

Практический ProdSec Vuln Triage playbook: triage → applicability → exposure → reachability → exploitability → blast radius → business impact → treatment → verification.

Когда я работал SecOps инженером, одна из самых полезных вещей, которую мне пришлось усвоить, была довольно простой: красная цифра на счетчике CVSS или алерт Hight Impact в отчете сканера — это еще не доказуемый факт бага.

По классике все выглядит примерно так: Сканер уязвимостей или другая тула ассесмента может сказать, что у нас, например, рейт CVSS 9.8. Далее SCA может подсветить vulnerable dependency. А SAST может найти потенциальный sink. И еще круче, DAST может подтвердить поведение на работающем приложении. CNAPP может показать misconfiguration в инфраструктуре. Ну, а Bug bounty researcher может прислать PoC и запросить денежку:)

Только вот, как оказалось, это "не все" что нужно для принятиях технического решения. Нормальная адекватная инженерная работа — это не переслать finding разрабу со словами «Critical, fix ASAP». Инженерная работа Mid+\Senior SecOps — понять, что именно найдено, применимо ли это к продукту, достижим ли vulnerable path, кто может его атаковать, какие права получит атакующий, куда он сможет pivot’нуться дальше, что реально потеряет бизнес и какой response уменьшит риск быстрее всего.

Именно этим mindset я хочу поделиться в этой статье.

Главная идея такая:

CVSS — это severity signal. Приоритет ремонта появляется только после добавления контекста.

И современный контекст — это не одна дополнительная колонка в треке Jira. Это целая live цепочка: applicability, exposure, reachability, exploitability, threat intelligence, asset criticality, blast radius, compensating controls, business impact и confidence.

Разберем все по косточкам! Погнали!:)

DISCLAIMER

Архитектуры и часть scenarios в статье намеренно упрощены и используются как учебные модели. Реальные CVE и vendor statements отмечены отдельно. Reachability verdict никогда не должен строиться только на одном scanner signal: качество решения зависит от полноты evidence и понимания конкретного runtime environment.

Field card: карта triage, которую удобно держать перед глазами

Если нужно быстро объяснить весь mindset одним скрином, я бы оставил себе такую карточку:

FINDING
   |
   v
[Real / Valid?]
   |
   v
[Affected in our build / runtime?]
   |
   v
[Where is it deployed?]
   |
   v
[Who can reach it?]
   |
   v
[Is the vulnerable path reachable?]
   |
   v
[Possible -> Feasible -> Weaponized -> Active?]
   |
   v
[What identity / privileges does compromise give?]
   |
   v
[What can the attacker reach next?]
   |
   v
[Business impact / blast radius]
   |
   v
[Which control can break the path now?]
   |
   v
[Priority -> Treatment -> Owner -> SLA / Expiry]
   |
   v
[Verify -> Reassess -> Reopen if assumptions change]

Это не checklist. Это короткая модель мышления (т.е. ты можешь ее адаптировать под свой стек\архитектуру\продукт). Если на одном из шагов нет ответа, то просто пишем Unknown, а не автоматически превращаем неизвестность в Low risk.

Еще один полезный operational signal из реальной работы — age / time at risk: сколько finding уже живёт в production и сколько времени актив остается под экспозицией. Возраст проблемы\бага сам по себе не превращает Medium в Critical, но помогает управлять очередью, метриками SLA breaches и накопленным security debt (что очень важно для Lead и Head).

Почему классическая модель «CVSS = Priority» больше не работает

Модель старой школы (лет так 10 назад) выглядела просто:

Scanner -> CVE -> CVSS -> SLA -> Patch

Например:

CVSS 9.0-10.0 -> Critical -> fix in 24/48h
CVSS 7.0-8.9  -> High     -> fix in 7 days
CVSS 4.0-6.9  -> Medium   -> fix in 30 days
CVSS < 4.0     -> Low      -> backlog

Для отчетности это красиво. Для реальной Product Security — слишком грубо, не качественно. Нужен экспертный взгляд, парсинг профессионала.

Метода FIRST в актуальном CVSS v4.0 прямо подчёркивает, что CVSS-B измеряет severity, а не risk. В версии 4.0 (актуальна на на момент написания материала) появились отдельные Base, Threat, Environmental и Supplemental metrics, и сама модель фактически говорит потребителю: Base Score — это только начало анализа.

То есть даже стандарт, который часто ошибочно используют как готовый risk score, говорит обратное.

Смотрим практический пример:

CVSS 9.8 в library, которую приложение физически не вызывает, может быть ниже по operational priority;
CVSS 6.5 на internet-facing API, который позволяет cross-tenant data exposure, может быть для бизнеса гораздо опаснее;
CVSS 8.x на внутреннем CI/CD controller может стать P0, если через него доступны signing keys, registry, production deploy tokens и Kubernetes;
CVSS 10.0 на package, которого нет в runtime artifact, вообще может оказаться false positive или not_affected для данного продукта.

Поэтому предпочитаю мыслить вот так:

Priority = f(
    Technical Severity,
    Applicability,
    Exposure,
    Reachability,
    Exploitability,
    Threat Intelligence,
    Asset Criticality,
    Blast Radius,
    Compensating Controls,
    Business Impact,
    Confidence
)

Это не математическая формула и не предложение умножать один subjective score на другой. Это скорее список вопросов, которые инженер должен пройти до того, как назвать vulnerability «Critical для нас\продукта».

Полевая терминология

Если вы только входите в Product Security, то часть терминов сначала звучит как корпоративная магия. На практике они довольно конкретны. Ценим ниже, разбираем по косточкам.

Термин	Что это означает в работе
Finding	Любой security signal: CVE, SAST finding, DAST issue, misconfiguration, pentest finding, bug bounty report
CVE	Идентификатор публично раскрытой vulnerability
CWE	Класс слабости: SSRF, path traversal, auth bypass, deserialization и т.д.
CVSS	Стандартизированная оценка технической severity
SCA	Software Composition Analysis — поиск vulnerable third-party dependencies
SAST	Static Application Security Testing — анализ исходников/IR без запуска приложения
DAST	Dynamic Application Security Testing — тестирование работающего приложения
SBOM	Software Bill of Materials — inventory компонентов продукта
VEX	Vulnerability Exploitability eXchange — machine-readable statement о применимости/эксплуатируемости vulnerability в конкретном продукте
EPSS	Вероятность наблюдаемой эксплуатации CVE в ближайшие 30 дней по модели FIRST
KEV	CISA Known Exploited Vulnerabilities — каталог уязвимостей с подтверждённой эксплуатацией in the wild
PoC	Proof of Concept exploit; доказательство, что primitive действительно работает
Pre-auth / unauth	Эксплуатация до аутентификации / без учётной записи
Exposure	Насколько система доступна атакующему: Internet, partner, VPN, internal, namespace-local и т.д.
Reachability	Может ли attacker-controlled flow дойти до vulnerable code/function/sink
Entry point	Точка входа: HTTP route, message queue consumer, CLI, file parser, RPC method, webhook и т.д.
Sink	Опасная операция: command execution, SQL query, deserialization, file write, SSRF request и т.д.
Source-to-sink	Поток данных от attacker-controlled input к dangerous sink
Call graph	Граф вызовов функций, полезный для code-level reachability
Taint flow	Анализ распространения недоверенных данных по коду
Attack path	Реальная цепочка от точки входа до security impact
Exploit chain	Несколько primitives/vulnerabilities, объединённых в один attack scenario
Blast radius	Масштаб последствий после успешной compromise
Pivot / lateral movement	Переход с одного скомпрометированного узла к другим системам
Crown jewel	Актив с непропорционально высокой ценностью: CI/CD, IAM, secrets manager, signing infrastructure, production control plane
Compensating control	Контроль, который реально ломает attack path или снижает impact, когда прямой fix пока невозможен
Residual risk	Риск, остающийся после mitigation
Risk acceptance / exception	Формальное временное принятие residual risk с owner, rationale и expiry date
SLA	Срок remediation, согласованный по классу риска
ASPM	Application Security Posture Management — агрегация и корреляция AppSec signals
CNAPP / CSPM	Cloud-native / cloud security posture tooling, где findings уже приходят с cloud context

Mindset инженера: не «закрыть CVE», а доказать (бизнес) риск

Когда я разбирал vulnerability, я старался не начинать с фразы:

«У нас Critical». «Нужен фикс от разрабов, включаем тикет в спринт»

Я начинал с другого, а точнее спрашивал себя и коллег по SecOps:

«Что именно должно произойти, чтобы attacker превратил этот finding в реальный impact?»

Это резко меняет качество анализа. Вместо красной карточки в scanner dashboard появляется attack story:

Actor
  -> Entry point
  -> Trust boundary
  -> Vulnerable component/function
  -> Required privileges/configuration
  -> Exploit primitive
  -> Initial impact
  -> Pivot
  -> Crown jewel / data / production
  -> Business consequence

Если я не мог хотя бы приблизительно построить эту цепочку, значит triage ещё не закончен. И надо парсить дальше, искать доп инфу, консультироваться, а сейчас даже перетереть это с ИИ:)

Восемь вопросов, которые я задаю до назначения priority

1. Finding настоящий?

Сначала sanity check:

правильный ли package/version;
не stale ли SBOM;
не false positive ли fingerprint;
попадает ли binary/image, который реально деплоится, под affected range;
совпадает ли OS/distro/build;
не vendor-patched ли package при старом upstream version string;
присутствует ли component только в build stage, но не в runtime image.

Это applicability.

Плохой triage начинается, когда команда тратит два дня на CVE, которого в production artifact вообще нет.

2. Где этот компонент живёт (слой, сегмент, сервис)?

Дальше нужен deployment context.

Например:

repo -> build -> image -> registry -> Kubernetes -> pod -> service -> route

Нужно понимать про:

dev / test / staging / prod;
public или internal;
tenant-facing или back-office;
container, VM, serverless, bare metal;
ephemeral worker или long-lived controller;
есть ли state, secrets, customer data;
какие identities/service accounts привязаны к workload.

Слово asset criticality начинается именно здесь. Да, мэн, держать четкую карту продукта\инфраструктуры в голове.

3. Есть ли exposure?

Exposure — это не только «торчит ли порт 443 в Интернет».

Вот полезная шкала оценки в процессе рассуждения:

Internet unauthenticated
        ↓
Internet authenticated
        ↓
Partner / customer private network
        ↓
VPN / corporate network
        ↓
Internal service-to-service
        ↓
Namespace / host local
        ↓
Offline / build-only

Иногда internal system опаснее public endpoint, потому что у него намного больше downstream privileges. Например, Jenkins может быть доступен только через VPN, но иметь:

GitLab token;
kubeconfig;
registry credentials;
AWS role;
artifact signing key.

В таком случае «internal only» — не аргумент для автоматического downgrade. Можно найти решение гибче.

4. Reachable ли vulnerable path?

ЗАПОМНИ: Package presence не равна exploitability. Это аксиома. Нужно уметь отличать несколько уровней доказательства. Юзаем шпаргалку ниже.

Лестница reachability evidence

Уровень	Evidence	Что мы реально знаем
L0 — Presence	package/version есть в SBOM	компонент присутствует
L1 — Imported/Linked	код импортирует package	dependency реально используется где-то в приложении
L2 — Function reachability	call graph ведёт к affected symbol	vulnerable function может быть вызвана
L3 — Source-to-sink	taint/data-flow от attacker input к vulnerable sink	controlled data может достичь опасной операции
L4 — Route/exposure	entry point опубликован и reachable через trust boundaries	attacker может инициировать этот flow
L5 — Runtime evidence	tracing/coverage/eBPF/telemetry подтверждает execution path	path реально исполнялся в deployment

Чем выше уровень evidence, тем сильнее вывод. Но важно и обратное: отсутствие статического path не всегда доказывает невозможность эксплуатации. Reflection, dynamic loading, plugin systems, native calls, dependency internals, runtime code generation могут ломать простые call graph assumptions.

Поэтому хороший verdict инженера выглядит не так:

NOT REACHABLE = SAFE

а больше вот так:

No reachable path found with current evidence; confidence: Medium. Reassess if feature/config/runtime changes.

Из open-source tooling хороший пример такого подхода — OSV-Scanner с call analysis: он умеет отделять vulnerabilities в вызываемом коде от package findings, где affected code path не обнаружен. OWASP dep-scan также развивает reachability-aware prioritization и VEX output.

5. Насколько exploit weaponizable?

Technical severity отвечает не на всё. Это тоже аксиома. Запомни это.

Поэтому я смотрю на еще и:

есть ли public PoC;
есть ли functional exploit;
насколько exploit stable;
нужен ли rare prerequisite;
pre-auth ли это;
можно ли автоматизировать массовый scanning;
попал ли CVE в CISA KEV;
какой EPSS probability и percentile;
есть ли vendor warning об active exploitation;
есть ли exploitation в threat reports.

EPSS: probability != percentile

Здесь есть одна ловушка, на которой регулярно спотыкаются даже люди, уже работающие с vulnerability data. Эти два термина похоже, но сука, по разному воспринимаются м путать их НИ-Ни!

EPSS probability и EPSS percentile — не одно и то же.

Probability — абсолютная модельная вероятность наблюдаемой эксплуатации CVE в ближайшие 30 дней. Значение 0.10 означает примерно 10%, а не «низкий балл 0.1 из 10».
Percentile — относительный rank этой probability среди всех CVE, для которых FIRST публикует EPSS. Например, percentile = 0.95 означает, что score выше примерно 95% текущей популяции, а не 95% вероятность эксплуатации.

Из-за того что большая часть CVE никогда не наблюдается в реальной эксплуатации, distribution сильно смещён к нулю. Поэтому даже на первый взгляд небольшая probability может находиться очень высоко по percentile.

Я обычно сохраняю оба значения вместе:

EPSS probability:  0.10 (10%)
EPSS percentile:   0.95 (95th percentile)
EPSS checked_at:   YYYY-MM-DD

checked_at полезен потому, что EPSS обновляется ежедневно: threat signal — не статический атрибут CVE.

И еще одно важное правило: не надо умножать EPSS на CVSS и называть результат risk score. EPSS — калиброванная probability, а CVSS Base — severity model. Такое перемножение создаёт красивое число без понятной статистической интерпретации — FIRST прямо относит подобную практику к misuse.

Здесь полезно различать:
Possible — теоретически возможно.
Feasible — практически реализуемо.
Weaponized — есть готовый exploit / tooling.
Active — уже эксплуатируется in the wild.

Эти состояния требуют разного operational response. Но это уже несколько другая тема и выхолит за скоуп статьи.

6. Что получит attacker после первого шага?

Это вопрос про privilege context. Например, RCE в pod не всегда равно cluster compromise.

Нужно проверить:

UID/root/non-root;
privileged container;
Linux capabilities;
hostNetwork / hostPID / hostPath;
service account token;
Kubernetes RBAC;
cloud IAM role;
mounted secrets;
access to metadata service;
outbound egress;
access to control plane;
registry permissions;
CI/CD secrets.

Один и тот же RCE, который:

RCE in isolated non-root pod

и который:

RCE in privileged deployment controller with cluster-admin

— два разных бизнес-события. Вот тут то видно кто Jun, кто Mid, а кто скиловый прошедший огонь и воду Senior:)

7. Какой blast radius?

После initial access я мысленно спрашиваю себя:

«Что attacker сможет сделать следующим?»

Ценим пример:

Internet
   |
   v
[Nginx]
   |
   v
[API Pod]
   |
   +--> service account
   |
   +--> internal DB
   |
   +--> internal admin API
   |
   +--> container registry
   |
   +--> secrets

Если vulnerability дает только локальный DoS одного stateless replica — один риск. Если она открывает путь к:

cross-tenant data;
production secrets;
signing keys;
build system;
registry write;
IAM privilege escalation;
production deployments;
customer PII;

ТО приоритет резко РАСТЕТ. Это и есть blast radius analysis.

8. Как быстрее всего разорвать attack path?

Здесь важный инженерный shift у себя в мозгу: remediation не равно patch. Patch — это , да, отличный вариант, но не единственный.

Иногда самый быстрый risk reduction:

отключить feature flag;
закрыть route;
убрать Internet exposure;
выключить CLI;
применить WAF/gateway rule;
заблокировать egress;
deny access к metadata;
урезать IAM/RBAC;
убрать secret mount;
изолировать namespace;
rollbackнуть component;
удалить vulnerable package;
rotate credentials;
поставить vendor hotfix;
временно вывести node/service из эксплуатации.

А потом спокойно сделать permanent fix. Именно поэтому хороший Security Engineer влияет не только на что чинить, как закинуть таск в спринт, но и на как уменьшить risk прямо сейчас.

Полный processing chain: как finding превращается в решение

Ниже — pipeline, который я бы дал junior engineer как рабочую карту.

[SCA / SAST / DAST / CNAPP / Pentest / Bug Bounty / Vendor Advisory]
                              |
                              v
                    1. Intake / Normalize
                              |
                              v
                    2. Validate / Dedupe
                              |
                              v
                       3. Applicability
                              |
                              v
                  4. Exposure / Reachability
                              |
                              v
                5. Exploitability / Threat Intel
                              |
                              v
                 6. Asset / Identity / Blast Radius
                              |
                              v
                     7. Business Impact
                              |
                              v
                 8. Compensating Controls
                              |
                              v
                    9. Priority Decision
                              |
                              v
                 10. Treatment / Ownership
                              |
                              v
                    11. Fix Verification
                              |
                              v
               12. Evidence / Exception / Recheck

Теперь разберём, что происходит на каждом шаге. По сути, тебе можно держать эту табличку как шпаргалку

Этап	Главный вопрос	Типичный output
Intake	откуда пришёл signal?	finding ID, source, asset
Validate	finding реальный и уникальный?	confirmed / duplicate / false positive
Applicability	affected ли наш version/build/runtime?	affected / not affected / unknown
Exposure	кто может достучаться?	Internet / auth / VPN / internal
Reachability	можно ли дойти до affected path?	call path / route / taint evidence
Exploitability	насколько реально exploit сделать сейчас?	PoC, EPSS, KEV, active exploitation
Blast radius	что будет после compromise?	identities, secrets, downstream systems
Business impact	что теряет бизнес?	data, money, uptime, compliance, trust
Controls	что ломает цепочку?	WAF, segmentation, IAM, disabled feature
Priority	насколько срочно действовать?	P0/P1/P2/P3 или Critical/High/Medium/Low
Treatment	что делаем?	patch, mitigate, contain, accept, avoid
Verification	риск действительно уменьшился?	retest / scan / telemetry evidence
Recheck	что может сделать решение невалидным?	expiry, reopen triggers

Как выглядит хороший triage ticket

Один из лучших навыков Senior Engineer — уметь превратить шумный scanner output в короткий decision-ready record.

Я бы использовал примерно такой шаблон:

Finding ID:
Source: SCA / SAST / DAST / Pentest / Vendor / Bug Bounty
Asset / Service:
Environment: prod / staging / dev
Owner:

CVE / CWE:
Affected component + version:
CVSS-B / vector:
EPSS probability / percentile:
CISA KEV: yes/no
Public PoC: yes/no/unknown
Active exploitation: yes/no/unknown

Exposure:
Authentication required:
Entry point:
Reachability evidence:
Exploit prerequisites:
Assessment confidence: High / Medium / Low

Runtime identity:
IAM / RBAC context:
Secrets available:
Downstream systems:
Blast radius:
Data classification:

Existing controls:
Control verification evidence:
Residual risk:

Final priority:
Recommended treatment:
Security owner:
Engineering owner:
Due date / SLA:
Exception expiry:
Reopen triggers:

Сравни два handoff’а. И ты поймешь в чем разница:)

Плохой ответ

Critical CVE 9.8. Please patch ASAP.

Хороший ответ

CVE-X присутствует в production image orders-api:v312. Package affected, но vulnerable XML import function не reachable из published routes; feature disabled, call graph path отсутствует, runtime trace не показывает загрузку parser. Internet exposure сервиса есть, но affected route отсутствует. CVE не в KEV; public exploit не обнаружен. Impact при гипотетическом exploit высокий из-за customer data. Priority: P2. Upgrade dependency в ближайшем release train; VEX not_affected/code_not_reachable с expiry 30 дней. Reopen при включении import feature, появлении KEV/working exploit или изменении route table.

Второй вариант позволяет Tech Lead принять решение. Первый — работает либо Jun либо олух. Либо происходит что-то еще:) но не очень хорошее:))

Severity, Risk и Priority — не путайте эти слова

Это одна из самых частых проблем на интервью и в реальной работе.

Severity

Насколько тяжёлым может быть technical impact vulnerability. Обычно здесь CVSS.

Risk

Комбинация likelihood + impact в конкретном контексте организации.

Priority

Насколько быстро мы должны действовать относительно других задач, рисков и ресурсов.

Можно иметь:

High Severity + Low Reachability + Strong Controls = Medium Priority

или:

Medium Severity + Internet Exposure + High Exploitability + Crown Jewel Impact = Critical Priority

И это не противоречие. Это нормальная risk-based prioritization.

Risk Priority != Remediation Difficulty

Это Lead-level нюанс, который очень легко потерять, когда security и engineering начинают спорить о сроках.

То, что vulnerability сложно исправить, не делает её менее рискованной. Сложность fix влияет на treatment plan, но не должна задним числом переписывать assessment.

Я стараюсь держать отдельно минимум пять осей:

Ось	На какой вопрос отвечает
Risk / Priority	Насколько опасно и насколько срочно нужно снизить exposure?
Engineering effort	Сколько работы требует permanent fix?
Change / availability risk	Может ли remediation сломать production, вызвать regression или downtime?
Fix availability	Есть ли patch/upgrade/hotfix или нужен собственный redesign?
Time at risk	Как долго актив уже остаётся под этим риском?

Это даёт гораздо более честную decision model:

	Low remediation effort	High remediation effort / change risk
High risk / high priority	Fix now. Это идеальный P0/P1 quick win.	Contain now, engineer the permanent fix next. Remove exposure, disable feature, reduce privilege, isolate, add a verified control, then patch/redesign safely.
Lower risk / lower priority	Take the quick win если это почти бесплатно и не создаёт regression.	Plan, accept temporarily, or redesign с owner, rationale, expiry и reopen triggers.

Самая опасная ошибка выглядит так:

“Да, это P0, но patch сложный, поэтому давайте назовём finding Medium.”

Нет. Если risk действительно P0, он остаётся P0. Просто immediate response может быть не patch, а containment / mitigation, который быстро разрывает attack path, пока engineering готовит безопасный permanent fix.

И обратная сторона тоже важна: дешёвый fix не обязан автоматически становиться P0. Его можно сделать как quick win, но remediation convenience не является measure of risk.

Смог это объяснить на тех интервью!? Поздравляю, мен, +15% к базовой ставке оффера!

Практическая decision matrix

Я не люблю псевдоточность вида Risk Score = 8.736 из десяти субъективных коэффициентов. Что б**ть за цифры, мы же люди, не машины, говорить нужно понятно. Для инженерной коммуникации часто лучше прозрачная qualitative matrix. Вот она, цени ниже.

Signal	Low	Medium	High	Critical signal
Severity	limited impact	material impact	major C/I/A	RCE, auth bypass, systemic compromise
Exposure	offline/local	internal	customer/partner reachable	Internet unauthenticated
Reachability	proven unreachable	uncertain	static reachable	input-to-sink / runtime confirmed
Exploit maturity	theoretical	PoC with constraints	functional exploit	KEV / active exploitation
Asset criticality	disposable	internal supporting	important production	IAM, CI/CD, secrets, control plane
Blast radius	isolated	one service	several systems/data	supply chain / cross-tenant / org-wide
Controls	strong verified	partial	weak	absent/bypassable
Confidence	low evidence	mixed	strong	multiple independent evidence sources

Я бы затем переводил это в operational class. Разберем их ниже.

P0 / Critical

Типичный профиль:

Internet-facing или easy lateral reach;
pre-auth / unauth;
reachable vulnerable path;
KEV / active exploitation / reliable weaponized exploit;
crown-jewel asset;
большой blast radius;
controls отсутствуют или обходятся.

Action: containment сейчас, remediation emergency lane, incident-assumption при необходимости, credential rotation, IOC review.

P1 / High

exploit path реален;
asset важный;
exploitation feasible;
impact высокий;
есть частичный mitigation или active exploitation пока не подтверждена.

Action: expedited fix, short SLA, named owner, tracking до closure.

P2 / Medium

vulnerability применима;
требует authentication/config/prerequisite;
blast radius ограничен;
controls действительно работают.

Action: normal release cycle с конкретной датой.

P3 / Low / Temporarily Accepted

component присутствует, но affected function недостижима с хорошим evidence;
feature отключена;
required configuration отсутствует;
exposure минимален;
compensating controls подтверждены.

Action: документированный exception/risk acceptance, owner, expiry и reopen conditions.

Risk acceptance без срока пересмотра — это не risk management. Это архивирование проблемы.

Где здесь CVSS v4, EPSS, KEV, SSVC и VEX и как, с*ка это все запомнить

Эти инструменты не конкурируют. Они отвечают на разные вопросы. Если забыл про один, но помнишь два других - ОК. Важно не столько "помнить" сколько "понимать", никто не запрещает юзать шпоры) Да же я когда преподавал в универе, то разрешал ребятам на экзамене использовать конспекты

Framework / Signal	На какой вопрос отвечает
CVSS-B	насколько vulnerability тяжёлая технически сама по себе?
CVSS Threat metrics	как меняется threat state / exploit maturity?
CVSS Environmental	как deployment и importance системы меняют severity context?
EPSS	какова модельная вероятность observed exploitation в ближайшие 30 дней?
CISA KEV	есть ли подтверждённая exploitation in the wild?
SSVC	какое response decision принять через decision tree?
VEX	affected ли конкретный product и как формально передать exploitability status?

CISA SSVC особенно полезен как mindset: вместо «score worship» он использует decision tree и учитывает состояние эксплуатации и impact. В модели CISA возможны outcomes вроде Track, Track*, Attend, Act.

Я не предлагаю копировать SSVC один в один в любую компанию. Но сама идея очень правильная: цель assessment — не получить красивое число, а принять response decision.

Кейс 1: CVSS 9.8, но attack path отсутствует

Представим production platform. Анонимно, детали под NDA, но суть сохранена.

                         Internet
                            |
                            v
                       [Cloud LB]
                            |
                            v
                     [Nginx Ingress]
                            |
                            v
                     [Istio Gateway]
                            |
                            v
                  +-------------------+
                  | orders-api Pod    |
                  | app + sidecar     |
                  +-------------------+
                     |            |
                     v            v
                [PostgreSQL]   [Kafka/MQ]

CI/CD:
Developer -> GitLab -> Jenkins -> Registry -> Kubernetes

SCA находит vulnerable XML parsing dependency с CVSS 9.8. Scanner dashboard становится красным. Формальный SLA говорит «Critical».

Что делает inexperienced engineer

Создаёт Jira:

Upgrade immediately. CVSS 9.8.

Что делает Senior Product Security Engineer

Проверяет applicability и path.

Package действительно есть в runtime image.
Affected function используется только модулем legacy XML import.
Feature flag xml_import=false в production.
Route для import отсутствует в Nginx/Istio config.
Static call graph не находит path от HTTP handlers к affected parser.
Runtime tracing не показывает загрузку этого parser за наблюдаемый период.
NetworkPolicy не является главным justification, но дополнительно ограничивает lateral path.
Нет KEV / active exploitation signal, который бы заставил пересмотреть conservative assumptions.

Reachability verdict

Package present:        YES
Affected version:       YES
Imported:               YES
Affected function:      NOT REACHED by current static evidence
Published route:        NO
Feature enabled:        NO
Runtime observed path:  NO
Confidence:             MEDIUM-HIGH

Решение

Technical severity остаётся Critical.

Operational priority может стать P2, потому что текущий deployed product не предоставляет attacker path к affected function.

Но я бы не делал close and forget.

Я бы сделал:

upgrade dependency в ближайшем release train;
VEX statement not_affected с justification типа code_not_reachable, если ваша схема VEX это поддерживает;
приложил evidence;
назначил expiry;
добавил reopen triggers.

Например:

Reopen if:
- XML import feature enabled;
- route published;
- dependency behavior changes;
- working exploit changes assumptions;
- CVE enters KEV;
- architecture / call path changes.

Урок: мы не «проигнорировали Critical». Мы доказали текущую неэксплуатируемость с заданным confidence и поставили автоматические условия пересмотра.

Кейс 2: формально «не RCE», но priority становится Critical

Теперь противоположный пример. Ценим, мотаем на ус:)

Internet
   |
   v
[CDN / WAF]
   |
   v
[Nginx Ingress]
   |
   v
[image-preview API]
   |
   |  outbound fetch
   v
[internal/cloud endpoints]
   |
   +--> metadata / workload identity (if reachable)
   +--> internal admin services
   +--> storage
   +--> registry

В функции preview обнаружен SSRF.

Первое впечатление:

прямого RCE нет;
endpoint «всего лишь качает картинку»;
scanner может присвоить Medium/High;
команда хочет положить issue в обычный backlog.

Теперь context review.

Exposure

endpoint Internet-facing;
account не требуется;
requests легко автоматизировать.

Reachability

attacker controls URL;
URL попадает в outbound HTTP client;
egress unrestricted;
allowlist отсутствует.

Identity context

Workload имеет cloud identity и доступ к internal resources.

Blast radius

Успешный SSRF потенциально превращается в:

Internet actor
   -> SSRF primitive
   -> internal/cloud endpoint access
   -> credentials / internal service access
   -> data or registry compromise

Что делать

Патчить код нужно. Но fast containment может быть быстрее:

disable preview feature;
outbound allowlist;
block link-local/metadata destinations;
egress NetworkPolicy;
reduce workload IAM;
separate fetcher into isolated workload;
require auth/rate limits если это соответствует продукту;
затем permanent code fix.

Итог

Technical severity:   Medium/High
Internet exposure:    Critical signal
Reachability:         Confirmed
Exploit automation:   High
Business impact:      High/Critical
Controls:             Weak
Priority:             P0/P1

Урок: отсутствие RCE не делает vulnerability «некритичной». В Product Security важен exploit chain, а не название CWE.

Кейс 3: TeamCity CVE-2023-42793 — когда почти все сигналы смотрят в одну сторону

Теперь реальный пример. Можешь сам погуглить:)

В 2023 году вендор JetBrains раскрыл CVE-2023-42793 в TeamCity On-Premises. Vendor описал scenario, при котором unauthenticated attacker с HTTP(S) access мог получить RCE и административный контроль TeamCity server. JetBrains выпустила исправление в 2023.05.4 и patch plugin для старых версий. Херовая бага... для них:) И сейчас поймешь почему.

Позже JetBrains сообщила о наблюдаемой эксплуатации, включая активность nation-state actors. CISA добавила CVE в KEV.

Представим enterprise deployment:

Internet / Corp Network
          |
          v
   [TeamCity Server]
          |
          +----> GitLab repos
          |
          +----> Build agents
          |
          +----> Docker Registry
          |
          +----> Artifact repository
          |
          +----> Kubernetes deploy token
          |
          +----> Cloud secrets / IAM

Здесь contextual signals:

Severity: Critical;
Exposure: если public — Critical; если internal — всё равно material;
Reachability: direct HTTP(S);
Auth requirement: pre-auth/unauth в vulnerable scenario;
Threat intel: active exploitation;
KEV: yes;
Asset criticality: CI/CD crown jewel;
Blast radius: source + artifacts + deployments + secrets;
Supply-chain impact: возможен downstream compromise.

В этот момент спор «9.8 или 10.0?» практически бесполезен.

Хороший response

Contain — убрать public exposure/ограничить access, если patch не мгновенный.
Patch/upgrade — применить vendor fix.
Hunt — проверить IOCs, логи, abnormal behavior.
Assume credential exposure where justified — оценить, какие secrets были доступны TeamCity.
Rotate — deployment tokens, registry creds, cloud credentials при необходимости.
Inspect downstream — build agents, artifacts, releases.
Restore — только после проверки.

Урок: mature vulnerability management иногда должен перейти из обычного remediation в incident-response mode.

Ещё три коротких real-world anchor’а

Jenkins CVE-2024-23897

Jenkins описал arbitrary file read через CLI, который в определённых условиях мог приводить к более серьёзным последствиям, включая RCE scenarios. Vendor отдельно описал prerequisites и workaround: временное отключение CLI могло предотвратить exploitation до upgrade.

Что это хорошо показывает:

название finding’а «file read» может недооценивать downstream impact;
prerequisites важны;
configuration и encoding могли влиять на практическую exploitability;
temporary mitigation может быть правильным first response, пока идёт patching.

XZ Utils CVE-2024-3094

XZ backdoor показал другую сторону contextual analysis: громкое событие не означает, что every Linux host одинаково affected.

Нужно было выяснять:

exact version;
distro/build;
package provenance;
runtime interaction;
присутствует ли malicious build в конкретной системе.

Red Hat, например, отдельно указывала affected Fedora builds и то, что RHEL не был затронут.

Урок: inventory + provenance + applicability могут быть важнее самой headline severity.

HTTP/2 Rapid Reset CVE-2023-44487

Для public high-volume edge сервисов availability issue может быть P0, даже если речь не идёт о code execution или data theft.

Урок: CIA impact должен оцениваться относительно business function. Availability иногда важнее Confidentiality.

Compensating controls: не верьте архитектурной диаграмме на слово

Одна из самых опасных фраз на triage call:

«У нас же WAF».

Хорошо. Какой rule? Какой exploit primitive он блокирует? Проверяли ли bypass? На каком edge? Доходит ли traffic в обход него? Есть ли alternate route?

То же самое с:

NetworkPolicy;
service mesh authz;
VPN;
MFA;
EDR;
runtime protection;
least privilege;
egress deny;
secret isolation.

Compensating control должен быть связан с attack path. Иначе, простите, это Г**но, а не контроль:))

Например:

Attacker
   |
   v
[Ingress]
   |
   v
[API Pod]
   |
   +------X------> Metadata
          |
      egress deny
      VERIFIED

Здесь control действительно ломает конкретный edge в attack graph. А запись «WAF enabled» без proof — почти ничего не значит.

Что значит «влиять на решение» как Senior Engineer

Когда я говорю, что инженер должен влиять на решение, я не имею в виду, что Security единолично решает судьбу релиза. Хорошая модель выглядит так:

Security приносит описание\расшифровку

exploit mechanics;
reachability evidence;
threat intel;
likely attack path;
blast radius;
mitigation options;
residual risk.

Engineering (DEV) приносит

implementation reality;
release constraints;
regression risk;
patch complexity;
feature dependencies.

Product / Business owner приносит

customer impact;
contractual commitments;
revenue/availability context;
acceptable downtime;
risk appetite.

Leadership принимает или делегирует decision

fix now;
ship with mitigation;
feature off;
rollback;
emergency maintenance;
documented exception;
accept residual risk.

Security Engineer здесь — decision enabler, а не человек, который только генерирует "красные тикеты". Короче, хоть грейд у него и ниже, а ЗП меньше чем у Head, без его оценки никуда, без его работы никак!

Risk treatment: у вас больше вариантов, чем «patch / no patch»

В NIST risk management обычно встречаются базовые стратегии: mitigate, avoid, transfer, accept. В vulnerability workflow их можно перевести в более инженерный язык.

Treatment	Пример
Remediate	upgrade/fix code
Mitigate	WAF rule, egress block, auth requirement
Contain	isolate host, remove Internet exposure
Avoid	disable/remove vulnerable feature
Reduce privilege	IAM/RBAC hardening, remove secrets
Detect	compensating monitoring/alerting while patch is pending
Rollback	return to safe version
Rotate	invalidate potentially exposed creds
Accept temporarily	documented exception with expiry
Redesign	architectural change to eliminate class of risk

Очень важно: mitigation должен снижать either likelihood or impact. Если он не меняет attack path и не уменьшает последствия — это не mitigation, а чувство безопасности.

Кто участвует в assessment

Хороший triage редко делается одним человеком. Это вероятно только для очень не зрелых команд и маленктих компаний\стартапов.

Роль	Что она знает лучше других
Product Security / AppSec	vulnerability mechanics, code path, abuse case
Senior Developer	actual implementation, feature flags, call paths
Platform / Cloud Security	IAM, network, Kubernetes, cloud controls
SRE / Infra	deployment reality, topology, operational impact
Service Owner	customer/business criticality
Threat Intel / SOC	exploitation activity, IOCs, campaigns
Security Lead	risk appetite, exceptions, cross-team priority

Зрелость (mature) — это не когда Security знает все и может процитировать на память. Зрелость — когда процесс быстро собирает нужный context у правильных владельцев. Дальше это все коллегиально обсуждается, принимается общее решение основанное на фактах, верстается оно в action plan. И далее раздается на уровни ниже для реализации (Sec, Dev, Ops, QA, etc)

Три уровня мышления: Junior, Senior, Lead

Если вы Junior / кандидат, новичок

Ваша цель — научиться не верить одному scanner output.

Минимальный набор:

понять CVE/CWE;
найти affected version;
определить asset;
проверить exposure;
понять auth/prerequisites;
проверить PoC/KEV/EPSS;
поговорить с developer о code path;
описать impact;
предложить remediation + mitigation.

Если вы это умеете, вы уже мыслите намного ближе к Product Security Engineer, чем человек, который просто сортирует CVEs по CVSS.

Если вы Senior Engineer

От вас ждут:

ownership triage;
attack-path reasoning;
confidence-based conclusions;
хорошую коммуникацию с dev/platform;
business translation;
viable treatment options;
verification after fix;
правильный exception process.

Senior не просто говорит «все плохо или все норм». Senior говорит:

«Вот path, вот evidence, вот impact, вот три способа снизить risk, вот самый дешёвый по времени, вот residual risk.»

Если вы Tech Lead / Security Lead

Вопрос уже не только про один finding. Нужно построить систему:

common triage rubric;
risk taxonomy;
ownership model;
SLAs;
exception workflow;
KEV/EPSS enrichment;
SBOM/VEX integration;
duplicate suppression;
re-open triggers;
metrics качества.

Полезные lead-level metrics:

MTTR по risk class, а не просто CVSS;
age of reachable Critical/High findings;
KEV exposure time;
Internet-exposed exploitable findings;
exceptions past expiry;
percentage findings with confirmed owner;
false-positive/duplicate rate;
percentage SCA findings с reachability evidence;
time from finding to containment;
recurrence rate по CWE/root cause.

Это уже vulnerability management как engineering system, а не spreadsheet. Вообщем, здесь уже меньше технарьщины и больше про outcomes.

Как ответить на интервью: «How do you prioritize vulnerabilities?»

Короткий хороший ответ на уровне Product Security:

«Я не использую CVSS как единственный priority signal. Сначала подтверждаю applicability и deployment context, затем смотрю exposure и reachability до vulnerable function, после этого добавляю exploit intelligence — EPSS, KEV, public PoC и active exploitation. Дальше оцениваю asset criticality, runtime identity, blast radius и business impact, проверяю compensating controls и только потом назначаю remediation priority. Для меня главное — построить attack path и выбрать response, который быстрее всего снижает residual risk: patch, isolation, feature disablement, IAM reduction или временный documented exception.»

Если кандидат отвечает примерно так — я понимаю, что он уже мыслит не scanner’ом, а risk system. И это Mid как минимум, а то и Mid+ or Senior. Больше скилл = больше экспертизы = больше ответственности = больше salary:)

Что автоматизировать, а что оставить человеку

Автоматизация (ИИ в том числе) отлично справляется с:

inventory;
SCA/CVE matching;
CVSS enrichment;
EPSS;
KEV flags;
Internet exposure signals;
cloud asset metadata;
basic reachability;
duplicate correlation;
SLA routing.

Человек всё ещё нужен для:

business impact;
strange architecture;
dynamic code paths;
exploit-chain reasoning;
control validation;
exception justification;
trade-off между risk и delivery;
confidence assessment.

Поэтому ASPM/CNAPP/SCA evolution идёт в сторону context correlation, но полностью «автоматический risk score» всё ещё нужно воспринимать осторожно.

Типовые ошибки\заблуждения, которые могут сэконоить время

Ошибка 1. CVSS = риск

Нет. Это severity input.

Ошибка 2. Package present = vulnerable path reachable

Нет. Нужен applicability/reachability analysis.

Ошибка 3. Internal = safe

Нет. Internal crown jewel может быть опаснее edge service.

Ошибка 4. Есть WAF = mitigated

Только если конкретный rule действительно ломает exploit primitive.

Ошибка 5. Нет public PoC = можно забыть

Нет. PoC — только один threat signal.

Ошибка 6. Patch deployed = ticket можно закрыть

Нет. Нужен verification: новая версия, rescan/retest, отсутствие vulnerable artifact/path.

Ошибка 7. Risk accepted = навсегда

Нет. Нужны owner, expiry и reopen trigger.

Ошибка 8. Security должен всегда требовать fix

Нет. Security должен обеспечить правильное решение по риску.

Небольшой practical model для команды

Если строишь процесс с нуля (from scratch), я бы начал не с сложного scoring engine, а с пяти обязательных полей:

1. Exposure
2. Reachability
3. Exploit status
4. Asset/business criticality
5. Verified controls

И добавил meta-field:

Assessment Confidence: Low / Medium / High

Почему confidence важен?

Потому что:

"Not reachable, confidence HIGH"

"Not reachable, because scanner didn't find anything, confidence LOW"

ТУТ, как видишь, совершенно разные решения.

Финальная модель

Я бы визуализировал современный vulnerability triage так:

                    +----------------------+
                    | Finding / CVE / CWE  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Applicability        |
                    | version/build/runtime|
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Exposure             |
                    | Internet/Auth/Trust  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Reachability         |
                    | route/call/taint     |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Exploitability       |
                    | CVSS/EPSS/KEV/PoC    |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Identity + Blast     |
                    | Radius + Crown Jewels|
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Business Impact      |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Verified Controls    |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Risk / Priority      |
                    | P0 / P1 / P2 / P3    |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Treatment            |
                    | Fix/Mitigate/Accept  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Verify + Reassess    |
                    +----------------------+

И здесь CVSS остаётся важным. Просто он больше не сидит на вершине трона. Он занимает своё правильное место: один из входных signals в инженерную систему принятия решений.

Главное

Когда я был инженером, моя задача не сводилась к тому, чтобы найти vulnerability и назвать её Critical.

Моя задача была сделать проблему понятной и помочь команде принять правильное решение.

Иногда правильное решение — emergency patch.
Иногда — выключить feature за 15 минут и patch сделать завтра.
Иногда — закрыть Internet route.
Иногда — урезать IAM и разорвать exploit chain.
Иногда — задокументировать, что vulnerable code path в нашем продукте реально недостижим, и спокойно исправить dependency в следующем release.

Но любое из этих решений должно быть основано на evidence, а не на ощущении.

Не спрашивай только: «Какой CVSS?»

Спрашивай: «Это применимо к нам? Может ли attacker добраться до vulnerable path? Насколько вероятна эксплуатация? Что он получит после первого шага? Какой blast radius? Что потеряет бизнес? И как быстрее всего разорвать attack path?»

Вот в этот момент vulnerability management перестаёт быть сортировкой красных строк в dashboard и становится настоящей Product Security engineering discipline.

Бесплатный toolbox: куда я захожу во время vulnerability triage

Ни один внешний портал не знает вашу architecture, identities, trust boundaries и business impact. Но несколько бесплатных источников могут очень быстро закрыть часть fact-finding.

Resource	Для чего я бы использовал	Что помнить
FIRST EPSS	Probability + percentile, history, API и ежедневный CSV. Отличный enrichment для большого backlog.	Это forecast exploitation, а не ваш полный risk score.
CISA KEV	Быстро проверить, есть ли подтверждённая exploitation in the wild.	KEV — сильный threat signal, но всё равно нужно подтвердить applicability к вашему продукту.
Rapid7 Vulnerability & Exploit Database	Очень удобный визуальный CVE browser: CVSS v3/v4, EPSS, `Exploited in the Wild`, наличие Metasploit module и emergent-threat research.	Хорош для быстрого analyst view; final verdict всё равно сверяйте с vendor advisory и вашим environment.
OSV.dev + OSV-Scanner	Open-source dependencies, lockfiles/SBOM/container images, fixed versions, HTML/JSON/SARIF; для поддерживаемых языков есть call analysis.	`called=false` или отсутствие найденного path — evidence, а не абсолютное доказательство безопасности. Dynamic loading/reflection всё ещё важны.
ProjectDiscovery CVEMap	Быстрый CLI/enrichment: CVSS, EPSS, KEV, PoC, Nuclei coverage, age и фильтрация; удобно для shell/JSON automation.	Это агрегатор. Для critical decision проверяйте первоисточники и vendor advisory.

И я всё равно держу рядом NVD как хороший baseline для CVE/CVSS/CWE/CPE и references. Сам NVD отдельно подчёркивает, что CVSS — это severity, а не risk.

Zero-budget triage в Excel / Google Sheets

Если ASPM/VM platform пока нет, можно собрать surprisingly useful workflow буквально из CSV и нескольких enrichment sources.

Выгрузить findings из SCA/VM/scanner в CSV.
Подтянуть EPSS probability + percentile из FIRST API/CSV.
Добавить флаг KEV.
Заполнить руками или из asset inventory локальный context.
Фильтровать backlog уже не только по CVSS.

Я бы использовал такие колонки:

CVE / Finding ID
Asset / Service
Environment
Owner
CVSS + Vector
EPSS Probability
EPSS Percentile
EPSS Checked At
KEV Y/N
Public PoC / Exploit Y/N
Internet Exposure
Authentication Required
Reachability
Reachability Evidence
Runtime Identity / Privileges
Asset Criticality
Blast Radius
Business Impact
Compensating Controls
Assessment Confidence
Risk Priority
Remediation Effort
Change Risk
Treatment
SLA / Due Date
Exception Expiry
Reopen Triggers

FIRST публикует EPSS как API и daily CSV, поэтому его легко JOIN-нуть по CVE даже без коммерческого tooling. Главное — не пытаться превратить spreadsheet в магический formula engine: таблица должна сохранять evidence и помогать принять решение, а не скрывать reasoning за непрозрачным score.

References and further reading

FIRST — CVSS v4.0 User Guide https://www.first.org/cvss/v4.0/user-guide
FIRST — CVSS v4.0 Specification https://www.first.org/cvss/v4.0/specification-document
FIRST — Exploit Prediction Scoring System (EPSS) https://www.first.org/epss/
FIRST — EPSS FAQ https://www.first.org/epss/faq
CISA — Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog
CISA — Stakeholder-Specific Vulnerability Categorization (SSVC) https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
CISA — SBOM / VEX Resources Library https://www.cisa.gov/topics/cyber-threats-and-advisories/sbom/sbomresourceslibrary
CycloneDX — Vulnerability Exploitability eXchange (VEX) https://cyclonedx.org/capabilities/vex/
NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning https://csrc.nist.gov/pubs/sp/800/40/r4/final
NIST IR 8179 — Criticality Analysis Process Model https://csrc.nist.gov/pubs/ir/8179/final
NIST IR 8286B — Prioritizing Cybersecurity Risk for Enterprise Risk Management https://www.nist.gov/publications/prioritizing-cybersecurity-risk-enterprise-risk-management-0
OWASP — Risk Rating Methodology https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
OWASP — Vulnerable Dependency Management Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html
Google — OSV-Scanner Call Analysis https://google.github.io/osv-scanner/output/
OWASP dep-scan — Reachability-aware dependency analysis https://github.com/owasp-dep-scan/dep-scan
JetBrains — CVE-2023-42793 TeamCity security issue https://blog.jetbrains.com/teamcity/2023/09/critical-security-issue-affecting-teamcity-on-premises-update-to-2023-05-4-now/
JetBrains — CVE-2023-42793 exploitation update https://blog.jetbrains.com/teamcity/2023/10/cve-2023-42793-vulnerability-in-teamcity-october-18-2023-update/
Jenkins — Security Advisory 2024-01-24 / CVE-2024-23897 https://www.jenkins.io/security/advisory/2024-01-24/
Red Hat — CVE-2024-3094 / XZ Utils alert https://www.redhat.com/en/blog/urgent-security-alert-fedora-40-and-rawhide-users
FIRST — EPSS Get the Data (API + daily CSV) https://www.first.org/epss/data
Rapid7 — Vulnerability & Exploit Database https://www.rapid7.com/db/
ProjectDiscovery — CVEMap https://github.com/projectdiscovery/cvemap
NIST — National Vulnerability Database (NVD) https://nvd.nist.gov/

Software Integrity глазами Security Director или нескромный вопрос о том как искать backdoors и недекларированные возможности в коммерческом ПО

Ivan's Cybersecurity Notes — Tue, 27 Oct 2026 05:00:00 +0000

Software Integrity глазами Security Director ИЛИ размышления о том как искать backdoors и недекларированные возможности (НДВ в терминологии ФСБ и ФСТЭК РФ), проверять source → build → binary → update chain и снижать риск скрытого поведения в критичном коммерческом ПО

Проблема гораздо старше DevSecOps и серьезнее чем просто AppSec

Во времена, когда software supply chain ещё не называли supply chain (лет так 15 назад, а то и более), государства уже задавались тем же вопросом: можно ли доверять устройству, если его спроектировал, изготовил или обновляет кто-то другой?

Хороший исторический пример — швейцарская Crypto AG. Расследование, опубликованное в 2020 году, показало, что компания десятилетиями поставляла криптографическое оборудование множеству государств, при этом CIA и западногерманская разведка тайно контролировали производителя и могли использовать ослабленные системы для чтения защищённых коммуникаций. Документы указывали, что оборудование Crypto AG использовали более 120 стран. The Washington Post — The intelligence coup of the century

Это не AppSec в современном смысле термина и тем более не DevSecOps. Там не было pull request, SAST gate или SBOM. Однако, внимание, фундаментальная проблема была той же:

Trust in the supplier becomes trust in the product.

В 1984 году Ken Thompson в знаменитой лекции Reflections on Trusting Trust показал ещё более неприятную версию той же идеи: даже чистый source code не гарантирует чистый binary, если компилятор или toolchain уже скомпрометирован. Его короткая фраза до сих пор звучит современно: “You can't trust code that you did not totally create yourself.” ACM — Reflections on Trusting Trust

А проблема аппаратного доверия никуда не исчезла после холодной войны (70-е и 80-е годы технологического противостояния США и Великого СССР). DARPA, например, запускала программу TRUST in Integrated Circuits именно для разработки методов обнаружения malicious circuits в микросхемах, спроектированных или произведённых в недоверенной среде. DARPA — TRUST

Сегодня тот же вопрос пришёл в коммерческий Product Security.

Возьмём не военный объект, а обычный enterprise product:

core banking platform;
payment switch;
electronic trading platform;
database engine;
IAM/IdP;
HSM management software;
EDR или network appliance;
industrial control software;
SaaS agent с privileged access на тысячи endpoints.

Такие продукты работают с PII, ключами, платёжными инструкциями, order books, privileged credentials и customer data. Они автоматически обновляются, получают remote configuration, загружают plugins, телеметрию и policy. И очень часто один vendor binary получает доверие на тысячи или миллионы систем.

Обычный Product Security задаёт знакомый вопрос:

Можно ли похэкать наш продукт из-за ошибки\бага?

Для этого у нас есть SAST, DAST, SCA, secret scanning, threat modeling, fuzzing, IaC scanning, container security и API testing. Все ОК! Да!

Но Software Integrity задаёт другой вопрос:

А что если опасное поведение — не ошибка? Что если оно было добавлено намеренно или появилось в source, dependency, build process, release artifact, firmware или update channel?

NIST SP 800-161 Rev. 1 формулирует этот риск буквально как возможность того, что приобретаемые продукты и сервисы могут содержать “potentially malicious functionality.” NIST SP 800-161 Rev. 1

Именно поэтому я рассматриваю эту задачу не как «ещё один scanner», а как отдельный, ВНИМАНИЕ, отдельный assurance track внутри трека Product Security:

SOFTWARE INTEGRITY & MALICIOUS FUNCTIONALITY ASSURANCE

Для меня он должен отвечать на четыре вопроса:

Что продукту вообще разрешено делать?
Соответствует ли проверенный source тому artifact, который реально получил клиент?
Что shipping binary действительно делает во время выполнения?
Что произойдёт, если vendor, update channel или control plane окажется hostile?

Если ответы на эти вопросы доказуемы, разговор о backdoors (НДВ в терминологии ФСТЭК) перестаёт быть конспирологией и становится обычной инженерией доверия.

Что я называю backdoor или недекларированной возможностью

Терминология здесь неидеальна. Backdoor обычно означает механизм, позволяющий обойти нормальные security controls или получить скрытый доступ. Но реальный класс проблем шире.

MITRE CWE использует, например:

CWE-506 — Embedded Malicious Code
CWE-510 — Trapdoor

CWE-506 описывает продукт, содержащий код, который выглядит вредоносным по своей природе. MITRE CWE-506

На практике я разделяю потенциально недекларированное поведение как минимум на несколько типов. Смотрим внимательно! Товарищ майор на экзамене будет спрашивать :)

Тип	Пример
Hidden authentication bypass	специальный token/header/credential открывает административный доступ
Logic bomb	функция активируется по дате, hostname, license ID или другому триггеру
Remote kill switch	удалённая конфигурация может отключить критическую функцию
Undocumented admin/debug interface	скрытый API, port, command или maintenance account
Covert data exfiltration	данные отправляются на endpoint, которого нет в архитектуре продукта
Build-time injection	source repository чистый, payload добавляется при сборке
Malicious dependency	вредоносная логика приходит из npm/PyPI/Maven/Go module и т.д.
Binary-only modification	shipping artifact содержит код, отсутствующий в проверенном source
Malicious update	легитимный update channel доставляет вредоносную версию
Firmware implant	поведение находится ниже OS/app layer: UEFI, BMC, controller firmware и т.п.

Важно отделять намеренный backdoor от просто плохого дизайна. Например, undocumented maintenance endpoint может быть создан инженером для поддержки и не иметь злого умысла. Но с точки зрения Product Security результат может быть практически тем же: появляется привилегированный путь, который не учитывался в threat model.

Intent сложнее доказать, чем capability.

Поэтому на практике я предпочитаю начинать не с вопроса «кто это сделал и зачем?», а с более инженерного:

Какие security-sensitive capabilities существуют в продукте, какие из них задекларированы и какие доказательства у нас есть, что shipping artifact соответствует ожидаемому поведению?

Почему классика в виде SAST и DAST не решают эту задачу

SAST отлично ищет классы ошибок:

injection;
path traversal;
insecure deserialization;
memory corruption;
SSRF;
broken crypto;
unsafe API usage.

Но backdoor может быть идеально корректным кодом.

Условный пример:

def authorize(request, user):
    if normal_policy_allows(user, request):
        return True

    if feature_flags.get("emergency_support_mode") and \
       request.headers.get("X-Support-Token") == SECRET_VALUE:
        return True

    return False

Здесь может не быть ни SQL injection, ни buffer overflow. С точки зрения компилятора и SAST всё прекрасно. Проблема в другом: должна ли такая capability вообще существовать?

DAST сталкивается с другой проблемой — trigger space. Если скрытая функция активируется только когда одновременно выполняются условия:

date > X
AND region == Y
AND hostname hash == Z
AND remote configuration contains flag Q

обычный dynamic scan может никогда не попасть в нужное состояние. Есть ещё три распространённых заблуждения.

Code signing не означает, что код безопасен

Подпись отвечает примерно на вопрос:

«Этот artifact действительно подписан ожидаемой identity».

Она не отвечает на вопрос:

«Эта identity не подписала вредоносный artifact».

Authenticity и benignness — разные свойства.

SBOM не доказывает отсутствие backdoor

SBOM отвечает:

«Что входит в продукт?»

Это критически важно, но SBOM сам по себе не говорит:

«Поведение всех этих компонентов безопасно и соответствует спецификации».

Проверка source не доказывает, что именно этот source попал клиенту

Между Git commit и product-7.4.1.tar.gz находятся:

CI runner;
compiler;
build scripts;
package manager;
artifact repository;
signing system;
release automation.

И любой из этих элементов может стать точкой внедрения.

Семь кейсов: одна проблема, разные точки внедрения

Теория полезна, но реальные incident patterns намного лучше объясняют, зачем нужен отдельный Software Integrity track.

1. Crypto AG: доверие к поставщику как часть модели угроз

Crypto AG — исторический, но очень чистый пример. Пользователь покупал security product именно потому, что доверял его криптографической функции. Если сам поставщик или его design process находится под чужим контролем, обычная проверка эксплуатации продукта не отвечает на главный вопрос: соответствует ли заявленная security property реальной?

Урок: vendor trust — это security dependency.

2. M.E.Doc / NotPetya: финансовое приложение как канал доставки

В июне 2017 года Microsoft сообщила, что первоначальная доставка Petya/NotPetya шла через update service украинского финансового приложения M.E.Doc. Microsoft MSRC — Update on Petya malware attacks

Для банковского или финансового threat model это особенно наглядно: бухгалтерское/финансовое ПО само по себе может быть trusted business dependency, но его update mechanism становится privileged distribution channel внутри customer network.

Урок: secure application + insecure update chain = insecure product.

3. CCleaner: valid signature не означает benign artifact

В 2017 году Cisco Talos обнаружила, что легитимно подписанный CCleaner 5.33, распространявшийся с официальных download servers, содержал multi-stage malware payload. Cisco Talos — CCleanup: A Vast Number of Machines at Risk

Это очень полезный контрпример для любого release process:

valid signature
      !=
benign software

Code signing доказывает identity и integrity после подписи. Оно не доказывает, что подписывающая сторона не подписала уже скомпрометированный artifact.

4. SolarWinds Orion: trusted update масштабирует компрометацию

В 2020 году CISA квалифицировала инцидент SolarWinds как software supply-chain compromise. В SEC filing SolarWinds указывала, что до 18 000 клиентов могли скачать затронутые версии Orion, хотя число организаций, реально скомпрометированных через SUNBURST, было существенно меньше. CISA · SolarWinds SEC filing

Урок: legitimate distribution channel масштабирует не только fixes, но и compromise.

5. XZ Utils: Git repository — ещё не весь release source

XZ стал почти идеальным учебным кейсом. Andres Freund вышел на проблему не потому, что scanner написал backdoor detected, а потому что увидел странные runtime symptoms: необычную загрузку CPU при SSH login и ошибки Valgrind. В исходном сообщении он отдельно отметил, что часть backdoor chain находилась только в distributed tarballs и отсутствовала в Git tree. oss-security — Andres Freund, 29 March 2024

Уроки сразу два:

review Git ≠ verify release artifact;

иногда performance anomaly или behavioral diff обнаруживает то, чего не нашёл static gate.

6. X_TRADER → 3CX: supply-chain compromise может быть каскадным

В 2023 году Mandiant описала редкий и очень показательный сценарий: первоначальная компрометация 3CX началась с trojanized X_TRADER, software package компании Trading Technologies. Затем attackers получили доступ в 3CX и скомпрометировали уже её Windows и macOS build environments, после чего malicious code распространялся через 3CX Desktop App. Mandiant назвала это первым известным ей случаем, когда одна software supply-chain compromise привела к другой. Mandiant — 3CX Software Supply Chain Compromise

Особенно неприятная деталь: 3CX сообщала, что X_TRADER installer был digitally signed valid certificate и загружен с сайта vendor. 3CX incident update

Для electronic trading / fintech threat model это почти готовый tabletop scenario.

7. Juniper ScreenOS: unauthorized code внутри security product (е#ть дела!)

В 2015 году Juniper сообщила, что internal code review обнаружил “unauthorized code in ScreenOS”, которое могло позволить knowledgeable attacker получить administrative access к NetScreen devices и расшифровывать VPN traffic. Juniper — Important Announcement about ScreenOS

Здесь особенно важен класс продукта: security appliance сам является trust anchor.

Все эти случаи разные:

Crypto AG     -> product design / supplier trust
M.E.Doc       -> update channel
CCleaner      -> signed release artifact
SolarWinds    -> build + trusted distribution
XZ            -> release tarball / build-time chain
X_TRADER/3CX  -> cascading supplier + build compromise
ScreenOS      -> unauthorized code in security product

Но общий вопрос один:

Какие доказательства показывают, что shipped product — именно тот продукт, который мы думаем, что проверили?

Threat model для критичного коммерческого продукта

Возьмём условную банковскую платформу / платёжный processing system / electronic trading platform.

У неё есть:

customer PII;
transaction data;
credentials;
API keys;
signing keys;
balances;
order books;
payment instructions;
audit trail;
privileged administrative functions.

Классический AppSec рассматривает внешнего attacker. Но для backdoor assurance threat model должен быть шире.

Potential adversaries

Malicious insider
Compromised developer account
Compromised OSS maintainer
Compromised CI/CD
Compromised artifact repository
Compromised signing infrastructure
Compromised software supplier
State-sponsored actor
Malicious or coerced vendor
Compromised firmware/hardware supplier

И attack surface выглядит уже не так:

Internet -> Application

а так:

Developer
   |
Source repository
   |
Dependencies
   |
Build system
   |
Compiler / toolchain
   |
Artifact repository
   |
Signing service
   |
Update service
   |
Customer environment
   |
Runtime control plane

Product Security должен контролировать всю цепочку, а не только application code.

Два разных assurance-сценария: мы вендор или мы покупатель\юзер?

Здесь часто смешивают две очень разные задачи.

Если продукт разрабатываем мы

У нас потенциально есть доступ к:

source
code review history
CI/CD
compiler/toolchain
build workers
artifact repository
signing service
release metadata
runtime telemetry

Поэтому мы можем строить source-to-artifact evidence chain и достаточно глубоко проверять происхождение релиза.

Если мы покупаем closed-source enterprise software

У нас может быть только:

installer / container / appliance
vendor documentation
SBOM
signature
network traffic
runtime behavior
contractual evidence

В этом случае цель меняется. Мы не можем честно сказать «мы доказали отсутствие backdoor». Зато можем:

проверить provenance и vendor security process;
анализировать финальный binary/package;
запускать продукт в sandbox/lab;
строить network и syscall baseline;
ограничить outbound connectivity;
staged-rollout обновления;
фиксировать hashes и release deltas;
отключить необязательные vendor control-plane connections;
получить договорные права на audit / incident notification / SBOM / vulnerability disclosure;
минимизировать blast radius, если наше доверие ошибочно.

Для Security Director это принципиальное различие:

Producer assurance пытается доказать происхождение. Buyer assurance управляет остаточным доверием.

Именно поэтому я бы не писал спекулятивные фразы вроде «а вдруг в Oracle или Microsoft есть backdoor». Без доказательств это просто предположение.

Правильная постановка гораздо звучит сильнее:

Какой уровень доверия получает любой closed-source database/OS/security product, какие privileged capabilities ему доступны и какие независимые evidence мы можем получить от vendor и из собственного наблюдения?

Эта формулировка одинаково применима к любому поставщику.

Контроль №1: определить, что продукту вообще разрешено уметь

Это, на мой взгляд, один из самых недооценённых controls. Перед тем как искать «плохой код», нужно определить allowed behavior.
Например, для database engine:

MAY:
- listen on configured database ports
- read database files
- perform configured replication
- connect to explicitly configured backup endpoint

MUST NOT:
- spawn arbitrary shell
- connect to arbitrary Internet hosts
- read SSH private keys
- enable hidden administrative users
- download executable code at runtime
- disable audit logging through remote configuration

Это можно назвать:

capability baseline;
security invariants;
negative requirements;
prohibited behavior specification.

Без этого security team часто видит опасную capability, но не может ответить:

«Это bug или feature?»

Для critical product я бы делал Declared Security-Sensitive Capabilities Register.

Пример:

Capability	Expected	Owner	Justification
Outbound Internet	No	Architecture	Product works offline
Child process execution	No	Platform	No operational need
Dynamic library loading	Limited	Core	Plugins only
Remote configuration	Yes	SRE	Signed config only
Debug interface	No in production	Engineering	Dev builds only
Auto-update	Yes	Release	TUF-protected

После этого многие «backdoor-like» возможности становятся формально проверяемыми.

Контроль №2: source-code assurance, ориентированный на capability

Обычные CodeQL/Semgrep rules стоит дополнить custom queries.

Я бы искал:

process creation
shell execution
dynamic code loading
reflection / eval
raw sockets
new outbound HTTP clients
hardcoded IP addresses
hardcoded credentials
hidden feature flags
alternate authentication paths
debug/admin endpoints
audit disabling
runtime code download
filesystem access outside product directories
credential-store access
environment/time/hostname based branches

Например, такое изменение:

+ if config.remote_support:
+     auth.require_admin = False

может не породить классическую vulnerability finding. Но оно должно вызвать security-sensitive behavior review.

*Для критичных модулей я бы также использовал:
*- CODEOWNERS;

mandatory security approval;
two-person review;
signed commits/tags where appropriate;
protected branches;
no direct pushes;
отдельный approval для auth, crypto, update, audit и remote-management code.

NIST IR 8397 включает threat modeling, static analysis, secret detection, black-box testing, structural testing и fuzzing в минимальный набор developer verification techniques. NIST IR 8397

Контроль №3: dependency и release-source integrity

XZ показал, почему недостаточно проверить repository.
Для каждой release dependency полезно знать:

Where did it come from?
Which exact digest?
Which source revision?
Who built it?
Can we reproduce it?
Did the release tarball differ from the repository?

Минимальный baseline:

lockfiles;
digest pinning;
dependency allowlist;
SBOM;
internal package proxy;
provenance where available;
policy against unreviewed new dependencies;
monitoring maintainer/ownership changes для critical OSS.

Для high-risk dependency имеет смысл сравнивать:

upstream Git tag
       vs
published source archive
       vs
compiled package

Контроль №4: harden the build

Если attacker может изменить build environment, clean source уже не спасает.

Я бы стремился к:

ephemeral build workers;
hermetic или максимально изолированным builds;
pinned toolchains;
immutable builder images;
minimal build-time secrets;
short-lived workload identities;
controlled/no outbound network during compilation;
separation build and signing;
immutable artifact repository;
detailed build logs.

Здесь очень полезна SLSA.

В актуальной SLSA 1.2 Build Track описывает уровни от наличия provenance до hardened build platform. Provenance фиксирует, кто, чем, каким процессом и из каких inputs создал artifact. SLSA 1.2 SLSA Provenance

Но важно помнить:

Provenance доказывает происхождение. Оно не доказывает добрые намерения производителя.

Контроль №5: in-toto и attestations

in-toto позволяет описать ожидаемую supply chain и проверить, что каждый шаг был выполнен ожидаемой identity и в ожидаемом порядке.

Условно:

source
  |
compile
  |
test
  |
package
  |
binary scan
  |
sign
  |
publish

Для каждого шага можно получить evidence:

WHO
WHAT COMMAND
INPUT DIGEST
OUTPUT DIGEST
WHEN

Это превращает release из одного файла в artifact + evidence. И это принципиально другой уровень assurance. Едем дальше, копаем тему!

Контроль №6: reproducible builds и independent rebuild

Один из самых сильных ответов на вопрос:

«Соответствует ли бинарник исходникам?»

— reproducible build.

Идея тут проста как 2-ве копейки:

Source revision A
      |
Builder #1
      |
Artifact hash X

Source revision A
      |
Independent Builder #2
      |
Artifact hash X

Если output детерминирован и совпадает bit-for-bit, становится значительно сложнее незаметно внедрить дополнительный код только в production build.

Проект Reproducible Builds определяет воспроизводимую сборку через одинаковые inputs, заданное build environment и идентичный проверяемый output. Reproducible Builds

Для обычного SaaS продукта это может быть слишком дорого для каждого commit.

Для:

HSM software;
financial transaction engine;
database;
VPN;
IAM;
cryptographic library;
trading engine;

я бы рассматривал independent rebuild как вполне оправданный release control. Да, только так!

Контроль №7: анализировать именно shipping binary

Это одна из главных мыслей всей этой статьи.

Source scan и binary scan отвечают на разные вопросы.

Для финального artifact можно проверять:

imported APIs;
system calls;
strings;
hardcoded domains/IPs;
embedded certificates;
embedded private keys;
executable sections;
packed/obfuscated regions;
unexpected interpreters;
bundled scripts;
dynamic loaders;
capabilities/permissions;
new binaries between releases;
suspicious network functionality;
malware indicators.

Commercial platforms, например ReversingLabs Spectra Assure, специально делают complex binary analysis post-build и не требуют исходного кода.

Для manual deep-dive используются:

Ghidra;
IDA;
Binary Ninja;
radare2;
language-specific decompilers.

Для firmware/device security существуют отдельные классы платформ вроде Binarly, Finite State и Eclypsium. Это не означает, что любой из этих продуктов может выдать сертификат:

“Backdoors: 0.”

Такого детектора в общем случае не существует. Но они резко повышают visibility именно в реальный поставляемый artifact.

Контроль №8: behavioral sandboxing

Статика показывает capability. Dynamic analysis показывает:

Что программа реально делает в конкретном environment.

Я бы собирал как минимум:

process tree
syscalls
filesystem access
registry/config changes
DNS
TCP/UDP destinations
TLS destinations
loaded modules
child processes
IPC
credential access
privilege changes
kernel interaction

Но один запуск недостаточен. Нужно менять сам environment:

time / date
timezone
locale
country
hostname
username
machine ID
network range
DNS responses
license state
feature flags
config values
server responses

То есть фактически делать behavioral state-space exploration.

Контроль №9: behavioral diff между релизами

Это крайне практичный control. И важный.

Допустим:

7.4.0 -> approved baseline
7.4.1 -> new release

И вы сравниваете behavior.

+ NEW outbound domain: telemetry-new.example
+ NEW child process: /bin/sh
+ NEW read: ~/.ssh/id_rsa
+ NEW privileged syscall
+ NEW dynamic library

Каждый такой diff не обязательно означает compromise.

Но каждый — хороший кандидат на review. Мне нравится этот подход, потому что он превращает сложную задачу:

«Найдите неизвестный backdoor»

в значительно более реалистичную:

«Объясните новые security-sensitive capabilities этого релиза».

Контроль №10: secure update architecture

Update channel — одно из самых привлекательных мест для supply-chain attacker.

Простая модель:

download
-> verify vendor signature
-> install

лучше, чем ничего, но не идеальна.

Что произойдёт, если signing key скомпрометирован? Именно эту задачу решает The Update Framework (TUF). TUF проектировался так, чтобы update system сохранял устойчивость даже при компрометации repository или части signing keys. Он использует:

разделение signing roles;
threshold signatures;
expiration;
version metadata;
hashes;
key rotation/revocation;
offline root trust.

TUF Overview

TUF Security

Для critical platform я бы также рассматривал:

staged rollout;
canary population;
delayed automatic rollout для high-risk updates;
rollback;
emergency freeze;
independent approval для security-critical changes.

Контроль №11: signing и transparency

Sigstore/Cosign хорошо закрывает authenticity и auditability artifact signing.

Sigstore keyless signing связывает artifact signature с identity, а signing events фиксируются в Rekor transparency log. Sigstore signing overview Rekor

Но снова:

valid signature != safe software.

Поэтому signing должен быть последним этапом после assurance gates, а не заменой assurance.

Контроль №12: runtime containment — предположить, что backdoor всё-таки прошёл

Security engineering становится зрелым, когда допускает failure предыдущих controls. Если приложение не должно ходить в произвольный Internet: не разрешайте ему это делать.

Например:

Default outbound: DENY

ALLOW:
api.company.example:443
updates.company.example:443

Everything else: DENY + ALERT

Для server-side продукта:

Kubernetes NetworkPolicy;
Cilium/Calico policies;
service mesh egress;
host firewall;
proxy allowlist.

Для процесса:

non-root;
Linux capabilities drop;
seccomp;
AppArmor/SELinux;
read-only filesystem;
isolated service accounts;
no access to cloud metadata unless needed.

Если потенциальный implant не имеет:

arbitrary outbound network
filesystem access
credential access
shell execution
privileged identity

его полезность для attacker резко снижается.

Containment иногда важнее detection.

Как это может выглядеть в CI/CD

Я бы строил отдельный release lane примерно так:

┌──────────────────────────────┐
│  SOURCE POLICY               │
│  reviews / CODEOWNERS        │
│  CodeQL / Semgrep            │
│  security capability rules   │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│  DEPENDENCY ASSURANCE        │
│  SCA / SBOM / digest pinning │
│  package policy              │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│  HERMETIC BUILD              │
│  ephemeral runner            │
│  pinned toolchain            │
│  restricted network          │
└──────────────┬───────────────┘
               │
         SLSA provenance
               │
┌──────────────▼───────────────┐
│  INDEPENDENT REBUILD         │
│  compare output digests      │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│  BINARY ASSURANCE            │
│  malware / capability scan   │
│  binary diff                 │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│  SANDBOX                     │
│  syscall/network behavior    │
│  behavioral diff             │
└──────────────┬───────────────┘
               │
        sign + attest
               │
┌──────────────▼───────────────┐
│  RELEASE                     │
│  policy verification         │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│  RUNTIME                     │
│  least privilege / egress    │
│  telemetry / integrity       │
└──────────────────────────────┘

Conceptual pipeline:

release-assurance:
  - verify_security_review
  - run_custom_sast_capability_rules
  - generate_sbom
  - verify_dependency_policy

  - build_in_ephemeral_isolated_runner
  - generate_slsa_provenance

  - rebuild_in_independent_environment
  - compare_release_digests

  - scan_final_binary
  - compare_binary_capabilities_with_previous_release

  - run_behavioral_sandbox
  - compare_network_and_syscall_baseline

  - sign_artifact
  - publish_attestations

  - release_only_if_all_gates_pass

Это не конкретный vendor syntax. Это security architecture pipeline.

Release Evidence Bundle: что я хотел бы получать на каждый critical release

Для high-assurance продукта security gate должен выдавать не просто зелёную галочку, а evidence bundle, который можно проверить позже.

Например:

release-evidence/
  source-commit.txt
  dependency-lockfiles/
  sbom.cdx.json
  build-provenance.intoto.jsonl
  build-environment.json
  artifact.sha256
  signature.bundle
  binary-analysis-report.json
  capability-diff.json
  sandbox-network-diff.json
  syscall-diff.json
  security-approvals.json
  update-metadata/

Тогда release decision можно формулировать как policy:

ALLOW RELEASE only if:
  reviewed_source == provenance.source
  AND independent_build_digest == release_digest
  AND no_unapproved_new_capabilities
  AND no_new_unapproved_egress
  AND signature_identity == expected_release_identity
  AND security_approvals >= required_threshold

Это не гарантирует отсутствие malicious functionality. Но оно резко увеличивает количество независимых следов, которые attacker должен одновременно подделать.

OWASP Software Component Verification Standard (SCVS) полезен именно как практический supply-chain assurance checklist: он отдельно покрывает Inventory, SBOM, Build Environment, Package Management, Component Analysis и Pedigree/Provenance. Для higher-assurance levels SCVS требует в том числе verifiable origin и auditable chain of custody для source и binary components. OWASP SCVS

Какие patterns я бы автоматически флагал

Ниже не «backdoor signatures», а security-sensitive patterns, требующие объяснения.

NEW process execution
NEW shell invocation
NEW outbound destination
NEW hardcoded IP/domain
NEW dynamic loader
NEW remote config key
NEW authentication branch
NEW debug/admin API
NEW crypto key embedded in binary
NEW credential-store access
NEW file access outside expected directories
NEW telemetry payload field
NEW capability/permission
NEW unsigned plugin/module path

Ключевое слово здесь — NEW. Для зрелого продукта baseline + diff часто полезнее, чем попытка написать универсальное правило «найти backdoor».

Что реально можно автоматизировать, а что останется экспертной работой

Рынок любит обещание: upload binary → get backdoor verdict.

На практике automated tooling хорошо помогает в пяти слоях:

Source capability detection — CodeQL, Semgrep и custom rules для security-sensitive APIs и data flows.
Component/provenance analysis — SCA, SBOM, package origin, signatures, attestations.
Binary/package analysis — recursive unpacking, imports/exports, embedded files, certificates, strings, suspicious sections, malware signatures, YARA, binary diff.
Dynamic behavior — process tree, syscalls, filesystem, registry, DNS, TCP/UDP, TLS destinations, IPC, loaded modules.
Release diff — что появилось в версии N относительно N-1.

Но автоматизация плохо отвечает на вопрос:

“Зачем эта capability существует?”

Именно здесь нужен человек, знающий architecture и expected behavior. Например, следующий code path может быть полностью легитимным для remote-support agent и совершенно недопустимым для offline database engine:

payload = http.get(config.control_plane + "/task")
if verify_signature(payload):
    subprocess.run(payload.command, shell=False)

Scanner может увидеть network + process execution. Но только architecture/security review может решить, должна ли система обладать такой power вообще.

Поэтому я бы не создавал отдельную команду “backdoor hunters”, которая работает в отрыве от product engineering. Я бы соединял:

Product Security
+ Architecture
+ Build/Release Engineering
+ Detection Engineering
+ Reverse Engineering
+ Supplier Security
+ Platform/SRE

Для сложных native binaries и firmware понадобятся reverse-engineering инструменты и специалисты; для Java/.NET проще использовать decompilation и semantic diff; для containers полезно сравнивать filesystem layers, entrypoints, capabilities и network behavior.

Коммерческие платформы класса software binary analysis могут автоматизировать часть post-build контроля. Но я бы всегда рассматривал их как источник evidence, а не как oracle, который способен доказать отсутствие закладки.

Vendor due diligence: что спрашивать у поставщика

Проблема становится особенно интересной, когда source code принадлежит не вам. NIST в 2026 году выпустил SP 1326 — C-SCRM Due Diligence Assessment Quick-Start Guide. Он рассматривает due diligence поставщика через provenance, resilience, foundational cyber practices, supply-chain tiers и FOCI. NIST SP 1326

Для critical software supplier я бы спрашивал ЭТО:

Development

Есть ли documented secure SDLC?
Кто может merge security-critical code?
Используется ли two-person approval?
Как защищены source repositories?
Как контролируются dependencies?

Build

Build workers ephemeral?
Build network isolated?
Toolchain pinned?
Есть SLSA provenance?
Возможен reproducible build?
Разделены build и signing?

Release

Каждый artifact подписан?
Есть transparency/attestation?
Финальный binary сканируется независимо от source?
Есть binary diff между releases?

Update

Как защищается update metadata?
Что произойдёт при компрометации signing key?
Есть threshold signing?
Есть rollback protection?
Есть staged rollout?

Runtime

Какие outbound connections делает product?
Какие endpoints обязательны?
Может ли vendor remote-disable product?
Есть ли remote support function?
Есть ли undocumented telemetry?
Какие данные покидают customer environment?

И один из моих любимых вопросов:

Can the product continue operating securely if the vendor's cloud control plane is unavailable or hostile?

Для банковской или инфраструктурной системы это очень хороший архитектурный тест.

Hardware и firmware: от холодной войны к современному trust chain

Разговор о software backdoors легко создаёт ощущение, что проблема родилась вместе с SolarWinds. На самом деле trust problem значительно старше.

Crypto AG хорошо показывает supplier-level manipulation на уровне security product. В hardware security существует параллельный класс угроз — hardware Trojans / malicious circuit modifications. DARPA в программе TRUST прямо исходила из сценария, где IC может быть designed or fabricated under untrusted conditions, и пыталась строить измеримые способы обнаружения модификаций. DARPA — TRUST

В современном enterprise stack граница между hardware и software размыта:

application
OS / hypervisor
bootloader
UEFI
BMC / management controller
NIC / storage firmware
microcode
silicon

Компрометация любого нижнего слоя может пережить reinstall верхнего.

NIST SP 800-193 поэтому строит firmware resiliency вокруг трёх функций:

Protection → Detection → Recovery.

NIST SP 800-193

Для high-assurance environment я бы постепенно добавлял:

secure boot;
measured boot;
TPM-backed attestation;
signed firmware updates;
firmware inventory and version pinning;
BMC isolation;
hardware root of trust;
independent firmware analysis там, где risk оправдывает стоимость.

И здесь важно не перейти в театр безопасности. Даже серьёзная hardware assurance программа не даёт философской гарантии «ничего скрытого нет». Она увеличивает cost of subversion и количество независимых способов её обнаружить.

Российская школа НДВ: термин старый, инструментарий неожиданно современный

Для русской версии эту часть было бы странно обходить. Сам термин «недекларированные возможности» в российской нормативной школе формализован намного раньше современного бума software supply-chain security.

Исторический Руководящий документ Гостехкомиссии 1999 года №114 назывался буквально:

«Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей».

Он определял НДВ как функциональные возможности ПО, не описанные или не соответствующие документации, использование которых способно нарушить confidentiality, integrity или availability. Гостехкомиссия, РД 1999 №114

Важно не выдавать этот документ за текущую универсальную норму для любого российского коммерческого ПО: область применения и сертификационный режим менялись, а прежний РД перестал использоваться как основа соответствующих сертификационных работ после реформы 2020 года. Но как историческая formalization проблемы он очень показателен.

Гораздо интереснее текущая картина.

ФСТЭК: новая Методика 2026 года

12 мая 2026 года ФСТЭК России утвердила новую «Методику выявления уязвимостей и недекларированных возможностей в программном обеспечении»; для решений по сертификации СЗИ, выданных после 1 августа 2026 года, должна применяться эта Методика. Информационное сообщение о Методике

Это не документ «для каждого сайта и SaaS». Его scope — исследования ПО средств защиты информации в рамках уровней доверия. Но набор техник очень интересен Product Security инженеру, потому что выглядит совсем не музейно.

В опубликованной выписке фигурируют:

анализ архитектуры;
static methods;
dynamic methods;
static analysis исходного кода;
module testing со сбором покрытия;
fuzzing attack-surface interfaces со сбором coverage;
экспертиза source и restored/decompiled code;
исследование code, который не был задействован dynamic analysis из-за anti-analysis механизмов;
анализ сторонних компонентов;
результаты composition/configuration analysis;
build environment и build system;
сам distribution artifact.

ФСТЭК 2026 — выписка, общие требования · Fuzzing requirements · Code expertise

Мне особенно нравится, что Методика рассматривает не только уязвимости и НДВ, но и «потенциально опасные декларированные возможности» — например, избыточные external interfaces или functions. Это очень близко к тому, что выше я называл capability baseline / negative requirements.

Ещё одна важная деталь: ФСТЭК связывает исследования с процессами безопасной разработки по ГОСТ Р 56939-2024, который действует с 20 декабря 2024 года и заменил ГОСТ Р 56939-2016. Росстандарт — ГОСТ Р 56939-2024

То есть современная российская модель уже тоже фактически соединяет:

secure development
+ architecture analysis
+ SCA/composition
+ static analysis
+ fuzzing
+ manual code expertise
+ build environment
+ distribution artifact

Это тот же conceptual shift, который в международной терминологии распределён между SSDF, C-SCRM, SLSA, provenance и product assurance.

А где ФСБ?

Здесь важно не смешивать регуляторов.

Традиционно ФСТЭК отвечает за большой пласт technical information protection и certification of non-cryptographic security controls, а криптографические средства и отдельные требования вокруг электронной подписи/СКЗИ относятся к компетенции ФСБ.

Хороший конкретный пример — Приказ ФСБ России №796 о требованиях к средствам электронной подписи и удостоверяющего центра. Для определённых классов средств УЦ там прямо требовалась проверка исходных текстов системного и прикладного ПО на отсутствие недекларированных возможностей, а для более высокого класса — формальная верификация соответствующих свойств. У текущей редакции этого приказа срок действия ограничен 1 января 2027 года, поэтому его корректно приводить именно как действующий на момент написания статьи специализированный пример, а не как универсальную норму. Приказ ФСБ №796

Почему этот российский экскурс полезен глобальному Product Security

Не потому, что международной компании нужно копировать российскую сертификацию. А потому что старая формулировка «отсутствие недекларированных возможностей» очень хорошо заставляет посмотреть на продукт иначе:

Vulnerability testing спрашивает, можно ли заставить программу сделать опасное действие. NDV assurance спрашивает, не умеет ли она уже делать опасное действие по замыслу или скрытому условию.

Современный Software Integrity program в коммерческой компании по сути соединяет обе модели.

Международные стандарты и frameworks, которые я бы использовал

NIST SSDF — SP 800-218

Базовый secure software development framework. Он не является «backdoor detection standard», но даёт фундамент для защищённой разработки и release process.

На момент написания final остаётся SSDF 1.1; NIST опубликовал draft SSDF 1.2 в декабре 2025 года.

NIST SSDF

NIST SP 800-218

NIST IR 8397

Minimum Standards for Developer Verification of Software.

Полезен как verification baseline:

threat modeling;
automated testing;
static analysis;
secret scanning;
black-box testing;
structural testing;
fuzzing;
dependency analysis.

NIST IR 8397

NIST SP 800-161 Rev. 1

Один из наиболее прямых документов для C-SCRM. Особенно важна его постановка риска malicious functionality.

NIST SP 800-161 Rev. 1

NIST SP 1326

Очень свежий документ — final опубликован в июле 2026 года. Это уже practical supplier due-diligence layer.

NIST SP 1326

SLSA 1.2

Framework для build provenance и supply-chain integrity.

SLSA 1.2

OWASP SCVS

OWASP Software Component Verification Standard — очень практичный complement к NIST/SLSA. Его шесть control families покрывают Inventory, SBOM, Build Environment, Package Management, Component Analysis и Pedigree/Provenance. OWASP SCVS

Для этой статьи особенно интересны требования к repeatable build, защите build pipeline и verifiable origin / chain of custody компонентов.

in-toto

Attestation framework для доказательства того, что software supply-chain steps выполнены ожидаемым образом.

in-toto

Sigstore

Artifact signing + identity + transparency.

Sigstore

TUF

Защита software update systems, в том числе от key compromise.

TUF

Common Criteria — ISO/IEC 15408

Common Criteria исторически ближе к миру assurance, чем типичный AppSec framework.

В 2026 году опубликованы новые редакции серии ISO/IEC 15408. Part 3 определяет security assurance components, а vulnerability assessment включает independent vulnerability analysis и penetration testing на соответствующих уровнях.

ISO/IEC 15408-1:2026

ISO/IEC 15408-3:2026

Common Criteria Part 3

Европейский контекст: Cyber Resilience Act

EU Cyber Resilience Act не является стандартом поиска backdoors. Но направление очень показательное.

CRA вводит horizontal cybersecurity requirements для products with digital elements, включая:

cybersecurity risk assessment;
vulnerability handling;
security testing/review;
SBOM;
secure update distribution;
support obligations.

Regulation (EU) 2024/2847

На момент публикации этой статьи есть интересный временной нюанс:

основная масса CRA применяется с 11 December 2027;
reporting obligations Article 14 уже применяются с 11 September 2026;
положения о conformity-assessment bodies начали применяться с 11 June 2026.

Это хорошо показывает общий тренд:

Product security постепенно становится не только engineering practice, но и доказуемым свойством продукта и его lifecycle.

Почему невозможно «доказать отсутствие backdoor» одной платформой

Здесь важно не продавать security theatre.

Универсальный scanner:

Backdoors found: 0

не даёт математической гарантии отсутствия скрытого поведения.

Причины:

Trigger может быть чрезвычайно редким.
Behavior может зависеть от external service.
Payload может загружаться позже.
Code может быть obfuscated.
Capability может выглядеть легитимной.
Vendor сам может быть adversary.
Build toolchain может быть скомпрометирован.
Hardware/firmware может находиться вне scope анализа.

Поэтому правильная стратегия — defense in depth:

prevent
   +
detect
   +
verify
   +
constrain
   +
monitor

Практическая maturity model

Я бы оценивал capability примерно так. Ценим логику ниже.

Level 0 — Vulnerability Security

SAST
DAST
SCA

Компания в основном ищет случайные ошибки.

Level 1 — Release Integrity

SBOM
artifact signing
protected release pipeline

Level 2 — Build Assurance

SLSA provenance
ephemeral builders
attestations

Level 3 — Artifact Assurance

post-build binary scanning
binary diff
capability analysis

Level 4 — Behavioral Assurance

sandbox
behavioral diff
egress baseline
environment variation

Level 5 — High Assurance

reproducible builds
independent rebuild
independent binary review
runtime attestation
strict containment
supplier evidence

Не каждый продукт должен быть Level 5.

Но risk tier продукта должен определять depth of assurance.

Метрики, которые действительно имеют смысл

Я бы не измерял программу количеством binary scans.

Лучше:

% critical releases with verified provenance

% critical releases independently reproduced

% production artifacts scanned post-build

% security-sensitive capability changes reviewed

number of new outbound destinations per release

% workloads with default-deny egress

% release artifacts with verified signatures/attestations

% critical suppliers providing SBOM + provenance evidence

mean time to investigate behavioral diff

number of undocumented privileged interfaces discovered

Эти metrics уже показывают реальную maturity.

Где здесь роль Security Director

Security Director должен определить:

Какие продукты действительно требуют такого assurance level.
Какие capabilities считаются запрещёнными или security-sensitive.
Какие evidence обязательны для release.
Какие suppliers считаются high risk.
Какие controls являются release blockers.
Как ограничивается impact, если prevention не сработал.

И главное — перевести абстрактный страх:

«А вдруг в продукте есть закладка?»

в проверяемые инженерные вопросы:

Можно ли отследить источник этого бинарного файла?
Можно ли воспроизвести его в другой среде?
Что изменилось в его возможностях\поведении?
Какое новое сетевое поведение появилось?
Кто санкционировал изменение?
Может ли продукт\ПО осуществлять утечку данных?
Может ли поставщик удаленно отключить его?
Может ли приложение работать без произвольного доступа к Интернету?
Можно ли обнаружить изменения после развертывания?

Если на эти вопросы есть хорошие ответы, разговор о backdoors перестаёт быть конспирологией и становится обычной инженерией доверия.

Выводы

Product Security долгое время концентрировался на vulnerabilities. Это логично: SQL injection, memory corruption и broken access control встречаются значительно чаще, чем специально внедрённые backdoors.

Но по мере того как software supply chains становятся длиннее, продукты сложнее, а критичные системы всё сильнее зависят от внешних vendors, вопрос software integrity становится самостоятельной security discipline.

Не существует одного инструмента, который докажет отсутствие недекларированных возможностей. Такова рельсность.

Но можно построить архитектуру, в которой скрытую функцию:

сложно внедрить;
сложно протащить через build;
сложно спрятать в binary;
сложно активировать незаметно;
сложно использовать для exfiltration;
и значительно легче обнаружить.

Именно это, на мой взгляд, и есть современный Software Integrity & Malicious Functionality Assurance.

Что почитать и посмотреть дальше

Если хочется углубиться не только в standards, а именно в логику доверия и реальные investigations, я бы начал отсюда.

Papers / primary material

Ken Thompson — Reflections on Trusting Trust — фундаментальный thought experiment про compiler-level subversion. https://doi.org/10.1145/358198.358210
David A. Wheeler — Diverse Double-Compiling — практическая защита от класса “trusting trust” при определённых assumptions. https://dwheeler.com/trusting-trust/
Andres Freund — original XZ disclosure — великолепный пример расследования, начавшегося с runtime anomalies. https://www.openwall.com/lists/oss-security/2024/03/29/4
Mandiant — 3CX / X_TRADER — cascading software supply-chain compromise. https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise
Cisco Talos — CCleaner — почему legitimate server + valid signature недостаточны. https://blog.talosintelligence.com/avast-distributes-malware/

Standards / guidance

NIST SP 800-161 Rev. 1 — C-SCRM
NIST SP 800-218 — SSDF
OWASP SCVS
SLSA 1.2
in-toto
Sigstore
TUF
Common Criteria / ISO/IEC 15408

И я бы обязательно читал original incident disclosures, а не только пересказы. Именно там обычно находятся детали, которые превращают заезженный термин “supply chain attack” в конкретный engineering control.

References

NIST SP 800-161 Rev. 1 — Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final
NIST SP 1326 — C-SCRM Due Diligence Assessment Quick-Start Guide, July 2026 https://csrc.nist.gov/pubs/sp/1326/final
NIST SP 800-218 — Secure Software Development Framework https://csrc.nist.gov/pubs/sp/800/218/final
NIST IR 8397 — Guidelines on Minimum Standards for Developer Verification of Software https://csrc.nist.gov/pubs/ir/8397/final
NIST SP 800-193 — Platform Firmware Resiliency Guidelines https://csrc.nist.gov/pubs/sp/800/193/final
MITRE ATT&CK T1195 — Supply Chain Compromise https://attack.mitre.org/techniques/T1195/
MITRE CWE-506 — Embedded Malicious Code https://cwe.mitre.org/data/definitions/506.html
MITRE CWE-510 — Trapdoor https://cwe.mitre.org/data/definitions/510.html
SLSA Specification v1.2 https://slsa.dev/spec/v1.2/
in-toto https://in-toto.io/docs/getting-started/
Sigstore / Cosign https://docs.sigstore.dev/cosign/signing/overview/
Rekor Transparency Log https://docs.sigstore.dev/logging/overview/
The Update Framework https://theupdateframework.io/docs/overview/
Reproducible Builds https://reproducible-builds.org/docs/formal-definition/
CISA — Active Exploitation of SolarWinds Software https://www.cisa.gov/news-events/alerts/2020/12/13/active-exploitation-solarwinds-software
SolarWinds SEC filing — SUNBURST investigation update https://www.sec.gov/Archives/edgar/data/1739942/000173994221000080/swi-20210331.htm
Red Hat — CVE-2024-3094 / XZ Utils https://access.redhat.com/security/cve/cve-2024-3094
Juniper — Important Announcement about ScreenOS https://community.juniper.net/browse/blogs/blogviewer?BlogKey=e0a62f51-c793-4e7e-98e8-c5ac081f2c18
ISO/IEC 15408 series / Common Criteria https://www.iso.org/standard/15408-1 https://www.iso.org/standard/15408-3 https://www.commoncriteriaportal.org/
EU Cyber Resilience Act — Regulation (EU) 2024/2847 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
ReversingLabs Spectra Assure https://www.reversinglabs.com/products/spectra-assure
Crypto AG investigation — The Washington Post https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/
Ken Thompson — Reflections on Trusting Trust https://doi.org/10.1145/358198.358210
DARPA — TRUST in Integrated Circuits https://www.darpa.mil/research/programs/trusted-integrated-circuits
Microsoft MSRC — Petya / M.E.Doc update service https://www.microsoft.com/en-us/msrc/blog/2017/06/update-on-petya-malware-attacks
Cisco Talos — CCleaner supply-chain compromise https://blog.talosintelligence.com/avast-distributes-malware/
Andres Freund — original XZ backdoor disclosure https://www.openwall.com/lists/oss-security/2024/03/29/4
Mandiant — 3CX compromise initiated by X_TRADER compromise https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise
OWASP Software Component Verification Standard https://scvs.owasp.org/
ГОСТ Р 56939-2024 — Росстандарт https://protect.gost.ru/gost/details/f3818925-a96f-4f55-96e9-46b44720ee64
ФСТЭК России — Методика выявления уязвимостей и недекларированных возможностей, 12.05.2026 (выписка) https://service.securitm.ru/docs/metodika-vyiavleniia-uiazvimostei-i-nedeklarirovannyx-vozmoznostei-v-programmnom-obespecenii-vypiska
Гостехкомиссия России — РД 1999 №114 https://base.garant.ru/197898/
Приказ ФСБ России №796 — требования к средствам электронной подписи и УЦ https://www.consultant.ru/document/cons_doc_LAW_126209/

Парсим ОУД4: что Банк России на самом деле хочет от вашего кода, сборки и Secure SDLC для софтверных компаний ФинТеха

Ivan's Cybersecurity Notes — Mon, 19 Oct 2026 03:00:00 +0000

КОПИЯ СТАТЬЯ (ПЕРЕНОС С ДРУГОГО ХОСТИНГА) ОТ 19 Марта 2026

TL;DR

ОУД4 — это момент, когда Банк России приходит не к CISO с презентацией, а к инженерам в Git, CI/CD, backlog и release process. Здесь уже не работает схема “у нас есть сканер, secure coding guide и добрый AppSec”.

Нужно доказать, что продукт разрабатывается, собирается, тестируется и обновляется в управляемом Secure SDLC, а не в режиме “три сильных инженера и один шаман всё держат на честном слове”.

Disclaimer

Этот материал — практическая авторская инженерная интерпретация требований Банка России к прикладному ПО финансовых организаций. Это не официальный комментарий Банка России, не юридическое заключение и не замена формальной оценки соответствия. Но как рабочая карта для команды разработки, AppSec, DevOps, QA и архитекторов — вполне годится: чтобы не читать профиль защиты как древний манускрипт, а переложить его на язык реальных процессов, артефактов и pipeline.

Профиль защиты версии 4.0 прямо разработан Банком России для разработчиков, заявителей, органов по сертификации, испытательных лабораторий и организаций, которые проводят оценку соответствия.

Ну, что заглянем документу под капот, раскидаем шелуху, скинем лишний формализм чиновников и четенько двинемся к плану действий!

Котаны, Let's Go!

Intro

Если вы (ну, ваша компания, а ты там как Sec спец) делаете коробочную АБС, ДБО-компонент, API-контур, интернет-модуль или другой банковский софт, то ОУД4 — это уже не история из серии “безопасники что-то там согласуют”. Это точка, где регуляторный язык приходит в SDLC и начинает задавать очень конкретные инженерные вопросы:

кто меняет код,
как зафиксирован baseline релиза,
чем подтверждается целостность исходников,
как защищена build-среда,
какие именно SAST/DAST/фаззинг-проверки запускались,
что происходит с уязвимостями,
как выпускаются патчи,
как живёт supply chain.

и т.д.

В профиль Банка России 4.0 это зашито не намёками, а прямыми компонентами доверия. Короче, без лишней шелухи ОУД4 — это не “бумажка для аудита”, хотя доя нормативке РФ так раньше в основном и было. Это момент, когда разработка должна стать доказуемой (ну, и в конечном счете конечно сам продукт\сервис должен быть безопаснее, ведь вы не хотите что бы ваши лавехи на счете в банке подрезал какой-нибудь хЭкер:).

1. Общее представление о документе ЦБ РФ и почему он бьет именно по AppSeс\DevSecOps инженерам, а не по CISO

Базовый документ здесь - профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций, версия 4.0. В справке профиля прямо указаны наименование, тип ПО, версия профиля и идентификация объекта оценки. Там же зафиксировано, что профиль соответствует пакету требований доверия ОУД4, усиленному и расширенному целым набором дополнительных компонентов.

«Настоящий ПЗ соответствует пакету требований доверия: оценочный уровень доверия 4 (ОУД4)…»

Отдельно важно, что профиль 4.0 уже завязан на актуальную нормативную рамку Банка России. Положение Банка России № 851-П от 30.01.2025 устанавливает обязательные требования к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия переводам денежных средств без согласия клиента и применяется к информации, обрабатываемой в автоматизированных системах, используемых для таких операций. Этим же положением 683-П признано утратившим силу.

Если перевести это на инженерный язык, регулятор ждёт ответа на семь скучных, но очень конкретных вопросов:

что именно вы оцениваете;
какой именно релиз показываете;
как устроена архитектура безопасности;
кто и как меняет код;
где и как собирается релиз;
какие проверки реально выполнялись;
как живут уязвимости, патчи и обновления.

Форма у документа нормативная, но по сути это очень инженерный документ: он проверяет не лозунги, а состояние SDLC и качество evidence.

2. Мэтчим ОУД4 с Secure SDLC и best practices

Если смотреть на международные best practices, совпадение очень плотное. NIST SSDF рекомендует встраивать secure software development practices в SDLC, чтобы снижать количество уязвимостей, уменьшать последствия невыявленных проблем и устранять их корневые причины. OWASP SAMM описывает зрелостную модель, которая помогает формировать и улучшать программу безопасности разработки под реальные риски организации.

2.1. Что общего

1. Security by design, а не финальный “добивочный пентест”

И SSDF, и SAMM, и профиль Банка России исходят из одной и той же идеи: безопасность должна жить в жизненном цикле, а не только в последней неделе перед аудитом.

2. Threat modeling и attack surface

В профиле есть отдельный компонент ALC_DVS_EXT.1 про моделирование угроз и описание поверхности атаки. Это очень хорошо ложится на нормальный Secure SDLC: сначала понимаем, где границы доверия и как атакуют систему, потом уже обсуждаем инструменты.

3. Secure coding + secure testing

Статический анализ, динамический анализ, нефункциональные проверки, фаззинг, контроль результатов — всё это звучит как обычный зрелый AppSec-процесс. Только у Банка России это должно быть не “в теории есть”, а оформлено и предъявляемо.

4. Vulnerability management

NIST SSDF говорит про снижение числа уязвимостей и устранение первопричин, а профиль Банка России требует процедур получения сообщений о недостатках, их исправления и выпуска процедур по исправлению для пользователей.

2.2. В чем специфика именно Банка России

Вот тут и начинается уже не “просто хороший Secure SDLC”, а именно регуляторная инженерия.

Особенность №1. Формальный объект оценки

В обычной зрелой разработке можно обсуждать программу безопасности в целом. В ОУД4 надо очень жёстко зафиксировать объект оценки: какой именно продукт, какой релиз, какие модули, какие границы, что входит, что не входит. Без этого весь дальнейший разговор теряет смысл.

Особенность №2. Не просто процессы, а доказательная документация

Тут уже мало сказать “у нас всё настроено”. Нужны схемы, регламенты, описания ролей, параметры инструментов, контрольные суммы, журналы, материалы анализа, связка с релизом и объектом оценки. Короче докажи что все ОК, при том спрос не только за "бумагу", а еще и что по факту вшито в CD\CI конвейер

Особенность №3. Build и supply chain становятся частью оценки доверия

У многих команд Secure SDLC заканчивается на code review + SAST + DAST. так по сути было еще несколько лет назад, а в некоторых компаниях и сейчас:):)

У Банка России отдельно появляются безопасность сборочной среды, контроль ролей в build-контуре, журналы аудита сборки, выделенное хранилище результатов и анализ влияния сторонних поставщиков и внешних компонентов. Вообщем здравый подход! Наконец-то чо-то путное от мегарегулятора, а не "палки в колеса".

Особенность №4. Обновления — это уже предмет оценки, а не бытовая эксплуатация

Профиль требует процедуры получения обновления, проверки целостности, тестирования, установки, контроля установки и верификации применения, а также материалы анализа влияния обновления на безопасность.

Особенность №5. ОУД4 здесь реально усилен и расширен

Профиль прямо перечисляет, что к базовому ОУД4 добавлены компоненты, среди которых ADV_IMP.2, ALC_FLR.2, ACO_VUL.2, ADV_IMP_EXT.3, ADV_TDS_EXT.3, AGD_OPE_EXT.1, ALC_DEL_EXT.1, ALC_DVS_EXT.1, ALC_DVS_EXT.2, ALC_DVS_EXT.3 и другие. То есть это не “обычный ОУД4”, а ОУД4, натянутый именно на прикладное ПО финансового сектора и на безопасную разработку как практику.

ОУД4 очень неплохо мэтчится с Secure SDLC / DevSecOps / SSDF / SAMM, но Банк России добавляет три жёсткие вещи: формальный scope, доказательную документацию и проверяемость каждого инженерного шага.

3. Ошибка тащить на ОУД4 “всю АБС вообще”

Самый частый инженерный фейл выглядит так:

“У нас есть большая коробочная АБС. Ну значит, и показывать будем всю систему”.

Нет. Так делать не надо. Мы же адекватные люди.

Профиль требует идентифицируемый объект оценки, а это автоматически означает, что чем шире scope, тем сложнее:

зафиксировать baseline;
показать полное представление реализации;
удержать traceability;
доказать покрытие тестами;
держать актуальным evidence;
пережить клиентские кастомизации без развала всей доказательной модели.

Правильная стратегия почти всегда такая:

выбрать один контур;
зафиксировать один релиз / одну ветку / один tag;
определить один набор модулей;
собирать evidence только под него.

Обычно хорошими кандидатами на объект оценки становятся:

интернет-контур;
API-шлюз;
модуль аутентификации и управления сессиями;
модуль электронных документов;
отдельный критичный платёжный компонент.

Вообщем, котаны, как видим, ОУД4 любит узкий, замороженный и доказуемый scope. Всё остальное быстро превращается в проект “а это тоже входит?”.

4. Транслируем нормативку ЦБ РФ в инженерный язык

4.1. Исходники должны быть не просто написаны, а прослеживаемы

В профиле прямо сказано, что соответствие ОУД4 усилено компонентом ADV_IMP.2 “Полное отображение представления реализации ФБО”, а также расширенным компонентом ADV_IMP_EXT.3 “Реализация ОО”.

На инженерском языке это означает:

baseline релиза зафиксирован;
есть tag, commit set, release branch;
есть перечень модулей внутри контура оценки;
есть описание реализации и её состав;
есть трассировка “требование → функция → модуль → тест → результат”.

Иначе говоря, исходники для ОУД4 — это не “репозиторий где-то в GitLab”. Это конкретная и идентифицированная реализация конкретного объекта оценки.

Если вы не можете однозначно ответить, какой именно commit и какой именно набор модулей вы показываете, то дальше обсуждать безопасность рановато.

4.2. Доступ к коду и его целостность — отдельный предмет оценки

Профиль отдельно вводит ALC_DVS_EXT.3: управление доступом и контроль целостности кода при разработке. В описании этого компонента прямо сказано, что модель управления доступом к исходному коду должна включать перечень сотрудников, их права и обязанности, а также описание выбранной модели управления доступом и используемых инструментов.

На практике это означает:

protected branches;
понятные правила merge/push/release;
review policy;
audit trail;
backup и контроль целостности репозитория;
регламент ролей и прав, а не просто “ну у нас и так все знают”.

То есть ОУД4 не устраивает ответ “GitLab у нас настроен нормально”. Нужны роль, правило, след, evidence.

4.3. Build-среда — это уже не DevOps-внутрянка, а зона доверия

Один из самых показательных компонентов — ALC_DVS_EXT.2 про обеспечение безопасности сборочной среды. Там прямо сказано, что информация о безопасности сборочной среды должна содержать описание ожидаемых результатов сборки, прав доступа к build-среде и хранилищу результатов сборки, а схематическое изображение сборочной среды должно показывать серверы, узлы, виртуальные узлы, контейнеризацию, связи между ними и компоненты, реализующие меры безопасности.

Журналы аудита процессов сборки должны включать дату и время, версию ПО, конфигурацию сборки, шаги сборки и события безопасности. Для подтверждения хранения результатов сборки могут использоваться журналы с местом сохранения модуля и результатами контрольного суммирования.

Если убрать канцелярит, то нужны:

build map;
роли и доступы в CI/CD;
журналируемость сборки;
артефактное хранилище;
hash/checksum/signature;
понятный путь от commit до release artifact;
желательно repeatable build.

Таким образом, если релиз нельзя проследить от исходника до артефакта, то доверие к нему рушится ещё до разговора про SAST. Опа))) красиво, красиво! Мои аплодисменты ЦБ РФ!

**_CI/CD сам по себе ещё не Secure SDLC_**

4.4. SAST / DAST / fuzzing — не “у нас есть сканер”, а “есть процедура”

Профиль вводит ALC_TAT_EXT.1 для статического анализа и ALC_TAT_EXT.2 для динамического анализа кода программы. Для статического анализа прямо указано, что перечень инструментов должен включать названия инструментов, их версии и соответствие используемым языкам программирования, а отчёты должны содержать срабатывания, результаты разметки, предупреждения, описание ошибок, их тип и место в исходном коде.

Это означает, что нужен не просто “сканер в пайплайне”, а как минимум:

регламент SAST;
перечень и версии инструментов;
правила/параметры конфигурации;
правила повторного запуска;
актуальные отчёты именно по нужному релизу;
разметка findings;
связь результатов с языками и модулями.

То же относится к DAST и фаззингу: инструмент — это только часть истории. Для ОУД4 важна воспроизводимая инженерная процедура.

Типовой SonarQube, любая SAST-платформа или DAST-сканер сами по себе ОУД4 не закрывают. Закрывает процесс, внутри которого они живут. Так что, котаны, нам здесь есть работы, кроме нас ее никто грамотно не сделает:)

4.5. Уязвимости должны жить в системе, а не в переписке

В компоненте ALC_FLR.2 профиль требует, чтобы процедуры устранения недостатков описывали средства получения сообщений от пользователей, а процедуры обработки известных недостатков обеспечивали исправление недостатков и выпуск процедур по исправлению для пользователей. Отдельно сказано, что исправления не должны приводить к появлению новых недостатков.

На инженерском языке это читается так:

есть единый vulnerability register;
есть входной канал для внешних сообщений;
есть triage;
есть owner;
есть статус и fix version;
есть уведомление пользователей;
есть контроль, что патч не принёс новый баг безопасности.

Если уязвимость живёт только в письме, чате или голове одного безопасника — для ОУД4 это почти то же самое, что её нет. Так что только реальные ратефакты1 Только верифицируемые источники, подтверждение от нескольких сторон (Dev, QA, Ops, Sec)

4.6. Supply chain — это уже не “дополнительная зрелость”, а прямая регуляторная тема

Компонент ALC_DEL_EXT.1 требует сведения о компонентах инфраструктуры разработки, зависящих от сторонних поставщиков, и о компонентах, которые поставляются или заимствуются у сторонних поставщиков. Там же отдельно фигурируют перечень поставщиков, сведения о договорах и перечень элементов инфраструктуры, воздействие на которые может привести к появлению недекларированных возможностей в ПО.

На практике это означает:

inventory зависимостей;
понимание, откуда приезжают библиотеки, образы, SDK, агенты;
SCA/SBOM;
контроль внешних registries и mirrors;
понимание, где third-party code становится частью вашего релиза.

Как видим Supply chain в ОУД4 — это уже не nice-to-have зрелой команды, а официальный предмет оценки.

4.7. Обновления и патчи — это тоже безопасность

В ALC_FPU_EXT.1 профиль прямо требует, чтобы регламент обновления предусматривал описание процедур получения обновления, контроля его целостности, типового тестирования, установки, контроля установки и верификации применения обновления. В AMA_SIA_EXT.3 сказано, что материалы анализа влияния обновлений на безопасность должны идентифицировать функции безопасности и компоненты объекта оценки, на которые влияет обновление, а оценщик должен подтвердить влияние или отсутствие влияния обновлений на безопасность.

То есть патч в модели Банка России — это не “собрали архив и отправили клиенту”. Это событие, которое должно иметь:

update procedure;
update package integrity control;
test method;
installation/verification flow;
update impact analysis;
доказательство, что уязвимость устранили и новых не занесли.

Безопасный релиз — это только начало. Потом ещё надо уметь безопасно обновлять продукт. То есть поддерживать, мониторить, латать если потребуется, и все это на плечах вендора) Полный цикл есть полный цикл! Браво, ЦБ РФ, мы долго этого ждали!

5. Где файдинги кладутся в tracker чтобы ОУД4 не превратился в театр созвонов

Вот здесь твой трекер вообще не “дополнение”, а рабочий нерв проекта. В загруженном шаблоне уже правильно заложены шапка проекта, master tracker и стартовые строки по блокам Scope / Docs / Code / Build / Testing / Vulns / Updates / Supply Chain / Governance

5.1. Сниппет шапки OUD4 Tracker

Поле	Значение
Продукт
Контур оценки / объект оценки
Релиз / версия
Репозиторий / ветка / tag
Команда
Product Owner
Security Owner
Архитектор
Dev Lead
DevOps / Release Owner
QA Owner
Doc / Compliance Owner
Дата старта подготовки
Плановая дата dry run
Плановая дата внешней оценки
Общий статус
Главные риски

5.2. Сниппет master tracker

Колонка	Что писать
ID	Уникальный номер строки
Block	Scope / Docs / Code / Build / Testing / Vulns / Updates / Supply Chain / Governance
Control / Requirement	Что нужно выполнить или доказать
Deliverable / Artifact	Чем это подтверждается
Owner	Конкретный человек
Current State	Есть / Частично / Нет / Есть, но не доказуемо
Status	Not started / In progress / Blocked / Ready for review / Done
Priority	Critical / High / Medium / Low
Evidence Quality	Strong / Medium / Weak
Gap Description	Чего не хватает
Action Required	Что делаем дальше
Auditor Question	Какой вопрос оценщика это закрывает

5.3. Несколько правильных стартовых строк

ID	Block	Control / Requirement	Deliverable / Artifact	Owner	Current State	Priority	Auditor Question
OUD4-001	Scope	Определён объект оценки	Scope document	Product Owner	Нет	Critical	Что именно оценивается?
OUD4-003	Docs	Подготовлено ЗБ / Security Target	Security Target	Security Manager	Нет	Critical	Где формально описаны требования и объект оценки?
OUD4-008	Build	Описана сборочная среда	Build environment scheme	DevOps	Нет	Critical	Где и как собирается релиз?
OUD4-011	Testing	Регламент статического анализа	SAST procedure	AppSec	Нет	Critical	Как выполняется статический анализ?
OUD4-018	Vulns	Реестр уязвимостей	Vulnerability register	AppSec	Нет	Critical	Как вы управляете уязвимостями?
OUD4-022	Updates	Процедура выпуска обновлений	Update procedure	Release Owner	Нет	Critical	Как вы выпускаете исправления?

Как только каждое требование превращается в артефакт, owner’а, статус и вопрос оценщика, ОУД4 перестаёт быть мистикой и становится обычным инженерным проектом. Это уже дело1 Чувствую, качественный софт нас ждет если не игнорировать ив се делать грамотно!

6. План что делать когда "я пришёл в организацию, тут бардак, документации мало, продукт надо дотащить до ОУД4"

Это самый практический кусок всей истории. Не для красивого блога, а для реальной жизни. Готов, ну, что делай заметки, погнали в практику!

Патч без анализа влияния на безопасность — это не завершённая remediation story. Это лотерея с change log.

6.1. Неделя 1: остановить расползание scope

Первая задача — не запускать сканеры, а прекратить хаос.

Что делаем сразу:

выбираем один объект оценки;
фиксируем один релиз-кандидат;
запрещаем менять scope без отдельного решения;
назначаем owner’ов по блокам;
заводим master tracker;
собираем список текущих дыр: нет ЗБ, нет схемы, нет регламента, нет реестра, нет update flow.

Результат недели:

есть scope, owners, baseline и единое место учёта evidence.

Вывод. Пока не заморожен scope, всё остальное — просто энергичное движение в туман.

6.2. Неделя 2–3: собрать minimum viable OUD4 pack

На этом этапе цель не “сделать идеально”, а быстро собрать каркас доказательств.

Минимум, который должен появиться:

draft ЗБ / Security Target;
описание объекта оценки;
архитектурная схема;
trust boundaries;
threat model;
перечень интерфейсов;
список внешних зависимостей;
релизная модель;
update flow draft;
rules of coding;
регламент доступа к исходникам;
регламент безопасности сборочной среды.

Первые две-три недели — это не время “чинить всё AppSec”, а время собрать скелет, на который потом лягут проверки и документы.

6.3. Неделя 3–5: восстановить контроль над кодом и сборкой

Теперь идём в инженерную фактуру.

По коду

фиксируем protected branches;
описываем merge/release roles;
подтверждаем review policy;
выгружаем evidence access control;
замораживаем baseline.

По build

рисуем build pipeline map;
фиксируем runners, build nodes, containers, artifact storage;
включаем осмысленное логирование шагов сборки;
организуем хранение артефактов;
добавляем checksums/signatures;
выделяем release owner.

Если у вас не под контролем исходники и build, дальше вы всё равно упрётесь в вопрос: “а что именно мы вообще показываем оценщику?”

6.4. Месяц 2: включить реальный контур анализа

Только теперь имеет смысл включать анализ и тестирование уже как систему.

Что делаем:

утверждаем регламент SAST;
утверждаем регламент DAST/runtime;
определяем критичные модули для fuzzing assessment;
прогоняем актуальные проверки по релизу;
собираем test traceability matrix;
закрываем negative scenarios;
заводим findings register и remediation backlog.

На этом этапе команда впервые понимает, что ОУД4 — это не штраф за существование, а структурированная модель контроля качества разработки.

6.5. Месяц 2–3: закрыть vulnerability process, supply chain и update flow

Дальше обычно всплывают три самые больные темы.

Vulnerability management

единый реестр;
triage;
severity;
owner;
fix version;
внешний канал сообщений;
уведомление пользователей.

Supply chain

dependency inventory;
SBOM/SCA;
список сторонних поставщиков;
контроль sources/registries;
учёт third-party code в релизе.

Updates

update procedure;
integrity check;
test method;
install/verify flow;
update impact analysis.

Именно здесь чаще всего выясняется, что продукт “вроде безопасный”, но жизненный цикл сопровождения у него неуправляемый.

6.6. Dry run перед внешней оценкой

Перед реальной оценкой нужен внутренний прогон.

Проверяем:

у каждой critical-строки в tracker есть owner;
по каждому critical control есть artefact;
evidence относится к нужному релизу, а не к “какому-то соседнему”;
ссылки живые;
нет серых зон между командами;
заранее собраны ответы на типовые вопросы оценщика;
сформирован residual risk list.

Мини-чек перед dry run

объект оценки утверждён;
ЗБ есть;
архитектура есть;
threat model есть;
baseline заморожен;
build evidence есть;
SAST/DAST evidence есть;
vulnerability register есть;
update procedure есть;
update impact analysis template есть.

Dry run нужен не для красоты, а чтобы поймать самую неприятную вещь: ситуацию, когда “вроде всё давно сделано”, но доказательств на это нет.

7. Что общего с Secure SDLC — и чем всё-таки Банк России отличается от "обычной good practice"

Если совсем коротко, то общего много:

security by design;
threat modeling;
secure coding;
secure build;
SAST/DAST/fuzzing;
vulnerability management;
patching and release governance.

Но есть и важные отличия.

Обычная good practice часто допускает инженерный ответ уровня:

“процесс есть, команда зрелая, сканеры работают, патчи ставим”.

Банк России хочет более жёсткую форму:

“покажите конкретный объект оценки, конкретный релиз, конкретные регламенты, конкретные evidence и конкретные процедуры, по которым вы это делаете”.

Именно поэтому ОУД4 в банковском контуре — это не просто Secure SDLC. Это Secure SDLC, который нужно формально доказать.

8. Чем "продукт реально готов" отличается от "мы собрали много файлов для аудитора"

Продукт к ОУД4 не готов, если:

scope плавает;
baseline не зафиксирован;
evidence относится к разным релизам;
build-среда не описана;
update flow живёт в голове релизника;
vulnerability process частично в Jira, частично в чатах;
SAST/DAST есть, но без регламента и разметки findings;
supply chain не инвентаризирован.

Продукт начинает быть готов, когда:

есть один объект оценки;
есть одна доказательная цепочка под него;
все артефакты привязаны к одному релизу;
у каждого блока есть owner;
Secure SDLC не декларируется, а доказывается.

По итогу, что могу сказать, критерий ОУД4 — это не экзамен на количество документов. Это экзамен на то, умеет ли команда показать управляемую и прослеживаемую инженерную систему.

9. Мини-кейс: как ОУД4 разваливается в реальной жизни, хотя всем кажется, что “у нас всё нормально”

Представим типичную ситуацию. Есть вендор, который делает коробочный финтех-продукт для банков. Продукт старый, большой, оброс интеграциями, кастомными модулями и историческими компромиссами. Команда уверена, что по безопасности у них “в целом всё неплохо”:

есть GitLab, есть CI, есть code review, где-то крутится SAST, релизы выходят, клиенты работают, incidents вроде бы не гремят.

А потом начинается подготовка к ОУД4. И тут вскрывается весёлое.

Шаг 1. Никто не может нормально определить объект оценки

На вопрос “что именно мы сертифицируем?” начинается классика:

“ну как, платформу”;
“ну вообще весь контур ДБО”;
“ну вот этот релиз, но там часть модулей от старой ветки”;
“ну клиент ещё допилил пару вещей, но это вроде не критично”.

*В итоге выясняется, что:
*

единого scope document нет;
границы объекта оценки плавают;
часть модулей реально относится к релизу, часть — нет;
кастомизации клиентов смешаны с базовой кодовой базой;
один и тот же компонент в документации и в репозитории называется по-разному.

Уже на этом этапе становится понятно: команда пока не готова показывать конкретный объект оценки, потому что у неё нет единой версии правды.

Шаг 2. Baseline релиза существует только “по памяти”

Формально релиз есть. Даже номер версии есть. Но когда начинают восстанавливать, из чего именно он собран, оказывается:

tag в репозитории не совпадает с фактической поставкой;
в release branch вносились “маленькие срочные фиксы” уже после сборки;
hotfix’ы уходили напрямую без нормальной фиксации;
часть библиотек подтягивалась в build не по lockfile, а “как приехало, так приехало”;
один из компонентов вообще собирался отдельным скриптом на сервере релиз-инженера.

На бумаге релиз есть. На практике воспроизводимого baseline нет. То есть команда не может честно доказать, что именно этот набор исходников породил именно этот артефакт.

Шаг 3. Build pipeline вроде бы есть, но доверять ему страшновато

Когда начинают разбирать сборочную среду, картина становится ещё веселее:

часть сборок идёт через CI;
часть — вручную;
артефакты лежат в нескольких местах;
права доступа на runner’ы давно никто не ревизировал;
логирование шагов сборки неполное;
контрольные суммы артефактов иногда сохраняются, иногда нет;
кто именно и когда запускал “финальную” сборку — можно установить только по косвенным признакам.

И вот здесь наступает важный момент: команда понимает, что у неё есть автоматизация, но нет доказуемой и контролируемой build-среды. А это две очень разные вещи.

Шаг 4. SAST/DAST есть, но это не процесс, а набор артефактов

Безопасники гордо показывают:

отчёты SAST;
пару DAST-сканов;
результаты старого пентеста;
презентацию с findings за прошлый квартал.

Но если копнуть глубже, оказывается:

отчёты относятся к разным версиям продукта;
часть findings помечена “accepted” без понятного owner’а;
нет единого правила, что именно должно сканироваться перед релизом;
нет внятной связи “компонент → проверка → результат → remediation”;
DAST запускался на стенде, который не совпадает с тем, что реально оценивается;
по fuzzing вообще “пока не дошли руки”.

И вот тут выясняется неприятная правда: инструменты есть, отчёты есть, а системы нет. То есть формально AppSec в компании как будто существует, но для ОУД4 это пока выглядит как коллекция отдельных активностей, а не как доказуемая практика Secure SDLC.

Шаг 5. Уязвимости живут в Jira, Excel, письмах и головах

Когда доходит до vulnerability management, начинается финальный танец.

Оказывается:

критичные баги лежат в Jira;
часть внешних замечаний пришла на почту support;
что-то фиксировали “по звонку клиенту”;
несколько исторических уязвимостей вообще известны только senior-разработчику и AppSec lead’у;
централизованного vulnerability register нет;
статусы и сроки remediation нигде не унифицированы.

На вопрос “как вы управляете известными уязвимостями?” команда отвечает долго, эмоционально и очень неструктурированно.

А для ОУД4 это плохой сигнал: если процесс нельзя показать в виде системы, то он считается слабоуправляемым, даже если фактически люди стараются и многое чинят.

Шаг 6. Обновления выпускаются, но влияние на безопасность не анализируется

Продукт обновляется регулярно. Но когда спрашивают:

как подтверждается целостность обновления;
как проверяется корректность установки;
как анализируется влияние изменений на безопасность;
как доказывается, что патч закрыл уязвимость и не внёс новую;

ответы начинают плавать.

Потому что фактически update process устроен так:

релиз собрали;
changelog написали;
клиенту отправили;
если не упало — значит, норм.

Для эксплуатации это ещё как-то живёт. Для ОУД4 — уже нет.

Чем всё заканчивается

Итог в таких историях почти всегда один и тот же, формально у компании много правильных слов:

DevSecOps, secure coding, CI/CD, review, security scans, patching.

Но как только появляется задача собрать всё это в одну доказательную цепочку под конкретный релиз и конкретный scope, конструкция начинает сыпаться.

Потому что ОУД4 ломается не там, где “совсем ничего нет”. ОУД4 ломается там, где много всего есть, но оно не связано между собой.

Мораль кейса

Главная проблема обычно не в том, что команда “ничего не делает по безопасности”.

Главная проблема в другом:

scope не зафиксирован;
baseline не заморожен;
evidence размазан по разным системам;
build не до конца контролируем;
AppSec-активности не сшиты в один lifecycle;
update flow не доведён до уровня доказуемого процесса.

Именно поэтому подготовка к ОУД4 почти всегда начинается не со сканеров, а с более скучной, но критичной работы:
собрать объект оценки, заморозить релиз, восстановить цепочку артефактов, назначить owner’ов и превратить разрозненные практики в систему.

10. Финальный вывод

Если совсем по-простому, Банк России здесь хочет увидеть следующее:

не хаотичный код, а контролируемую реализацию;
не “как-нибудь собирается”, а защищённую build-среду;
не “у нас есть сканер”, а регламентируемый анализ;
не “чиним по ситуации”, а vulnerability process;
не “патч потом выкатим”, а управляемые обновления;
не “мы в целом молодцы”, а конкретный evidence package под конкретный scope.

И в этом смысле ОУД4 довольно честный. Он не требует магии. Он требует, чтобы команда перестала жить в режиме “знание размазано по ветеранам, релизнику и одному безопаснику” и начала жить в режиме доказуемого Secure SDLC - такого, который можно открыть, проверить и привязать к конкретному релизу.

P.S. Если в компании хаос, не начинайте со сканера. Начинайте со связки:

scope → ЗБ → архитектура → контроль кода → контроль сборки → evidence tracker → SAST/DAST → уязвимости → updates/supply chain.

Это самый короткий путь от бардака к проекту, который реально можно тащить к ОУД4.

На этом пока все, друг, удачи! С тобой канал w2hack!

*Оригинальные публикации от 19 марта 2026 года: часть 1 и продолжение.

Product Security на практике: разбираем fintech-платформу от бизнес-логики и API до CI/CD, Kubernetes и Cloud

Ivan's Cybersecurity Notes — Sun, 11 Oct 2026 22:00:00 +0000

Preview

Про Product Security легко рассказывать списком технологий. SAST, DAST, SCA, threat modeling, Kubernetes, IAM, SIEM — всё знакомо, всё полезно. Но это не раскрывает суть продуктовой безопасности как security software engineering. Оттого ProdSec как самостоятельное направление безопасности часто путают с отдельными активностями AppSec, DevSecOps. Поэтому интереснее идти не от тулов, а от одного сквозного сценария. Именно на базе кейса разберем что, где и как. Ну, готовы!? let's go!

И, да, парни, учитывая что все текущие платформы\продукты с чем мне приходилось иметь дело были англоязычные, а так же корпус понятий и терминов из кибербеза нативно идет на английском, а иногда не имеет адекватного\точного перевода на русский, то далее в материале буду использовать понятийное native ядро с описанием остального контекста русским текстом.

Возьмём условную consumer fintech-платформу с инвестиционным кабинетом. Пользователь проходит KYC, пополняет счёт, покупает и продаёт активы, видит позиции и денежные остатки, добавляет банковские реквизиты и выводит доступные средства. Внутри — web и mobile clients, публичное API, несколько backend-сервисов, брокерская или custodial-интеграция, внутренний ledger, платёжный provider, Kafka, Kubernetes в AWS и CI/CD.

Disclaimer

Это не разбор реального финтех кейса (банка, брокера или биржи), но не утверждение, что у какой-либо компании\продукта есть описанные ниже проблемы. Архитектура составная. Я беру типовые паттерны из публично описанных financial systems и намеренно упрощаю детали, которые не нужны для разговора о Product Security. Все что не под NDA будет в тексте, остальное, ребята, извините:)

Что за финтех система в рассматриваемом кейсе

Основной пользовательский путь будет таким:

Продать актив → дождаться состояния, в котором деньги можно выводить → зарезервировать сумму во внутреннем ledger → добавить или выбрать банковский счёт → инициировать payout → пройти проверки → отправить перевод через payment provider → сверить внешний и внутренний результат.

Здесь есть важная бизнес-деталь. Исполненная сделка и деньги, доступные для вывода, — не всегда одно и то же состояние. Если представить, например, американские акции, стандартный settlement для большинства сделок с 28 мая 2024 года — T+1: продажа сегодня обычно рассчитывается на следующий рабочий день. В других рынках и продуктах правила могут отличаться, поэтому в нашей модели лучше явно различать хотя бы trade_executed, settled_cash, available_to_withdraw и reserved_for_payout, а не складывать всё в одно поле balance. SEC о переходе на T+1; для примера того, как брокер отдельно показывает доступность средств для вывода, можно посмотреть описание Cash Available to Withdraw у Fidelity.

Ledger здесь — не блокчейн, а внутренний финансовый журнал: система записей, по которым продукт понимает, кому принадлежит экономическая стоимость, почему она изменилась и какие операции уже произошли. Payout — вывод средств за пределы платформы. Эти два понятия дальше будут встречаться постоянно.

Если какие-то из затронутых доменов хочется потом разобрать отдельно — AppSec, API Security, DevSecOps, Cloud/Kubernetes, Threat Modeling или Secure SDLC — я собираю более широкую карту материалов в своей Product Security Knowledge Base. Здесь же останемся внутри одного кейса и посмотрим, как эти области встречаются в одном продукте.

Я сознательно не буду превращать материал в compliance-гайд по PCI DSS, PSD2, DORA, SEC/FINRA или локальному финансовому регулированию. В реальном проекте требования compliance и legal обязательно войдут в дизайн, но набор будет зависеть от страны, лицензий и модели бизнеса. Здесь нас интересует именно инженерная логика Product Security.

1. База продукта и что под капотом

Представим, что у платформы есть web и mobile clients, API Gateway, Identity Service, Portfolio Service, Trading Service, Ledger Service, Payout Service и отдельная административная плоскость для Operations. Внутри используются Kafka, PostgreSQL и Redis; workloads работают в Amazon EKS; инфраструктура описана Terraform; delivery идёт через GitLab CI, registry и GitOps. Снаружи находятся KYC/Fraud services, market-data provider, broker/execution venue или custodian и payment provider.

Упрощённо это можно представить так:

                         Web / Mobile
                              |
                    +-------------------+
                    | CDN / WAF / Edge  |
                    +-------------------+
                              |
                     +-----------------+
                     |   API Gateway   |
                     +-----------------+
                       /       |       \
                      /        |        \
             +---------+  +---------+  +----------+
             | Identity|  |Portfolio|  |  Trading |
             +---------+  +---------+  +----------+
                  |            |             |
                  |            |             +-----------> Broker / Custodian
                  |            |                              / Execution Venue
                  |            v
                  |       +---------+
                  +------>|  Ledger |<----- trade / cash events
                          +---------+
                               |
                         reserve / release
                               |
                          +-----------+       +-------------+
 Operations / Admin ---->|  Payout   |------>| Payment     |
                          +-----------+       | Provider    |
                               ^              +-------------+
                               |
                      KYC / Fraud / Risk

          Async flows -> Kafka / queues / provider webhooks
          State       -> PostgreSQL / ledger store / Redis where appropriate
          Runtime     -> Amazon EKS / AWS IAM / KMS / Secrets Manager
          Delivery    -> GitLab CI / Registry / GitOps

Смысл схемы не в выборе конкретных AWS-сервисов. Важнее увидеть несколько разных источников правды и trust boundaries. Trading domain знает, была ли сделка исполнена и рассчитана. Ledger отвечает за внутреннее денежное состояние. Payout domain управляет жизненным циклом вывода и резервирует средства. Payment provider знает, что произошло на внешнем платёжном rail. Identity/Fraud дают сигналы и решения, но не должны произвольно переписывать финансовую историю. Admin plane умеет делать очень мощные вещи и поэтому заслуживает отдельной модели доверия.

Такие идеи не взяты из воздуха. Square публично описывал Books как immutable double-entry accounting service, где ошибку исправляют новой компенсирующей записью, а не тихим UPDATE старой истории. Uber в актуальном обзоре своей Payments Platform описывает zero-sum money orders, ledger, entity changelog, Kafka-based asynchronous processing и audit trail; в более раннем разборе Gulfstream отдельно обсуждаются idempotency, versioning и reconciliation между асинхронными системами. Мы не копируем их архитектуру — это просто хорошие публичные подтверждения того, что financial correctness строится как отдельная инженерная система, а не как таблица users.balance.

На такой схеме security-инженер уже видит десятки потенциальных поверхностей атаки. Но если сразу побежать рисовать красные стрелки, легко утонуть в деталях. Я обычно сначала фиксирую security invariants — свойства продукта, которые должны оставаться истинными независимо от того, как именно атакующий пытается их нарушить.

Для payout flow инварианты будут примерно такими:

пользователь не может распорядиться чужими деньгами;
баланс нельзя увеличить без легитимной финансовой операции;
один бизнес-payout не должен привести к двум фактическим переводам;
смена payout-реквизитов не должна превращать обычный account takeover в мгновенную потерю денег;
администратор не может незаметно провести чувствительную операцию в обход утверждённого workflow;
внешний provider не становится источником абсолютной истины только потому, что сообщение пришло от него;
компрометация одного workload не должна автоматически давать права на весь AWS account;
в production должен попадать ожидаемый артефакт из ожидаемого source/build process.

Это уже хороший фундамент. Вместо абстрактного «нам нужен SAST» появляется вопрос: какое свойство системы мы защищаем, каким контролем и как потом проверим, что контроль реально работает?

Для общей базы требований пригодятся OWASP ASVS, NIST SSDF и OWASP SAMM. На сентябрь 2026 у ASVS актуальной стабильной версией является 5.0.0. Но framework всё равно не знает твою бизнес-логику — он помогает не забыть классы требований, а не заменяет инженерное понимание продукта.

2. Threat model: строим attack path

Для нового payout flow я бы не начинал встречу с вопроса «какие у нас тут STRIDE-категории». STRIDE полезен как способ не забыть классы угроз, но команде проще работать с конкретным сценарием: как атакующий превращает первоначальный доступ в деньги, данные или контроль над системой?

Например, довольно быстро появляются такие цепочки:

Stolen session
    -> add attacker's payout account
    -> no recent re-authentication
    -> no risk-based step-up
    -> create payout
    -> fraud service timeout fails open
    -> money leaves platform

Или:

RCE in Payout Service
    -> read workload credentials
    -> IAM role allows broad Secrets Manager access
    -> obtain another service credential
    -> call privileged internal API
    -> manipulate payout workflow

Или supply-chain вариант:

Compromised CI token
    -> modify pipeline definition
    -> inject malicious build step
    -> normal signing stage signs produced image
    -> deployment policy sees valid signature
    -> malicious but "legitimate" image reaches production

Здесь особенно хорошо видно, почему Product Security нельзя свести к поиску CVE. В первом сценарии каждый компонент может работать ровно так, как его написал разработчик, а атака всё равно получится из комбинации допустимых продуктовых решений.

На threat-model review мне нужен не красивый док в Confluence, а несколько вещей, с которыми команда сможет работать дальше: как-то опасные abuse cases, конкретные security requirements, владельцы контролей, способ проверки, нужная telemetry и решение о том, что будет release blocker. Логика близка к OWASP Threat Modeling Cheat Sheet: что мы строим, что может пойти не так, что мы с этим делаем и достаточно ли хорошо это сделали.

Возьмём смену payout-реквизитов. Требование «обеспечить безопасность функции вывода» бесполезно — его нельзя нормально ни реализовать, ни протестировать. Гораздо лучше написать так:

добавление нового payout account требует недавней re-authentication или step-up authentication;
backend проверяет ownership счёта и право конкретного subject использовать его для payout;
изменение реквизитов влияет на уже созданные, но ещё не исполненные операции предсказуемым образом;
для высокого риска можно применить cooling-off period, лимит суммы или дополнительное подтверждение;
внешний callback не меняет финансовое состояние без аутентификации, replay protection и проверки допустимого state transition;
административное исключение требует повышенной роли, сильной аутентификации и tamper-resistant audit trail.

Step-up — это дополнительная проверка личности именно перед чувствительным действием: например, повторная аутентификация, passkey/WebAuthn или другой сильный фактор. Maker-checker — принцип, при котором один сотрудник создаёт критическую операцию, а другой независимо её подтверждает.

Если свести весь подход к одной цепочке, получится так:

Abuse case
   -> security requirement
       -> architecture / control
           -> test
               -> runtime signal
                   -> release / risk decision

Эту цепочку полезно держать перед глазами почти на всём протяжении проекта.

3. API и деньги: authorization, state machine и асинхронность

В fintech API неприятные проблемы часто начинаются не с того, что злоумышленник смог войти, а с того, что система разрешила ему сделать после успешной аутентификации. Это важное различие: authentication отвечает «кто ты», authorization — «что именно тебе можно сделать сейчас с этим объектом».

В OWASP API Security Top 10 2023 несколько категорий напрямую связаны с authorization: BOLA, Broken Object Property Level Authorization и Broken Function Level Authorization.

Представим endpoint:

POST /api/v1/payouts
Authorization: Bearer <token>
Content-Type: application/json

{
  "portfolio_id": "pf-19482",
  "bank_account_id": "ba-8841",
  "amount": 25000,
  "currency": "EUR"
}

Слабая реализация может проверить только валидность token, наличие bank account и достаточный balance. На реальном review меня интересует больше:

Does this subject own or control portfolio pf-19482?
Can this subject use bank account ba-8841?
Is the account verified and in an allowed state?
Was payout destination changed recently?
Does the operation require step-up?
Is the amount allowed by current limits and risk state?
Is this state transition legal?
Has this business operation already produced an external transfer?

То есть authorization привязывается не к наличию кнопки и не просто к URL. Нужны subject + action + resource + context.

Например:

subject: user-42819
action: payout.create
resource: portfolio-pf-19482
amount: 25000 EUR
risk_state: elevated
recent_auth: false

Результат политики может быть не только allow или deny, но и require_step_up. В большой системе стоит заранее решить, где живёт эта логика: в каждом сервисе, общей library, policy engine или отдельном authorization service. Какой вариант лучше — зависит от архитектуры. Плохой вариант почти всегда один: пять сервисов, которые по-разному понимают одно и то же право.

Не путай mobile client с доверенной зоной (Zero trust always)

Мобильное приложение добавляет UX и дополнительные security-сигналы, но не переносит trust boundary на устройство пользователя. Клиент контролирует своё устройство, сеть и локальную копию приложения, поэтому сервер не должен принимать решение о balance, KYC state, payout limit или authorization на основании того, что «это прислал наш официальный APK».

Для native authentication flow сейчас разумно ориентироваться на OAuth/OIDC best practices: external user-agent для авторизации и Authorization Code Flow с PKCE для public clients. Это закреплено в RFC 8252 и актуальном OAuth Security BCP RFC 9700. Для проверки самого mobile client полезен OWASP MASVS.

Device attestation, root/jailbreak detection и certificate pinning могут быть дополнительными сигналами и повышать стоимость атаки, но я бы не делал из них единственную границу безопасности. Если атакующий модифицировал приложение и начал вызывать API напрямую, серверные invariants должны всё равно сохраниться.

Business logic: то что выше "шестеренок под капотом"

Теперь более интересная часть. Допустим, после settlement у пользователя есть available_to_withdraw = 15 000 EUR, дневной payout limit — 10 000 EUR, а резервирование средств и проверка лимита реализованы разными операциями. Два worker одновременно получают по запросу на 9 000 EUR, оба читают старое состояние и оба считают операцию допустимой.

В итоге система может зарезервировать или попытаться вывести 18 000 EUR. Это не обязательно выглядит как классическая «уязвимая строка кода». Проблема живёт в конкурентной обработке финансового состояния.

Для денежных workflow я предпочитаю явно записывать invariants:

available_to_withdraw must not become negative
unless the product explicitly supports credit

settled_cash + unsettled_cash + reserved_for_payout
must reconcile with the ledger model

one business payout ID must not result
in more than one effective external transfer

confirmed payouts in a window
must not exceed the effective limit

an external provider event may move a payout
only through an allowed state transition

Сам payout удобно воспринимать как state machine, например:

requested -> risk_review -> reserved -> submitted
          -> rejected                 -> failed
                                      -> completed
                                      -> reconciliation_required

Конкретные состояния могут быть другими, но смысл такой: не каждый входящий event имеет право перевести объект из любого состояния в любое. completed после уже отменённой операции, повторный submitted или callback для другого external payment ID должны либо быть безопасно отвергнуты, либо отправить операцию в явное состояние разбирательства.

После этого появляются понятные тесты: concurrent requests, duplicate webhook delivery, out-of-order Kafka events, retry после timeout, задержанная доставка события, изменение payout account во время pending operation, rollback одного сервиса после успешной операции другого.

Здесь есть важная инженерная тонкость. Фраза «сделаем exactly-once» сама по себе ничего не гарантирует. Внутри контролируемой транзакционной границы или собственного order-processing pipeline можно построить exactly-once semantics через strong consistency, immutable identifiers и idempotency — Uber, например, публично описывает такой подход для своих payment orders. Но на границе с внешним payment provider остаётся классический неприятный случай: provider уже произвёл перевод, а сеть оборвалась до того, как наш сервис получил подтверждение.

Поэтому защита строится слоями: durable business identifier, идемпотентная команда на внешнем API, atomic reservation внутри ledger boundary, database constraints/locking там, где это оправдано, transactional outbox или другой надёжный способ публикации событий, дедупликация на consumer side и обязательная reconciliation. Stripe, например, прямо рекомендует idempotency keys для безопасных retry, а в документации webhooks предупреждает о повторной доставке, retries и отсутствии гарантии порядка событий.

Если запрос завис после отправки, правильный вопрос не «повторить ли HTTP POST», а «можем ли мы доказать, был ли уже произведён экономический эффект». Если доказать нельзя, это отдельное бизнес-состояние, а не повод оптимистично поставить failed и отправить деньги ещё раз.

Это хороший пример границы между Application Security (привет инженерам) и архитектурой (привет архитектору). Security здесь не диктует команде конкретный паттерн транзакций, но обязан заметить, что нарушение consistency приводит не к красивой ошибке в логах, а к реальным деньгам.

4. Secure SDLC: переводим решения из встреч в delivery process

Если Product Security впервые видит новую payout feature после того, как код уже написан, обсуждать архитектуру поздно и дорого. Поэтому security должна появляться в обычном delivery process не отдельной церемонией в конце, а в нескольких точках, где решение ещё можно изменить. Более широкую карту того, как я связываю Secure SDLC, AppSec и DevSecOps, я держу в Product Security Knowledge Base; здесь оставим только те элементы, которые реально нужны нашему payout flow.

Я бы построил поток примерно так:

Product idea
   -> security triage
       -> threat model if risk is material
           -> security requirements
               -> design / implementation
                   -> automated checks + review
                       -> targeted validation
                           -> release decision
                               -> runtime telemetry
                                   -> feedback

Security triage не обязан быть часовым митингом. Это может быть несколько вопросов в design/RFC template: появились ли новые sensitive data, privileged action, external integration, authentication/authorization flow, financial state transition, internet-facing endpoint, file processing, server-side URL fetching или новая IAM boundary. Если ответов «да» много, задача автоматически уходит на более глубокий review.

Здесь же полезно разделить одноразовые решения и повторяемые решения. Если каждый новый сервис заново выбирает, как валидировать JWT, логировать audit event, получать cloud identity или проверять webhook signature, security-команда будет бесконечно ревьюить одну и ту же проблему. Лучше один раз сделать approved library, reference implementation или platform capability и превратить это в paved road — безопасный путь по умолчанию, которым разработчику проще воспользоваться, чем обойти.

Security Champions помогают масштабировать такой подход внутри engineering teams. Их задача не в том, чтобы превратить backend-разработчика в pentester. Гораздо полезнее, если champion знает локальный контекст команды, понимает approved patterns и может рано заметить, что новая feature меняет trust boundary или business invariant.

На этом этапе также появляется понятие evidence. Если requirement говорит «критический endpoint использует централизованный authorization middleware», хорошо, когда у тебя есть не только запись в wiki, но и способ автоматически проверить это в code review или integration test. Чем больше повторяемых решений превращаются в проверяемые guardrails, тем меньше security зависит от памяти конкретного человека.

5. Конвейер CI/CD

Допустим, разработчик меняет Payout Service. Pipeline может выглядеть так:

commit
  -> pre-commit / local checks
  -> merge request
      -> unit tests
      -> SAST
      -> secret scanning
      -> SCA
      -> IaC checks
      -> build
      -> SBOM
      -> image scan
      -> integration / abuse tests
      -> provenance / signing
  -> registry
  -> deployment policy
  -> production

Инструменты здесь полезны, но проблема начинается, когда каждая найденная High автоматически превращается в pipeline failed. Через несколько недель разработчики либо привыкают к красному pipeline, либо находят способ его обходить.

Для SAST можно использовать Semgrep, CodeQL, SonarQube, Checkmarx, Veracode и другие решения. Но реальная зрелость появляется, когда кроме generic SQLi/XSS rules команда начинает кодировать свои архитектурные ограничения. Например: privileged endpoint обязан использовать approved authorization middleware; full bank account нельзя писать в log; low-level payout client нельзя вызывать за пределами определённого service layer; отключение webhook verification должно быть невозможно простым feature flag.

Secret scanning полезно делать и локально, и на server side: Gitleaks, TruffleHog, Trivy или возможности самого SCM. Если production credential уже попал в Git history, удаления строки недостаточно — его надо считать exposed и ротировать.

В SCA я бы смотрел не только на CVSS. Важны direct/transitive dependency, reachability, runtime exposure, публичный exploit, наличие фактической эксплуатации и asset context. Для prioritization можно учитывать, например, CISA Known Exploited Vulnerabilities и EPSS, но ни один такой сигнал не является готовым risk score: EPSS оценивает вероятность эксплуатации CVE в ближайшие 30 дней и сам FIRST отдельно подчёркивает, что environmental impact он не знает.

Blocker или то что действительно должно остановить release

Для нашего продукта я бы ожидал блокировку при подтверждённом authorization bypass в payout/trading flow, double payout, возможности подделать provider event и изменить финансовое состояние, production secret в репозитории, internet-reachable admin surface без ожидаемого access control или реальном пути от RCE к чрезмерно привилегированной cloud identity.

Dependency issue тоже может быть blocker, если эксплуатация подтверждена или правдоподобна, vulnerable path действительно используется и impact для конкретного workload высок. Но «High в dev dependency, который не попадает в runtime» и «известно эксплуатируемая RCE в internet-facing parser» — это две совершенно разные задачи, даже если scanner окрасил обе строки одинаково.

Полезно воспринимать scanner severity как один вход в решение, а не само решение. Обычно важны exploitability, reachability, exposure, asset criticality, business impact, compensating controls и uncertainty. Неопределённость тоже фактор: если ты не можешь доказать, что критичный путь недостижим, это не автоматически делает риск низким.

Supply chain

Теперь вернёмся к сценарию с украденным CI token. Атакующий меняет pipeline, добавляет malicious build step, после чего обычная система подписывает созданный image. Подпись валидна — просто подписали уже не тот результат.

Поэтому software supply chain начинается раньше container registry. Нужно защищать source repository и pipeline definitions, требовать review для критичных изменений, ограничивать CI identities, по возможности использовать isolated/ephemeral runners, разделять build и signing authority, хранить provenance и проверять identity артефакта перед deployment.

Для формализации удобно смотреть на SLSA v1.2: в этой версии есть отдельные Build и Source tracks. Для SBOM подойдут CycloneDX и SPDX, для подписи и attestations — Sigstore/Cosign.

Сам SBOM ничего не «защищает», это не тула, а скорее док с содержанием. Он становится полезным, когда после новой CVE ты можешь быстро ответить: в каких production workloads есть компонент X, какой именно версии, откуда он попал в build и где vulnerability реально достижима?

6. Kubernetes и AWS

Допустим, в Payout Service появился RCE. Частая ошибка — сразу обсуждать container escape. Я бы первым делом посмотрел, что атакующий получает без всякого escape, используя уже выданные workload права.

Если pod работает privileged, с hostPath, CAP_SYS_ADMIN, writable root filesystem и чрезмерными Kubernetes RBAC permissions, компрометация действительно может быстро уйти в cluster layer. Для обычных application workloads разумный baseline — non-root, allowPrivilegeEscalation: false, минимальные capabilities, seccomp, отсутствие hostPath и privileged mode без обоснования. В Kubernetes для этого есть Pod Security Standards, где профиль Restricted — полезная отправная точка для большинства обычных workloads.

Политику лучше превращать в admission control, а не держать только в wiki. В зависимости от стека это могут быть Kyverno, OPA Gatekeeper или native ValidatingAdmissionPolicy/CEL. Но rollout policy тоже является инженерной задачей: включить жёсткий enforce на старом cluster без baseline — хороший способ остановить deployment. Практичнее пройти путь audit -> fix baseline -> warn -> enforce.

Для posture scanning пригодятся Trivy, Kubescape, kube-bench и cloud/CNAPP tooling. Для runtime visibility — Falco, Tetragon или коммерческий runtime sensor. Но scanner и runtime detector не заменяют понимание permission model.

Cloud IAM

Предположим, container escape невозможен, зато service account получает AWS role с такими правами:

secretsmanager:GetSecretValue *
s3:GetObject *
kms:Decrypt *
rds:*
iam:PassRole *

В таком случае атакующему cluster escape вообще может не понадобиться. Он уже получил credential, которым разрешено слишком много. Именно поэтому IAM review я начинаю от business capability workload. Payout Service действительно может нуждаться в конкретном secret, публикации события в конкретный topic и вызове ограниченного API. Из этого не следует, что ему нужен wildcard на Secrets Manager или право iam:PassRole.

На EKS long-lived AWS keys обычно можно убрать в пользу workload identity и временных credentials. AWS поддерживает, в частности, EKS Pod Identity; идея та же — связать IAM permissions с Kubernetes service account и не разносить статические ключи по YAML и CI. При этом важно помнить о credential isolation и IMDS: сама workload identity не спасает, если pod всё ещё может получить более привилегированные node credentials.

Secrets: а имнно Kubernetes Secret

Фраза «пароль лежит в Kubernetes Secret» сама по себе мало что говорит о security. Для обычного Kubernetes важно помнить две вещи: base64 в объекте Secret не является encryption, а безопасность сильно зависит от encryption-at-rest, RBAC и от того, кто вообще может создавать workloads в namespace и тем самым получать доступ к Secret.

Но в нашем EKS-примере нужна более точная оговорка. Amazon EKS начиная с Kubernetes 1.28 включает envelope encryption для всех Kubernetes API data по умолчанию, используя AWS KMS provider v2; для старых EKS 1.27 и ниже encryption Secrets на уровне Kubernetes API настраивалась отдельно. Это хороший пример того, почему cloud-specific defaults надо проверять, а не переносить общую фразу из vanilla Kubernetes один в один. Документация AWS EKS.

При этом encryption at rest всё равно не решает весь lifecycle. Для production я смотрю на создание, хранение, delivery, access, rotation, revocation и audit. В зависимости от архитектуры это могут быть AWS Secrets Manager, Vault, External Secrets, KMS и short-lived credentials. Часто лучший secret — тот, который удалось заменить identity и вообще перестать хранить как долгоживущий credential.

Ledger integrity важнее одной только confidentiality

Финансовая система обязана защищать не только секретность данных, но и их целостность. Шифрование database at rest мало поможет, если один чрезмерно привилегированный service account может тихо переписать transaction state.

Для ledger полезно отдельно продумать append-only или tamper-evident audit patterns, строгие state transitions, separation of duties, reconciliation и восстановление истории. Хороший вопрос для architecture review звучит так: какой минимальный набор компонентов или identities нужно скомпрометировать, чтобы незаметно изменить финансовую истину? Если ответ — «один обычный backend service», blast radius слишком большой.

7. Third party и admin plane: режем доверие с обеих сторон

Payment provider присылает webhook:

POST /webhooks/payment-status

{
  "payment_id": "ext-5521",
  "status": "completed"
}

*IP allowlist *можно использовать как дополнительный слой, но не как единственное доказательство подлинности. Нужны TLS, authentication provider, cryptographic signature или HMAC, timestamp/nonce, replay window, idempotent processing и проверка state machine. Для серьёзных расхождений нужен reconciliation с provider API.

Даже правильно подписанное сообщение не должно иметь полномочие сказать: «сделай любую внутреннюю транзакцию COMPLETED». Оно относится к конкретному external payment ID и может вызвать только допустимый переход конкретного внутреннего объекта. Если provider дважды доставил одно событие — экономический эффект не должен удвоиться. Иначе это бага:)

Здесь же я бы посмотрел на admin plane. Обычный customer API часто получает больше security-внимания, чем внутренняя панель, хотя именно там живут refund, account unlock, KYC override, manual payout и другие очень мощные действия. Для них нужны отдельная authorization model, strong authentication, least privilege, step-up для особо чувствительных операций, maker-checker там, где это оправдано, и аудит, который оператор не может тихо подчистить теми же credentials.

Отдельная организационная граница проходит между Product Security и Fraud. Такие показатели как Credential stuffing, anomalous device, mule account и подозрительная скорость вывода могут быть fraud signals в анти-фрод системах; а вот broken authorization, unsafe state machine и compromised service identity — больше про security concerns. В реальной fintech-команде эти области постоянно пересекаются. Да, да, так. Спорить, «чей это тикет», менее полезно, чем заранее договориться о shared signals, ownership и escalation path. Короче, работать надо командой, а не валить ответственность на смежника:) Безопасность здесь партнер, а не стопер бизнеса или разработки.

8. Проверка: pentest должен атаковать предположения продукта

Перед release payout flow имеет смысл провести targeted security validation. Автоматические инструменты вроде OWASP ZAP, Burp Suite, API fuzzing и custom integration tests хороши и полезны, паплайн робит, но pentester получит намного больше пользы, если кроме URL ему дать architecture context и abuse cases (белый ящик).

Я бы сформулировал задание примерно так:

Can you create a payout from another user's portfolio?
Can you reference another user's bank account object?
Can a customer identity invoke an admin transition?
What happens if you send the same payout concurrently 20 times?
Can a completed provider event be replayed?
What if payout account changes while payment is pending?
Can undocumented or old API versions bypass current controls?
Can a field hidden by UI be mass-assigned through API?

Для pentester это тоже меняет стиль работы. Вместо «нашёл IDOR — severity High» появляется цепочка: finding Х-> attacker action Y-> prerequisite -> business effect Z -> next step. Например, BOLA на read-only history endpoint и BOLA на payout destination — один класс weakness, но совершенно разный продуктовый риск.

И наоборот, отсутствие обычных OWASP bugs ещё не означает, что flow безопасен. Такие слабости как-то Race condition, не критичный replay, неоднозначный state confusion и "легенький" abuse of legitimate functionality могут потребовать custom scripts и понимания domain model\платформы изнутри.

Если preventive control не сработал — что мы увидим?

На design review полезно буквально задать этот вопрос. Для payout flow я бы хотел видеть события вокруг добавления/смены payout account, step-up, создания и изменения payout, административного override, duplicate/replayed webhook, невозможного state transition, необычной payout velocity и reconciliation mismatch.

В platform layer полезны denied IAM calls, secret access, Kubernetes exec, privileged workload creation, admission failure, artifact verification failure и неожиданный outbound traffic. Но логировать просто HTTP 403 мало — нужен контекст: кто действовал, над каким объектом, какое policy decision сработало и с каким request/session identifier.

При этом security logging не должен сам превращаться в утечку. Password, access token, secret, полный bank account number или чувствительный authentication material в log не нужны. Для общей базы здесь полезен OWASP Logging Cheat Sheet.

Ценность появляется, когда detection смотрит на последовательность:

new device
 -> credential reset
 -> payout account changed
 -> multiple step-up failures
 -> successful step-up
 -> large payout

Каждое событие может быть легитимным. Вместе они уже меняют риск. Если команда использует MITRE ATT&CK (а я про нее писал статью ранее), я бы применял его к наблюдаемому поведению атакующего и detection coverage, но не смешивал с CWE/ASVS. Weakness в authorization и adversary technique — разные уровни модели. И риски разные, но все неприятные.

Incident readiness как часть дизайна продукта

Представим, что парни в SOC действительно увидел подозрительный payout. До инцидента должно быть понятно, кто может временно остановить выплаты, кто блокирует session/account, как отозвать credentials, где взять неизменённые audit events, как сверить внутренний ledger с provider и кто принимает решение о customer communication. Это не означает, что Product Security заменяет Incident Response. Его задача — убедиться, что продукт вообще предоставляет технические рычаги для containment и recovery. Kill switch, account hold, key rotation, feature rollback и reconciliation лучше продумать до первого настоящего инцидента. Итогом SoC, CERT нужны как по факту так и по комплаенсу.

9. Findings, release и risk acceptance

После automated scans, review и pentest легко получить десятки findings. Если просто превратить их в десятки одинаковых tickets, Product Security почти не добавила контекста. Сначала я бы нормализовал: duplicate ли это, false positive, production ли asset, достижим ли vulnerable path, есть ли public exposure, какой business impact, существуют ли compensating controls и связан ли finding с реальным attack path. Затем уже определяется priority.

Severity и priority — разные вещи. Severity описывает техническую опасность проблемы. Priority отвечает на вопрос, что организация должна делать с ней сейчас.

Подтверждённый payout authorization bypass — это очевидный immediate/release-blocking риск. Reachable dependency vulnerability в ограниченном internal worker может иметь высокий severity, но другой remediation window. Hardening gap без практического attack path может уйти в backlog. Это не «смягчение security», а нормальная triage-модель.

Иногда риск нельзя разумно устранить к дате release. Тогда нужен risk acceptance, но не в виде кнопки Ignore. Я хочу видеть понятный сценарий риска, affected assets, prerequisites, impact, compensating controls, detection/recovery, owner, дату истечения и trigger для пересмотра.

Например:

Risk:
Legacy reporting endpoint exposes broader data than target model.

**Exposure:**
Authenticated operations users only; no internet route.

**Compensating controls:**
SSO + MFA, restricted network path, audit logging,
quarterly access review.

**Residual impact:**
Unauthorized reporting-data access after compromise
of an internal operations identity.

**Decision:**
Accepted until service migration.

**Owner:**
VP Operations.

**Expires:**
2026-12-15.

Exception без срока имеет неприятную привычку превращаться в архитектуру.

Где здесь Product Security Manager\Lead

Представим, Security предлагает 24-hour cooling-off после добавления нового банковского счёта. Product Security Manager справедливо отвечает: это ухудшит conversion и создаст поддержку для нормальных клиентов.

Ответ «такова security policy» ничего не решает. Лучше положить на стол варианты: полный cooling-off, instant payout после сильного step-up и хороших risk signals, либо instant payout только до определённого лимита с задержкой выше threshold. Затем Product, Fraud, Engineering и Security сравнивают residual risk, UX, detection и recovery. Так выглядит взрослая роль Product Security: не максимизировать количество запретов, а сделать риск понятным и управляемым, не потеряв сам продукт.

10. Что в этом кейсе делает Senior Product Security Engineer

Если посмотреть на весь путь целиком, senior здесь нужен не потому, что знает на двадцать названий scanners больше. Его ценность в том, что он удерживает связь между бизнес-сценарием, архитектурой, реализацией и production.

До разработки он помогает найти critical assets, trust boundaries, invariants и abuse cases. На design review спорит про authorization model, failure modes, third-party trust и blast radius. Во время implementation превращает повторяемые решения в libraries, tests, CI policies и paved roads. Перед release проверяет не «все ли dashboards зелёные», а остался ли material attack path, который делает запуск неприемлемым. После release смотрит на telemetry, exceptions, новые CVE, drift и incidents и возвращает выводы обратно в design.

DevSecOps-инженер в этом же кейсе, скорее всего, глубже возьмёт pipeline, runner isolation, artifact provenance, policy-as-code и deployment controls. AppSec-инженер — API, code, authorization, threat modeling и security testing. Pentester — проверку abuse cases и реальную эксплуатацию предположений. Platform/Cloud Security — Kubernetes и IAM. Product Manager — UX, delivery и business trade-offs. Senior Product Security должен не заменить всех этих людей, а собрать их решения вокруг одного продуктового риска.

Поэтому и метрики лучше выбирать системные. Количество найденных vulnerabilities само по себе почти ничего не говорит. Мне интереснее доля high-risk features, которые прошли security design review до implementation; покрытие critical flows security tests; возраст risk exceptions; time-to-remediate действительно exploitable issues; процент production artifacts с проверяемым provenance; количество privileged workloads и long-lived credentials; false-positive rate; доля defects, пойманных до production; recurrence одного и того же класса ошибок.

Последняя метрика особенно полезна. Если за год команда пять раз нашла один и тот же broken authorization pattern в разных сервисах, проблема уже не в пяти разработчиках. Скорее всего, не хватает общей authorization capability, reference implementation, architecture rule или обучения. Senior чинит систему, которая воспроизводит дефект, а не только очередной дефект.

А какие тулы юзаем?

Их много, и выбирать стек без контекста бессмысленно. Для небольшого продукта вполне реально начать с комбинации Semgrep/CodeQL для code analysis, Gitleaks или TruffleHog для secrets, Trivy/Grype для dependencies и images, Checkov/Trivy для IaC, Syft/CycloneDX для SBOM, Kyverno/Gatekeeper для admission policy, Kubescape/kube-bench для Kubernetes posture, Falco/Tetragon для runtime visibility и DefectDojo для aggregation/workflow.

Коммерческие платформы — Snyk, Checkmarx, Veracode, GitHub Advanced Security, Wiz, Prisma Cloud, Orca, Mend, JFrog и другие — часто покупают не потому, что «open source плохой», а потому что большой организации нужны centralized inventory, correlation, policy, reporting, integrations, support и единый operating model. Ну, а в бесплатном ПО этого, как понимаешь, друг, нихера нет:)

Иными словами, инструменты появляются после модели риска, а не вместо неё.

Итог

Если убрать названия технологий, весь наш fintech-кейс можно свернуть в несколько вопросов:

Что нельзя позволить атакующему? Он не должен распоряжаться чужими деньгами, нарушать финансовую истину, обходить critical approval, внедрять код в trusted build или превращать одну локальную компрометацию во всю платформу.
Где это может сломаться? В authorization, business logic, async workflow, third-party integration, CI/CD, dependency, Kubernetes, IAM или admin process.
Что мы строим против этого? Не абстрактную «security», а конкретные controls с владельцами и понятными failure modes.
Как докажем, что они работают? Automation, abuse tests, architecture review, policy-as-code, pentest и ручная проверка там, где automation не понимает бизнес-смысл.
Что произойдёт, если control всё-таки обойдут? Нужны telemetry, detection, containment и recovery.
Можно ли выпускать продукт? Это уже risk decision, в котором техническая severity — только одна часть контекста.

В итоге получается вполне приземлённая цепочка:

Business asset / invariant
    -> abuse case
        -> security requirement
            -> architecture / control
                -> validation
                    -> runtime signal
                        -> risk decision
                            -> feedback into product

Для меня именно это и есть Product Security в практическом смысле: не отдельный этап SDLC и не набор scanners, а инженерная система, которая держит связь между тем, что важно продукту, тем, как его реально атакуют, и тем, как команда принимает технические решения от первого design review до production incident. Этим я и занимаюсь:)

P.S.

Если хочется продолжить от этого кейса уже по отдельным доменам — threat modeling, API Security, AppSec, DevSecOps, Cloud/Kubernetes, Secure SDLC или leadership operating model — я собираю такие материалы в Product Security Knowledge Base. Но сам принцип я бы оставил тем же: сначала понять продукт и его инварианты, а уже потом выбирать framework, control и инструмент.

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

Ivan's Cybersecurity Notes — Tue, 06 Oct 2026 22:00:00 +0000

Практическая модель 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

Об авторе

MITRE ATT&CK для Product Security: как связать pentest, threat modeling, CI/CD и реальные сценарии атак

Ivan's Cybersecurity Notes — Wed, 30 Sep 2026 22:00:00 +0000

Матрицу MITRE ATT&CK обычно ассоциируют с SOC, threat hunting и red team. Это база. Но она может быть полезна намного раньше — на этапе threat modeling, pentest, архитектурного review и CI/CD. И не только для инциденщиков, но и в теме Product Security. В статье разбираю, как перейти от isolated finding к attack path и связать attacker behavior с preventive controls, что такое security validation, причем тут runtime detection и release risk на примерах public API, SSRF → cloud, Kubernetes и software supply chain. Отдельно покажу, почему vulnerability нельзя автоматически превращать в ATT&CK technique и в каких Product Security сценариях ATT&CK лучше вообще не использовать.

В чем недопонимание потенциала MITRE ATT&CK

Когда говорят про MITRE ATT&CK, в голове обычно сразу появляются SOC, SIEM, threat hunting, red team и огромная цветная матрица, которую кто-то заботливо раскрасил в ATT&CK Navigator. Как уже писал в анонсе это база, все так и есть. Product Security же живёт вроде бы в другом мире: Secure SDLC, threat modeling, SAST/SCA/DAST, code review, pentest, API security, Kubernetes, cloud, CI/CD, release gates и security architecture.

Из-за этого ATT&CK часто воспринимают как инструмент, который становится полезным уже после релиза, когда продукт атакуют и нужно понять, что именно делает злоумышленник. На практике я бы смотрел на неё шире.

ATT&CK может стать общим языком между:

pentest findings;
abuse cases и threat model;
AppSec и DevSecOps controls;
cloud и Kubernetes security;
red team и adversarial testing;
detection engineering;
incident response;
release risk и security ownership.

Но есть важное условие: не надо превращать ATT&CK в ещё один каталог уязвимостей. И так, ниже в этом материале разберём, как использовать MITRE ATT&CK именно в Product Security: от отдельного finding до attack path, preventive controls, security testing, telemetry и release decision. Let's Go, парни!

TL;DR: модель в одной минуте

Если оставить от всей статьи одну идею, я бы оставил эту:

Weakness / Finding
        ↓
Attacker Action
        ↓
ATT&CK Technique
        ↓
Attack Path
        ↓
Preventive Control
        ↓
Validation
        ↓
Telemetry / Detection
        ↓
Owner + Risk Decision

Например:

SSRF
 ↓
Attacker queries cloud metadata
 ↓
T1552.005 — Cloud Instance Metadata API
 ↓
Temporary cloud credentials
 ↓
Attacker uses the credentials
 ↓
T1078.004 — Valid Accounts: Cloud Accounts
 ↓
Cloud discovery / data access

Главный принцип здесь простой:

Мы мэппим не название vulnerability. Мы мэппим действие атакующего, которое эта vulnerability делает возможным.

И если вы не можете одним предложением сказать, что именно делает attacker, ATT&CK ID, скорее всего, пока ставить рано.

ATT&CK — это не каталог уязвимостей

MITRE ATT&CK — это knowledge base тактик и техник adversary behavior.

Упрощенно:

Tactic отвечает на вопрос: зачем attacker выполняет действие?
Technique / Sub-technique отвечает на вопрос: каким способом он достигает этой цели?

Например:

Initial Access — получить первоначальный доступ;
Execution — выполнить код или команды;
Credential Access — получить credentials;
Discovery — понять, где attacker оказался и что ему доступно;
Lateral Movement — двигаться дальше;
Collection — собрать данные;
Exfiltration — вывести их;
Impact — нарушить работу, изменить или уничтожить данные и системы.

Если prevention когда-нибудь не сработает, увидим ли мы это поведение в production?
Но основная мысль всё равно остаётся прежней:

ATT&CK описывает поведение атакующего, а не дефект в коде.

CWE, CVE, OWASP, STRIDE и ATT&CK отвечают на разные вопросы

Частая ошибка — пытаться выбрать один «главный» framework. На практике они работают на разных слоях. Смотрим таблицу ниже.

Модель / источник	На какой вопрос отвечает
CWE	Какой класс weakness существует в software?
CVE	Какая конкретная известная vulnerability существует в продукте или компоненте?
CVSS	Как оценить severity конкретной vulnerability по формальной scoring model?
OWASP Top 10 / API Top 10	Какие классы application security risk особенно важны и распространены?
OWASP ASVS	Какие application security requirements и verification controls нужны продукту?
STRIDE	Какие категории угроз стоит рассмотреть при threat modeling?
MITRE ATT&CK	Какие действия может выполнять adversary и как они складываются в attack path?

Отсюда полезное разделение:

CWE / OWASP
Что сломано?

**ATT&CK**
Что attacker сделает с этим дальше?

**Product Security**
Как разорвать путь и доказать, что он разорван?

Четыре правила нормального ATT&CK mapping

Прежде чем переходить к кейсам, я бы ввёл четыре простых правила.

Правило 1. Начинайте с глагола атакующего

Не так:

уязвимость SSRF → T1552.005

А так:

Attacker использует SSRF, чтобы запросить cloud instance metadata и получить временные credentials → T1552.005.

Technique должна описывать действие, а не просто ассоциироваться с названием finding.

Правило 2. Не путайте prerequisite и выполненную technique

Например, excessive Kubernetes RBAC ещё не означает T1610 — Deploy Container. Он только создаёт prerequisite.

T1610 появляется, когда adversary действительно использует доступ для развёртывания контейнера.

Точно так же украденный cloud token ещё не означает T1078.004 — Valid Accounts: Cloud Accounts. Эта technique становится релевантной, когда attacker использует valid cloud credentials.

Правило 3. Не мэппите следующий шаг только потому, что он возможен

Attack path может выглядеть так:

Exploit
 ↓
Credential Access
 ↓
Discovery
 ↓
Collection
 ↓
Exfiltration

Но если вы доказали только первые два шага, не надо автоматически красить следующие три.

Разделяйте:

observed — действие реально наблюдалось;
validated — действие воспроизведено в controlled test;
feasible — архитектура делает его реально достижимым;
hypothetical — теоретически возможно, но evidence пока нет.

Правило 4. Если ATT&CK ничего не добавляет — не используйте её

Не каждый Product Security risk нужно мэппить.

Например, business-logic flaw в payout API может позволить изменить реквизиты получателя или обойти approval workflow. Это может быть критический риск, даже если ATT&CK mapping получается натянутым.

В таком случае лучше оставить:

Business Abuse Case
 → Security Requirement
 → Control
 → Test
 → Monitoring

чем ставить случайный ATT&CK ID ради красивой таблицы. Это не недостаток ATT&CK. Просто она решает другой класс задач.

Product Security mapping: от finding к attack path

Я бы использовал такую рабочую цепочку:

Asset / Crown Jewel
        ↓
Data Flow / Trust Boundary
        ↓
Abuse Case / Finding
        ↓
Attacker Action
        ↓
ATT&CK Technique(s)
        ↓
Attack Path + Business Impact
        ↓
Preventive Control
        ↓
Security Validation
        ↓
Telemetry / Detection
        ↓
Owner + Release Decision

Это принципиально отличается от стандартного workflow:

Critical finding → Jira → developer → fixed.

Для Product Security важен не только факт исправления дефекта.

Нужно понять:

какой asset или trust boundary затронут;
что именно attacker сможет сделать;
какой следующий шаг становится достижимым;
где находится реальный business impact;
какой control разрывает path;
как проверить этот control;
увидим ли мы атаку, если control обойдут;
кто владеет residual risk;
можно ли после этого выпускать продукт.

Кейс №1. Public-facing API: RCE — это только начало

Представим обычную архитектуру:

Internet
   ↓
API Gateway
   ↓
Public API
   ↓
Application Service
   ↓
Kubernetes / VM
   ↓
Cloud Services / Database / Storage

Pentest находит vulnerability, позволяющую добиться server-side code execution. В классическом AppSec report можно написать:

Critical RCE in public API.

Это правильно, но для Product Security слишком плоско.

Шаг 1. Как attacker попадает внутрь?

Если exploitation публичного приложения используется как initial access, здесь хорошо ложится:

T1190 — Exploit Public-Facing Application.

Но сама по себе RCE не означает, что мы должны автоматически добавить ещё пять Execution techniques. Сначала нужно посмотреть, что происходит после exploitation.

Шаг 2. Что реально умеет compromised process?

Product Security должен спросить:

от какого OS user работает процесс;
какие filesystem permissions у него есть;
можно ли запустить shell или interpreter;
какие environment variables доступны;
какие secrets смонтированы;
какой service account / workload identity используется;
доступен ли Kubernetes API;
доступен ли cloud metadata endpoint;
какой outbound traffic разрешён;
какие internal services достижимы;
можно ли обратиться к database/storage напрямую.

Если attacker действительно начинает выполнять shell-команды, тогда можно рассматривать релевантную Command and Scripting Interpreter sub-technique. Но не надо выводить её только из слова RCE — mapping должен следовать фактическому действию.

### Шаг 3. Где blast radius?
Допустим, application workload имеет доступ к cloud instance metadata.

Следующий action:

Attacker обращается к metadata endpoint за credentials.

Это уже сильный mapping на:
T1552.005 — Unsecured Credentials: Cloud Instance Metadata API.

И тут появляется хороший Product Security-вопрос:

Даже если application layer когда-нибудь будет скомпрометирован, что сможет получить этот workload и куда он сможет пойти дальше?

Controls:

workload identity вместо долгоживущих static credentials;
least privilege IAM;
hardened metadata access;
egress restrictions;
минимизация secrets в environment/config;
network segmentation;
минимальные permissions к internal APIs и storage.

То есть один AppSec finding начинает влиять на architecture и blast radius, а не только на код vulnerable endpoint.

## Кейс №2. SSRF → cloud metadata → credentials → data
SSRF — один из самых наглядных примеров, потому что сама MITRE для T1552.005 прямо рассматривает сценарий доступа к cloud metadata через SSRF.

Представим public-facing application с SSRF. Плоский triage:

SSRF. High/Critical. Исправить URL validation.

Attack-path подход:

SSRF
  ↓
Attacker queries Cloud Metadata API
  ↓
Temporary Credentials
  ↓
Attacker uses Cloud Account / Workload Identity
  ↓
Cloud Discovery
  ↓
Cloud Storage Access
  ↓
Collection / Exfiltration

Здесь возможны разные ATT&CK techniques — но только когда соответствующее действие реально происходит или подтверждено как feasible.

Attack step	Возможный ATT&CK mapping	Когда mapping оправдан
Exploitation public app	T1190	SSRF используется как механизм exploitation / initial access в конкретном сценарии
Query metadata	T1552.005	Attacker обращается к metadata API за credentials / sensitive metadata
Use stolen cloud credentials	T1078.004	Credentials не просто получены, а реально используются
Enumerate cloud services	T1526	Attacker определяет доступные cloud services
Enumerate cloud infrastructure	T1580	Attacker перечисляет cloud infrastructure/resources
Collect data from object storage	T1530	Данные действительно читаются/собираются из cloud storage

Обрати внимание на разницу между T1526 и T1580. Не надо ставить оба ID «на всякий случай».

Если attacker выясняет, какие cloud services доступны identity — это один тип discovery. Если enumerates конкретную cloud infrastructure — другой. Technique выбирается по действию, а не по желанию сделать chain длиннее.

Как это превращается в Product Security controls

Attack step	Preventive control	Validation	Detection / telemetry
SSRF	strict allowlist, безопасный URL parsing, запрет ненужных outbound destinations	targeted SSRF regression tests	unusual outbound requests from service
Metadata access	hardened metadata mechanism, network restrictions	проверить доступ к metadata из workload	обращения к metadata endpoint
Credential theft	short-lived workload identity, минимизация exposed credentials	credential exposure review	аномальное получение/использование temporary credentials
Cloud account abuse	least privilege IAM, scoped roles, conditional restrictions	effective-permissions test	unusual API calls для workload identity
Discovery	минимальные `list/describe` permissions	IAM simulation / controlled enumeration	burst of enumeration calls
Storage access	resource policies, access boundaries	negative/positive authorization tests	unusual object listing / reads
Exfiltration	egress controls, rate/anomaly limits	controlled exfiltration simulation	anomalous data volume / destination

Теперь security review перестаёт быть разговором об одной SSRF. Мы проверяем устойчивость продукта к целой post-exploitation chain. И особенно полезно, если chain разрывается раньше:

SSRF
 ↓
Metadata unreachable
 ↓
STOP

или:

Credentials obtained
 ↓
IAM role cannot access sensitive data
 ↓
STOP

Это уже evidence того, что defense-in-depth реально уменьшает blast radius.

Кейс №3. Kubernetes: misconfiguration ещё не technique

Допустим, security review обнаружил:

container запускается как root;
разрешён privileged: true;
используется опасный hostPath;
service account имеет избыточный RBAC;
NetworkPolicy отсутствует.

Это серьёзные security weaknesses. Но сам список ещё не является ATT&CK chain. Нужен attacker action. Представим, что workload уже скомпрометирован, а его service account позволяет создавать pods.

Тогда возможна цепочка:

Compromised workload
       ↓
Attacker uses excessive Kubernetes permissions
       ↓
Deploys privileged container
       ↓
Mounts / accesses host resources
       ↓
Escapes to host
       ↓
Accesses other workloads / node resources

Здесь уже появляются:

T1610 — Deploy Container — когда adversary действительно разворачивает container;
T1611 — Escape to Host — когда происходит выход из containerized environment к host.

Product Security controls

run as non-root;
запрет privileged containers;
минимизация Linux capabilities;
read-only root filesystem где возможно;
seccomp / AppArmor / SELinux;
Pod Security Admission / equivalent admission policy;
запрет опасных hostPath mounts;
запрет host PID / IPC / network без необходимости;
least privilege Kubernetes RBAC;
отдельные service accounts для workloads;
NetworkPolicy;
минимизация Kubernetes API access;
audit logging.

Validation

Не только manifest scanning. Полезнее проверить сам attacker path:

может ли compromised service account создать новый pod;
может ли он создать privileged pod;
может ли mount host filesystem;
доступны ли node credentials / sockets;
можно ли обращаться к Kubernetes API из workload;
можно ли добраться до соседних workloads.

Runtime

Telemetry тоже следует из attack path:

создание privileged pods;
неожиданные DaemonSets;
новые hostPath mounts;
изменения RBAC;
выдача cluster-level privileges;
аномальные API calls от workload identities;
запуск контейнеров из неожиданных images/registries.

В итоге одна цепочка связывает AppSec, platform security, Kubernetes hardening, policy-as-code и runtime detection.

Кейс №4. CI/CD: когда valid signature ничего не гарантирует

Product Security сегодня отвечает не только за application code, но и за то, как этот код превращается в production artifact.

Представим сценарий:

attacker получает developer или CI credential;
меняет pipeline definition или referenced build script;
CI выполняет malicious step;
build создаёт изменённый artifact;
legitimate signing system подписывает artifact;
release попадает в production или к downstream customers.

При этом формально всё может выглядеть хорошо:

SAST — passed;
SCA — passed;
image scan — passed;
signature — valid.

Но доверенный build path уже контролируется attacker.

T1677 и T1195 — не одно и то же. Это место особенно важно не смешивать.

T1677 — Poisoned Pipeline Execution описывает malicious execution внутри CI/CD pipeline: прямое изменение pipeline configuration, indirect execution через referenced scripts/tests или запуск malicious code через public pipeline execution.

А T1195 — Supply Chain Compromise описывает manipulation продукта или delivery mechanism до получения конечным потребителем.
**
У него есть, в частности:**

Поэтому:

Attacker edits your CI pipeline and steals secrets
→ T1677 is a strong mapping

А если manipulated build/dependency затем становится механизмом compromise для downstream consumer:

Compromised build / dependency
→ malicious release
→ downstream victim installs / receives it
→ T1195 becomes relevant to the supply-chain path

Не каждый CI compromise автоматически надо называть T1195.

Product Security controls

Repository / SCM

protected branches;
mandatory review;
CODEOWNERS для pipeline и security-sensitive files;
phishing-resistant MFA;
short-lived authentication;
минимизация personal access tokens;
audit privileged changes.

CI/CD

protected pipeline definitions;
isolated / ephemeral runners;
least privilege CI identity;
separation build / deploy / signing authority;
secrets только на тех stages, где они реально нужны;
запрет untrusted PR на privileged runners;
контроль third-party actions/plugins;
immutable or tightly controlled runner images.

Artifact integrity

provenance;
SBOM;
signatures;
immutable artifact storage;
promotion одного и того же artifact между environments вместо повторной сборки;
reproducible/verifiable builds там, где это практически оправдано.

Release governance

independent approval для high-risk production changes;
audit trail;
rollback;
kill switch;
разделение прав на source, build, signing и deployment.

И здесь есть хороший принцип:

Valid signature подтверждает, что artifact прошёл через signing authority. Она не доказывает, что build process до подписания был trustworthy.

Поэтому supply-chain threat model должен смотреть на всю цепочку:

Source
  ↓
Build Configuration
  ↓
Dependencies
  ↓
Runner
  ↓
Artifact
  ↓
Signing
  ↓
Registry
  ↓
Deployment / Distribution

Как встроить ATT&CK в pentest, а не просто приклеить ID к отчёту

Pentest отлично интегрируется в такую модель, если перестать воспринимать его как PDF со списком findings. Для каждого high-risk finding я бы добавлял четыре вопроса:

Какое конкретное действие attacker теперь может выполнить?
Какой prerequisite нужен для следующего шага?
Какая ATT&CK technique описывает этот action, если такая техника действительно есть?
Какой control разрывает следующий шаг?

Пример:

Pentest finding / evidence	Attacker action	Возможный ATT&CK context	Product Security follow-up
RCE в public API	Exploits public service	T1190	Что доступно compromised process после exploitation?
SSRF с доступом к metadata	Queries metadata API	T1552.005	Можно ли получить credentials и какие у них permissions?
Получен cloud token	Uses valid cloud credentials	T1078.004	Какие resources реально доступны identity?
Excessive K8s RBAC	Creates new privileged workload	T1610	Admission policy остановит deployment?
Privileged container + host mount	Escapes to host	T1611	Какие host/node resources становятся доступны?
Изменяемый CI pipeline	Executes attacker-controlled build step	T1677	Может ли pipeline получить signing/deploy credentials?
Compromised dependency	Delivers manipulated dependency/software	T1195.001 / T1195.002 при соответствующем сценарии	Может ли malicious code дойти до downstream consumer?
Read access to object storage	Collects objects from cloud storage	T1530	Какие данные доступны и есть ли detection на массовое чтение?

Так pentest finding превращается в security engineering input, а не просто remediation ticket.

Что получает red team

Для red team ATT&CK mapping — привычная вещь, но Product Security добавляет другой фокус. Red team может проверить не только «можем ли мы выполнить technique», а какие product controls должны были остановить путь раньше.

Например:

T1190 — public application exploited
 ↓
Product control failed
 ↓
T1552.005 — metadata queried
 ↓
Cloud boundary failed
 ↓
T1078.004 — cloud identity used
 ↓
IAM boundary failed
 ↓
T1530 — storage data collected

После exercise обсуждение становится намного полезнее:

какой control отсутствовал;
какой существовал, но был bypassed;
какой сработал;
где detection появился слишком поздно;
где attack path остановился;
какой team владеет remediation.

Это уже не просто «red team дошёл до цели», а проверка многослойной security architecture продукта.

Threat modeling + ATT&CK

STRIDE и ATT&CK иногда пытаются противопоставлять. На мой взгляд, гораздо полезнее использовать их вместе. STRIDE помогает задавать design-time вопросы:

можно ли spoof identity;
можно ли tamper data;
есть ли repudiation problem;
возможен information disclosure;
можно ли вызвать denial of service;
возможна privilege escalation.

ATT&CK добавляет другой слой:

Как подобное поведение может выглядеть в реальном adversary operation?

Представим data flow:

User
 ↓
Web / Mobile
 ↓
API
 ↓
Identity Provider
 ↓
Backend
 ↓
Database
 ↓
Cloud Storage

После определения assets и trust boundaries я бы не открывал всю Enterprise Matrix и не шёл слева направо по каждой клетке. Лучше начать с attacker objectives и релевантных surfaces.

Для internet-facing SaaS могут быть полезны:

Initial Access;
Credential Access;
Discovery;
Persistence;
Collection;
Exfiltration;
Impact.

Для cloud-native продукта:

cloud account abuse;
metadata / credential access;
cloud discovery;
storage access;
cloud resource modification;
logging / defense impairment.

Для Kubernetes:

container execution/deployment;
cluster credentials;
container escape;
discovery;
lateral movement.

Для software factory:

Poisoned Pipeline Execution;
credential abuse;
dependency/development-tool compromise;
software supply-chain compromise.

ATT&CK становится не заменой threat model, а библиотекой attacker behavior, которая помогает расширить threat modeling session реальными post-exploitation сценариями.

От ATT&CK к controls: Mitigations и D3FEND

Есть ещё один полезный нюанс. ATT&CK содержит Enterprise Mitigations — классы defensive measures, способных снижать вероятность успешного выполнения techniques.

Но Product Security controls часто намного конкретнее:

deny hostPath;
require non-root;
pin GitHub Action to immutable commit;
block workload access to metadata;
require step-up auth for payout change;
separate signing identity from build identity.

Поэтому ATT&CK Mitigations можно использовать как reference, но не обязательно заставлять всю engineering control library жить внутри ATT&CK taxonomy. Если нужен именно defensive knowledge graph, можно дополнительно посмотреть на MITRE D3FEND, который ориентирован на cybersecurity countermeasures и связи defensive techniques с offensive behavior.

Практический подход может быть таким:

ATT&CK
What does the attacker do?

Product Security Controls / ASVS / Cloud & K8s Policies
What prevents it in our product?

D3FEND / ATT&CK Mitigations
What defensive patterns may complement the design?

От prevention к detection: не заканчиваем на fix

Product Security иногда слишком сильно уходит в shift-left. Shift-left полезен, но продукт после релиза не исчезает. Поэтому для critical attack path я бы всегда задавал два вопроса:

Как мы предотвращаем этот behavior?
Как мы поймём, что он происходит, если prevention обойдут?

Современная ATT&CK detection-модель хорошо поддерживает этот подход.

Например, для T1552.005 у MITRE есть Detection Strategy DET0001, ориентированная на обращения к cloud metadata endpoint, включая direct access и SSRF-related patterns. Это хороший пример связи design и telemetry.

Если metadata access является важным security boundary, Product Security может потребовать:

network telemetry для metadata requests;
workload identity context;
cloud audit logs;
correlation с необычным последующим API usage;
alerting для workload, который обычно metadata не запрашивает.

То же самое для Kubernetes:

privileged pod creation;
RBAC modifications;
неожиданные DaemonSets;
access к sensitive cluster resources.

И для CI/CD:

изменение pipeline definitions;
запуск workflow из необычного context;
доступ build job к signing secrets;
изменение trusted dependency/action;
anomalous artifact publication.

Так Product Security начинает влиять не только на secure code, но и на security observability продукта.

Простой шаблон для threat model / Jira / security backlog

Не обязательно строить отдельную дорогую платформу. Можно добавить несколько полей в существующий security backlog.

Например:

Asset: payments-api
Crown jewel: payout data
Trust boundary: Internet -> API

**Finding:** SSRF in webhook validation
Severity: High

Attacker action:**
  Query cloud instance metadata through SSRF

**ATT&CK:**
  validated:
    - T1552.005
  feasible_if_credentials_are_used:
    - T1078.004
  feasible_if_storage_is_reachable:
    - T1530

**Attack path:**
  SSRF -> metadata -> temporary credentials -> cloud storage

**Business impact:**
  Unauthorized access to payout/customer data

**Preventive controls:**
  - outbound destination allowlist
  - hardened metadata access
  - scoped workload identity
  - least privilege storage policy

**Validation:**
  - SSRF regression test
  - metadata reachability test
  - IAM effective-permission test
  - negative storage authorization test

**Detection:**
  - metadata access telemetry
  - unusual cloud API enumeration
  - abnormal storage reads

**Owner:** Payments Platform
Release status: Blocked until metadata/credential path is broken
Residual risk: Low after control validation

Обратите внимание на поля validated и feasible. Они помогают не превращать ATT&CK mapping в утверждение, будто вся цепочка уже была реально выполнена.

Как использовать ATT&CK Navigator в Product Security

ATT&CK Navigator удобен для визуализации coverage.

Но здесь есть ловушка. Очень легко получить красивую матрицу, в которой половина cells зелёная, четверть жёлтая, и никто не может объяснить, что именно означает цвет.

Я бы не начинал с вопроса:

Сколько процентов MITRE ATT&CK мы закрываем?

Для Product Security это почти всегда слишком абстрактно. Полезнее сделать несколько отдельных layers.

Layer 1 — Threat Relevance

Techniques, реально релевантные конкретному product architecture и threat model.

Layer 2 — Preventive Coverage

Где существует реальный preventive control.

Layer 3 — Validation Coverage

Какие controls проверены через:

pentest;
adversarial testing;
CI/CD tests;
cloud/Kubernetes assessment;
architecture review.

Layer 4 — Detection Coverage

Какие relevant techniques видны через production telemetry и detections.

Layer 5 — Known Gaps

Самый полезный слой.

Например:

Эти семь behaviors релевантны продукту, но для трёх у нас нет validated prevention, а для двух — detection. Вот это уже security roadmap.

ATT&CK как мост между AppSec, DevSecOps, Cloud и SOC

Одна из постоянных организационных проблем в security — разные команды говорят на разных языках.

AppSec:

SSRF in public service.

Cloud Security:

Workload role is overprivileged.

SOC:

Unexpected API enumeration from service identity.

DevOps:

Это обычный pod с access к AWS API.

Product Security может соединить их:

AppSec
SSRF in public service
        ↓
ATT&CK / Attack Path
T1552.005 -> T1078.004 -> discovery -> T1530
        ↓
Cloud Security
Metadata + IAM blast radius
        ↓
DevSecOps
Egress / workload identity / policy-as-code
        ↓
SOC / Detection
Metadata access + unusual cloud API activity

Теперь разные команды обсуждают один attack path, а не четыре независимых тикета. Для меня это одна из самых сильных сторон ATT&CK в Product Security.

Как встроить ATT&CK в Secure SDLC

Не надо добавлять отдельный двадцатистраничный процесс. Mapping можно встроить в существующие точки SDLC.

SDLC stage	Как использовать ATT&CK
Requirements	определить critical assets, abuse cases и adversary objectives
Architecture	связать attack paths с trust boundaries и security controls
Threat modeling	выбрать только релевантные techniques, а не всю matrix
Development	превратить controls в engineering requirements
CI/CD	проверить pipeline, identity и supply-chain paths
Pre-release	использовать mapping для targeted pentest/adversarial validation
Production	связать critical behaviors с telemetry и detections
Incident	вернуть observed TTPs обратно в threat model и backlog

Получается feedback loop:

Threat Model
    ↓
Engineering Controls
    ↓
Security Validation
    ↓
Production Telemetry
    ↓
Incidents / Threat Intelligence
    ↓
Updated Threat Model

Так ATT&CK становится живым инструментом, а не compliance-таблицей.

Минимальный вариант, с которого можно начать завтра

Если ATT&CK пока живёт только у SOC/red team, не надо запускать большой transformation project. Возьмите один critical product.

Шаг 1. Выберите crown jewels

Например:

customer data;
payment flow;
production deployment;
signing keys;
cloud control plane.

Шаг 2. Выберите 5–10 realistic attack paths

Не techniques. Именно paths.
Например:

Public API exploit
→ workload identity
→ cloud storage

или:

Developer account
→ CI pipeline
→ signing
→ production release

Шаг 3. Для каждого шага сформулируйте attacker action

Если action нельзя сформулировать — mapping ещё сырой.

Шаг 4. Добавьте ATT&CK только там, где есть точное соответствие

Не пытайтесь заполнить каждую строку.

Шаг 5. Для каждой relevant technique укажите

prerequisite;
preventive control;
validation method;
telemetry/detection;
owner.

Шаг 6. Проведите targeted security test

Не «пентест всего интернета», а проверку конкретного path.

Шаг 7. Зафиксируйте evidence

Например:

validated;
blocked;
detected;
not tested;
accepted risk.

Шаг 8. Обновляйте mapping после изменений

Триггеры:

major architecture change;
новый cloud service;
новая CI/CD platform;
material pentest finding;
incident;
значимое изменение threat intelligence.

Этого уже достаточно, чтобы ATT&CK начала приносить практическую пользу.

Какие метрики действительно полезны

% critical attack paths с validated preventive controls;
% critical attack paths с detection coverage;
% high-impact techniques с defined owner;
количество attack paths, где следующий шаг остаётся feasible после remediation;
количество release blockers по high-impact paths;
время от finding до validated control;
количество повторных findings, указывающих на один systematic control gap;
количество critical paths, проверенных adversarial testing;
coverage релевантных, а не всех существующих ATT&CK techniques.

Для Product Security lead/director это уже нормальный разговор о risk reduction, а не о раскрашивании framework.

Итог

MITRE ATT&CK не делает Product Security за нас. Она не заменяет:

secure architecture;
threat modeling;
OWASP ASVS;
code review;
SAST/SCA/DAST;
pentest;
cloud hardening;
Kubernetes security;
secure CI/CD;
detection engineering;
incident response.

Но она может связать эти дисциплины в одну понятную цепочку. Для меня главный смысл выглядит так:

Vulnerability говорит, где продукт слаб. ATT&CK помогает описать, что adversary делает с этой слабостью дальше. Product Security должен разорвать attack path — и уметь доказать, что он разорван.

Поэтому вместо вопроса:

На какую технику MITRE замэппить этот finding?

я бы задавал другой:

Какое конкретное действие attacker выполняет, какой следующий шаг оно открывает и на каком этапе мы этот путь предотвращаем, проверяем и детектируем?

Тогда ATT&CK перестаёт быть матрицей «для SOC и red team» и становится вполне практичным инструментом Product Security.

Полезные источники

Как я учусь сложным вещам: практическая система для памяти, фокуса и самообучения в CyberSec

Ivan's Cybersecurity Notes — Sun, 27 Sep 2026 22:00:00 +0000

Preview

Хей, парни! на связи Иван | White2Hack

И так, кто не знает несколько лет назад, а точнее в 2023 году я собрал большую брошюру про обучение и самообучение. Получилось больше ста страниц: память, внимание, нейропластичность, интервальные повторения, мнемотехники, скорочтение, Pomodoro, мотивация, приоритизация и ещё куча всего. За это время я продолжал преподавать, читать курсы, готовиться к сертификациям, учить языки, осваивать новые security-технологии и собирать свои собственные лаборатории. И постепенно понял неприятную вещь: знать много техник обучения — ещё не значит хорошо учиться.

Можно идеально знать, что такое spaced repetition, завести пять приложений для заметок, купить три курса по Kubernetes — и через месяц всё равно не суметь с нуля объяснить, как работает NetworkPolicy.

Я видел похожую картину и у студентов. Пока слайд открыт — всё понятно. Убираешь слайд и просишь объяснить своими словами — начинается самое интересное. Поэтому сейчас я смотрю на обучение гораздо приземлённее. Мне нужен не красивый процесс. Мне нужен результат, который можно проверить.

Не “я изучил тему”, а “я могу что-то сделать без подсказки”.

Ниже, в этом материале — система, которую я сегодня использую для себя. Она подходит не только для IT\CyberSec: тем же способом я учу английский, читаю технические книги, разбираю видео, готовлюсь к интервью и вхожу в новые области Product Security / AppSec / DevSecOps.

Сразу оговорюсь: здесь не будет обещаний «выучить всё за 20 часов» или магического расписания повторений. В моей старой работе такие формулировки местами были слишком смелыми. Сейчас я бы их не повторял. И, так выдаю базу!

Главный сдвиг: учить не тему, а действие

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

Плохо:

выучить API Security;
подтянуть английский;
разобраться с AWS;
посмотреть курс по DevSecOps.

Намного лучше:

найти Broken Object Level Authorization в тестовом API, показать exploit path и предложить remediation;
за 10 минут рассказать на английском о своём проекте и ответить на follow-up questions;
построить threat model небольшого сервиса;
добавить SAST (Static Application Security Testing) и SCA (Software Composition Analysis) в pipeline, намеренно сломать gate, понять причину и настроить policy;
прочитать главу и через день восстановить её основные идеи без книги.

Это, кстати, хорошо совпадает с тем, как профессиональные cybersecurity frameworks описывают работу: через tasks, knowledge and skills, а не через абстрактное «знаком с безопасностью».

Для себя я называю это performance-first learning.

Тема	Слабая цель	Проверяемая цель
English	Improve speaking	Провести 20-минутное mock interview без русского
Pentest	Learn web pentesting	Найти и воспроизвести 3 класса уязвимостей в lab
AppSec	Learn threat modeling	Сделать threat model сервиса и защитить решения перед инженером
DevSecOps	Learn CI/CD security	Настроить security gate и обработать FP/exception
Книга	Прочитать 300 страниц	Через неделю объяснить 10 ключевых идей и применить 2 из них
Видео	Посмотреть курс	Воспроизвести показанное без видео и решить похожую задачу

Если цель невозможно проверить, обучение очень легко превращается в потребление контента.

Мой learning loop или как Я сам это делаю

Сегодня мой базовый цикл выглядит примерно так:

Результат, который хочу получить
        ↓
Карта предмета
        ↓
Один хороший пример
        ↓
Объяснить пример самому себе
        ↓
Закрыть источник и вспомнить
        ↓
Сделать самому
        ↓
Получить обратную связь
        ↓
Вернуться через интервал
        ↓
Решить похожую, но уже новую задачу
        ↓
Объяснить другому человеку

Мне нравится эта схема тем, что в ней почти невозможно спрятаться за фразой «я вроде понял». Либо сделал, либо нет.

1. Я больше не начинаю с первой страницы

Открыть книгу на Chapter 1 и дисциплинированно идти до Chapter 27 выглядит правильным. Иногда так и надо. Но при ограниченном времени это часто плохая стратегия входа в новую область.

Сначала я хочу увидеть карту.

Если это книга — смотрю оглавление, введение, summary, заголовки, основные термины. Если это технология — architecture overview, glossary, quick start, типичный workflow. Если это security — assets, trust boundaries, attack surface, identities, data flows, controls, telemetry. Если это английский — не «все времена английского языка», а конкретные ситуации: meeting, email, interview, объяснение finding, disagreement, clarification.

Это тот случай, когда старый принцип 80/20 для меня всё ещё полезен — не как математический закон, а как вопрос:

Какие несколько понятий дадут мне возможность понимать остальные?

Например, прежде чем читать сто страниц про OAuth/OIDC, полезно понять участников протокола, tokens, redirect flow и trust relationships. После этого детали перестают быть набором терминов.

В моей старой брошюре была формулировка: новая информация легче «цепляется» за уже существующий скелет знаний. Сейчас я бы сказал проще: сначала построи систему координат, потом добавляй детали.

2. Новичку не всегда полезно сразу бросаться в задачу. Сначала посмотри один хороший worked example

В IT популярен совет: «не читай — просто делай». В нём есть правда, но для совсем новой области он иногда превращается в другое: человек два часа хаотично тыкается, копирует команды из Stack Overflow и вообще не понимает, почему что-то заработало.

Для нового типа задач мне больше нравится такой порядок:

посмотреть один качественный решённый пример;
на каждом существенном шаге спросить себя: почему автор сделал именно это?;
закрыть пример;
повторить самостоятельно;
потом изменить условия задачи.

Исследования worked examples и self-explanation давно показывают, что для раннего этапа освоения сложных когнитивных навыков это может быть эффективнее, чем сразу бросать новичка в полностью самостоятельное problem solving.

В security это выглядит очень естественно. Допустим, я впервые разбираю SSRF (Server-Side Request Forgery). Не просто смотрю готовый exploit, а проговариваю:

Почему этот input controllable?
Почему backend делает server-side request?
Какая trust boundary пересекается?
Что именно доступно из internal network?
Как отличить реальный SSRF от красивого payload, который ничего не даёт?
Какой control устранит root cause, а какой только усложнит эксплуатацию?

Вот в этот момент чужой walkthrough превращается в мою модель.

3. Перечитывание даёт ощущение знания. Retrieval показывает правду

Это, пожалуй, самый ценный инструмент во всей статье. Схема, на которой я сам много раз ловился:

прочитал → понятно → перечитал → ещё понятнее → закрыл → ничего не помню

Знакомость материала очень легко спутать со знанием. Поэтому после небольшого блока я закрываю источник и пытаюсь извлечь материал из памяти.

Не посмотреть правильный ответ ещё раз. Сначала именно вспомнить.
**
После OAuth/OIDC** — нарисовать flow с пустого листа.
После Kubernetes — написать manifest без copy-paste.
После видео по Burp Suite — повторить последовательность действий самому.
После английского — сказать фразу вслух до того, как открыл карточку.
После главы книги — записать 5–7 тезисов по памяти.

Retrieval practice хорошо поддерживается исследованиями обучения и, что для меня важнее, прекрасно работает как диагностика. Если я не могу восстановить идею — значит, проблема обнаружена сейчас, а не на интервью или в production.

Мой простой тест понимания

После любой темы я задаю себе три вопроса:

1. Могу ли я объяснить это без источника?
2. Могу ли я сделать это без пошагового гайда?
3. Узнаю ли я эту же идею в другом контексте?

Первый проверяет память.
Второй — навык.
Третий — transfer.
Вот третий обычно самый неприятный :)

4. Spacing: возвращаться к материалу полезнее, чем пытаться «вбить» его за один вечер

В версии 2023 года я много писал про кривую Эббингауза и давал довольно конкретные интервалы повторений. Сегодня я бы оставил принцип, но убрал магию вокруг цифр.

Распределённая практика работает. Универсального идеального расписания для любого человека и любого материала — нет. Для новой темы я могу начать примерно так:

Этап	Примерный момент
Первый контакт	День 0
Recall без подсказки	В тот же день
Короткая проверка	День 1
Ещё одно извлечение	День 3–4
Практика в новой задаче	День 7
Проверка сохранности	Через 2–4 недели

Но это не календарь религиозных праздников. Если вспоминаю легко — увеличиваю интервал. Если всё развалилось — возвращаюсь раньше.

Для языка это удобно отдавать Anki или другой системе интервальных повторений (SRS). Для технических навыков карточки нужны далеко не всегда. Иногда лучший spaced repetition для AppSec — через неделю получить другую уязвимую API и снова пройти путь identify → exploit → impact → remediation → retest.

5. Для security я использую цикл «увидел → сломал → починил → объяснил»

Вот здесь generic learning advice обычно заканчивается, а мне как раз становится интересно. *Cybersecurity плохо учится только чтением. *Систематический обзор университетских cybersecurity courses показывает устойчивый акцент на active learning, case studies, simulations, virtual labs и project-based assessment. NIST NICE Framework тоже описывает развитие специалиста через реальные work roles, tasks, knowledge и skills; вокруг него существуют challenge-based и hands-on training environments.

На практике я стараюсь превращать тему в цикл:

Observe
  ↓
Reproduce
  ↓
Break / Attack
  ↓
Fix / Mitigate
  ↓
Retest
  ↓
Explain the risk

Penetration Testing

Если тема — IDOR/BOLA, мне мало определения из OWASP.

Я хочу:

увидеть нормальный request;
понять identity/authorization context;
изменить identifier;
воспроизвести unauthorized access;
доказать impact;
предложить server-side control;
проверить fix другим пользователем/tenant.

Тогда vulnerability перестаёт быть карточкой с термином.

Product Security / AppSec

Для каждого класса проблем полезно собрать небольшой mental template:

Asset
→ Entry point
→ Trust boundary
→ Preconditions
→ Abuse / attack path
→ Business impact
→ Control
→ Validation

После десятка реальных разборов ты начинаешь узнавать структуру проблемы раньше, чем вспоминаешь номер или название CWE-класса.

DevSecOps

Здесь я вообще считаю лабораторию обязательной.

Не «я посмотрел, как работает SAST», а:

добавил scanner в pipeline;
положил в код заведомую проблему;
увидел finding;
настроил gate;
поймал false positive;
сделал exception с понятным сроком и owner;
проверил, что pipeline не превратился в генератор ненависти разработчиков к Security.

Последний пункт часто важнее первых шести.

6. Английский я тоже перестал учить как «предмет»

С иностранным языком особенно легко коллекционировать знания вместо навыка. Можно знать Present Perfect, иметь 8 000 карточек и всё равно зависнуть, когда на митинге тебя внезапно спрашивают:

What exactly is blocking the release?

Поэтому мой подход к языку сейчас сценарный. Не учу слово отдельно, если могу выучить рабочий chunk:

clarify
→ Could you clarify what you mean by ...?
concern
→ My main concern is ...
blocked
→ I'm currently blocked by ...
recommend
→ I'd recommend validating this before release.

Исследования L2 vocabulary показывают, что простое массовое повторение слабее, чем сочетание repetition с retrieval, spacing и semantic elaboration. Исследования corrective feedback также в целом поддерживают пользу обратной связи при освоении второго языка.

Но мне важна практическая часть: слово должно начать жить в речи.

Мой короткий цикл для Technical English

INPUT
услышал / прочитал 5–10 полезных конструкций
RETRIEVAL
закрыл список и попытался вспомнить
OUTPUT
сказал их своими словами в другом контексте
FEEDBACK
проверил формулировку / получил correction
REUSE
использовал через день в новом сценарии

Например, вместо 40 минут vocabulary list я могу 20 минут разыгрывать один сценарий:

SAST нашёл authorization issue перед релизом. Объясни разработчику finding, impact и next step на английском.

Там одновременно тренируются vocabulary, grammar, pronunciation, security thinking и способность не превращать разговор в набор заученных фраз. Если язык нужен для работы — и практика должна быть похожа на работу.

7. Как я теперь смотрю обучающие видео

YouTube очень хорошо умеет создавать ощущение продуктивности. Полтора часа прошло, progress bar дошёл до конца — мозг доволен. А что осталось?

Видео я стараюсь смотреть с остановками по смысловым кускам, а не как сериал. Это хорошо согласуется с исследованиями multimedia learning: learner-paced segmentation снижает перегрузку на сложном материале, а более свежий meta-analysis по video learning показывает преимущества active learning strategies для retention, comprehension и transfer.

Мой режим простой:

10–20 минут видео
↓
PAUSE
↓
3–5 тезисов по памяти
↓
один вопрос: «что здесь было непонятно?»
↓
повторить показанное самому
↓
только потом следующий кусок

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

Скорость 1.5x? Иногда отлично для знакомой темы или review. Для нового плотного материала я лучше посмотрю медленнее и один раз нормально пойму причинно-следственную связь.

Скорость плеера — плохая метрика скорости обучения.

8. Как я читаю технические книги и большие документы

Здесь я разделяю два режима.

Triage reading

Мне нужно понять:

стоит ли материал моего времени;
где лежат нужные куски;
как устроена тема;
что читать глубоко.

Тогда я быстро прохожу:

TOC → intro → headings → diagrams → summary/conclusion → нужные разделы.

Deep reading

Если раздел реально нужен, скорость перестаёт быть целью. Я читаю небольшой кусок и превращаю его в вопросы:

Почему это работает?
При каких условиях перестанет работать?
Как это выглядит в реальной системе?
Что здесь можно перепутать?
Как я это проверю в lab?

Для сложных тем полезен self-explanation: не просто повторить предложение автора, а связать его с уже известными принципами и объяснить самому себе, почему следующий шаг следует из предыдущего.

Это гораздо медленнее, чем «прочитать 100 страниц за вечер». Зато через неделю есть что вспомнить.

9. Я перестал коллекционировать информацию. Теперь я её сжимаю

Ещё одна ловушка самообучения — бесконечная агрегация.
50 bookmarks.
17 YouTube playlists.
Три Notion workspace.
Папка READ_LATER_FINAL_v2.

И прекрасное чувство, что знания почти принадлежат тебе :) Сейчас для темы я стараюсь иметь одну рабочую точку сборки. Не обязательно красивую.

Мой минимальный шаблон заметки:

# Тема

**Зачем мне это?**
## 5–10 core concepts
## Что я пока не понимаю
## Как это проверить руками
## Ошибки / failure modes
## Что я могу объяснить без источника
## Ссылки на 2–5 действительно хороших источников

После каждого нового источника я не копирую всё подряд, а спрашиваю:

Что в моей модели изменилось?

Если ничего — возможно, источник мне больше не нужен. Это особенно полезно в Product Security, где один и тот же тезис можно встретить в OWASP, NIST, vendor documentation, блоге, conference talk и пяти Medium-постах. Пять ссылок не обязательно означают пять новых знаний.

10. Фокус: я не пытаюсь выиграть у уведомлений силой воли

В старой брошюре у меня был раздел Multitasking VS Focus и отдельный «метод трёх часов без шума».

Сейчас я сохранил идею, но перестал поклоняться цифре «три часа». Для сложного learning block мне нужны:

одна задача
+ один контекст
+ выключенные уведомления
+ заранее понятный output

Иногда это 25 минут. Иногда 50. Иногда полтора часа, если пошла нормальная глубокая работа.

Task switching имеет реальную cognitive cost. Мне не нужно знать точное число потерянных процентов, чтобы заметить очевидное: после Slack → документация → Telegram → lab → почта я каждый раз заново собираю контекст в голове.

Pomodoro

Использую, когда не хочется начинать.

25/5 — отличный starter motor.

Но если я вошёл в сложную лабораторию и на 25-й минуте наконец понял, где ошибка в policy, таймер не имеет права командовать мной только потому, что он помидор.

11. Прокрастинация часто исчезает, когда следующий шаг становится смешно маленьким

«Выучить Kubernetes» — прекрасная задача, если хочется ничего не делать. Она огромная, бесформенная и без точки входа.

А вот:

«Запустить cluster и создать namespace»
— уже почти не страшно.

Мне хорошо работает связка из двух вещей.

1. Уменьшить первый шаг

Не «сегодня два часа английского», а «записать 90 секунд self-introduction». Не «готовиться к OSCP целиком», а «поднять одну penetration-testing машину и сделать initial enumeration». Не «разобраться с Terraform», а «создать один resource и уничтожить его».

2. Заранее решить, когда это произойдёт

Implementation intentions — обычная конструкция если → то.

Если я закончил утренний кофе и открыл ноутбук,
то первые 25 минут работаю над lab до Slack и почты.

Это намного полезнее, чем ежедневное внутреннее собрание совета директоров на тему «есть ли у меня сегодня мотивация?».

12. Сомнение и страх я тоже считаю частью learning loop

Есть забавный момент: чем дольше мы готовимся, тем легче назвать подготовку «обучением» и не проверять себя в реальности. Особенно это видно в двух областях.

Иностранный язык

«Сначала я подтяну grammar, потом начну говорить». Через год grammar стала лучше. Говорить всё ещё страшно.

Security

«Сначала дочитаю весь курс, потом пойду в lab». Курс закончен. Перед пустым terminal всё равно тишина. Для себя я ввёл неофициальное правило minimum viable embarrassment.

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

записать себя на английском и услышать собственные ошибки;
ответить на interview question без конспекта;
попробовать exploit и увидеть, что гипотеза была неверной;
показать threat model человеку, который найдёт в нём дыру;
написать первый плохой скрипт вместо чтения пятой книги про Python.

Это не самоистязание. Это быстрая обратная связь. Ошибку, которую ты увидел сегодня, не придётся торжественно обнаруживать через шесть месяцев.

13. «Крепкая четвёрка» — мой любимый антидот от перфекционизма

Эту идею из своей старой брошюры я оставляю почти без изменений.
Есть работа «на тройку» — лишь бы отстали.
Есть отличная работа «на пятёрку».
А есть пятёрка-перевёртыш: перфекционизм, который мешает результату вообще появиться.

Человек две недели проектирует идеальный learning plan. Полирует CV вместо отправки applications. Учится писать идеально правильный English sentence и поэтому молчит на встрече. Читает про программирование вместо первого кривого скрипта.

Я предпочитаю крепкую четвёрку:

Сделать достаточно хорошо, получить реальную обратную связь и улучшить следующую итерацию.

В обучении версия 0.1, которую можно проверить, почти всегда полезнее версии 1.0, которая существует только в голове.

14. Не мотивация, а короткий цикл и scoreboard

Мотивация хороша. Просто она не подписывала SLA. Сегодня есть, завтра нет. Поэтому большие цели я режу на циклы примерно по 6–12 недель и заранее решаю, какой observable result должен появиться.

Не:

«улучшить английский».

А:

«через восемь недель пройти 30-минутное mock interview без русского и без заранее написанного текста».

Не:

«изучить AWS Security».

А:

«собрать lab с несколькими attack paths, настроить detection и объяснить архитектуру без слайдов».

Каждую неделю я смотрю не на часы, а на output. Что появилось?

Lab? Threat model? Write-up? Recorded answer? Working pipeline? Решённая задача? Если я десять часов «учился», но ничего из этого не появилось, я не считаю неделю особенно успешной.

Если мне нужно быстро освоить новый security skill

Вот универсальный двухнедельный шаблон, который я бы использовал сегодня.

День	Работа	Проверяемый результат
0	Формулирую конечное действие	Знаю, что должен уметь сделать
1	Строю карту темы	10–15 core concepts + неизвестные слова
2	Разбираю 1–2 хороших worked examples	Могу объяснить каждый шаг
3	Повторяю пример без подсказки	Первый самостоятельный результат
4	Делаю простую лабораторию	Working scenario
5	Закрываю источники и восстанавливаю тему	Список реальных пробелов
6	Исправляю пробелы	Короткая обновлённая карта
7	Беру другую задачу того же класса	Первый перенос навыка (transfer)
8	Пауза + recall	Проверка retention
9	Усложняю условия	Failure / attack scenario
10	Добавляю mitigation	Fix + retest
11	Объясняю тему вслух	5–10 минут без конспекта
12	Решаю задачу без walkthrough	Blind practice
13	Сам себе экзамен	Questions + troubleshooting
14	Делаю итоговый артефакт	Lab / write-up / demo / checklist

Смысл не в том, что любую профессию можно выучить за 14 дней. Смысл в том, что через две недели у тебя должен быть работающий первый слой навыка, а не только история браузера.

Если мне нужно быстрее подтянуть Technical English

Здесь цикл немного другой. Я бы выбрал одну рабочую ситуацию на неделю.

Например: security interview.

День 1 — собрать 10–15 ключевых phrases/chunks
День 2 — recall + 5 коротких ответов вслух
День 3 — 15 минут mock interview
День 4 — разобрать ошибки и переформулировать ответы
День 5 — новый mock без старого текста
День 6 — listening: интервью/митинг кусками + пересказ
День 7 — 20–30 минут разговора без конспекта

Следующая неделя — meetings.
Потом explaining findings.
Потом disagreement / risk discussion.

Так язык постепенно собирается вокруг реальных задач, а не вокруг ощущения «я когда-нибудь закончу учебник».

Что я бы сегодня выкинул из типичного learning advice

За годы вокруг обучения накопилось слишком много красивых правил. Часть из них полезна как метафора, но плохо выдерживает слово «доказано».

Вот что я больше не использую как жёсткую истину:

«Пирамида обучения» с точными процентами

Знаменитые 10% читаем / 20% слышим / 90% делаем часто приписывают Edgar Dale. У этих цифр нет той научной основы, которую им обычно приписывают. Практика действительно важна. Но проценты лучше оставить мотивационным плакатам.

«20 часов — и навык освоен»

20 часов хорошей практики могут дать очень заметный старт. Но сложность навыков различается на порядки. 20 hours — полезный антидот от страха перед стартом, а не гарантия компетентности. Но тоже база. Хотя бы с нее стартануть.

«10 000 часов — и ты эксперт»

Тоже не закон природы. Важны качество практики, feedback, стартовый уровень, область и куча других факторов. Но в целом общйи каркас 10к часов верен.

«Концентрация всегда заканчивается ровно через 25 минут»

Нет. Pomodoro — инструмент организации работы, а не таймер человеческой биологии.

«Есть идеальные интервалы повторения для всех»

Spacing полезен. Конкретная сетка зависит от задачи, человека и требуемого retention interval.

«Скорочтение позволит читать в 3–5 раз быстрее без потери понимания»

Для поиска и triage — можно читать очень быстро.

Для глубокого понимания сложного материала скорость и comprehension приходится балансировать. И это нормально, мен.

Быстрая диагностика: что сломалось в обучении?

Симптом	Что проверить первым
Через неделю ничего не помню	Retrieval + spacing
Всё понимаю только пока открыт конспект	Recall без подсказки
Посмотрел пять курсов, навык не появился	Практика без walkthrough
Не знаю, с чего начать новую тему	Performance goal + карта предмета
Lab кажется слишком сложным	Один worked example → self-explanation → повтор
Тону в источниках	Один canonical note + 2–5 основных sources
Постоянно отвлекаюсь	Single-task block + notifications off
Не могу начать	Первый шаг на 5–25 минут + `если → то`
Боюсь говорить по-английски	Короткий output + correction + повтор
Боюсь technical interview	Ответ вслух без конспекта + запись
Хочу знать всё до практики	Minimum viable embarrassment
Всё полирую и не выпускаю	«Крепкая четвёрка»

И ещё одна вещь, которую преподавание научило меня ценить

Когда человек может объяснить сложную вещь другому человеку, очень быстро становится видно, где у него понимание, а где набор знакомых слов. Поэтому финальным тестом я часто делаю не quiz, а объяснение.

Попробуй без конспекта рассказать:

почему эта vulnerability возникает;
какой trust boundary нарушен;
почему mitigation реально работает;
чем severity отличается от business priority;
почему именно эта фраза на английском звучит естественнее;
что было главным в прочитанной главе.

Если в объяснении приходится прыгать через логические дыры — отлично. Ты только что бесплатно нашёл следующую тему для обучения.

Итог

После многих лет преподавания и собственного самообучения я всё меньше верю в «секретные техники сверхобучения» и всё больше — в хорошо собранный процесс.

Мне не нужно поглотить максимум информации.

Мне нужно:

понять, что я должен уметь → быстро построить карту → увидеть хороший пример → попробовать вспомнить → сделать самому → получить feedback → вернуться позже → применить в другом контексте.

И повторить цикл.

Самая опасная иллюзия — принять знакомство с материалом за владение им.

Поэтому моя главная метрика сегодня очень простая:

Не сколько я посмотрел и прочитал, а что я теперь могу воспроизвести, сделать и объяснить без подсказки.

Если эта цифра растёт — обучение работает.

Всё остальное вторично.

Источники и что я перепроверил для этой версии (статьи)

Основа статьи — моя self-published брошюра «(Само)обучение: исследования, факты и лучшие практики» (2023) и собственный опыт преподавания, профессионального обучения и самообучения. Для этой версии я отдельно перепроверил ключевые тезисы по исследованиям и профильным материалам. И дабы все могли проверить материалы на которые я опирался при написании материала, ниже вот основная исследовательская база:

Carpenter S. K., Pan S. C., Butler A. C. The science of effective learning with spacing and retrieval practice. Nature Reviews Psychology, 2022. https://doi.org/10.1038/s44159-022-00089-1
Agarwal P. K., Nunes L. D., Blunt J. R. Retrieval Practice Consistently Benefits Student Learning: a Systematic Review of Applied Research in Schools and Classrooms. Educational Psychology Review, 2021. https://doi.org/10.1007/s10648-021-09595-9
Kim S. K., Webb S. The Effects of Spaced Practice on Second Language Learning: A Meta-Analysis. Language Learning, 2022. https://doi.org/10.1111/lang.12479
Barcroft J. et al. A Review of Laboratory Studies of Adult Second Language Vocabulary Training. Studies in Second Language Acquisition, 2020. https://doi.org/10.1017/S0272263119000500
Li S. The Effectiveness of Corrective Feedback in SLA: A Meta-Analysis. Language Learning, 2010. https://doi.org/10.1111/j.1467-9922.2010.00561.x
Chi M. T. H. et al. Self-explanations: How students study and use examples in learning to solve problems. Cognitive Science, 1989. https://doi.org/10.1016/0364-0213(89)90002-5
Mayer R. E. Using multimedia for e-learning. Journal of Computer Assisted Learning, 2017. https://doi.org/10.1111/jcal.12197
Zhang Y. et al. Active learning strategies in video learning: A meta-analysis. Educational Research Review, 2025. https://doi.org/10.1016/j.edurev.2025.100708
How universities teach cybersecurity courses online: a systematic literature review. Frontiers in Computer Science, 2024. https://doi.org/10.3389/fcomp.2024.1499490
Tang C. et al. Introducing Penetration Test with Case Study and Course Project in Cybersecurity Education. Journal of The Colloquium for Information Systems Security Education. https://journal.cisse.info/index.php/jcisse/article/view/148
NIST. NICE Framework Resource Center — Education and Training Provider Resources. https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center/resources/education-and-training
Rayner K. et al. So Much to Read, So Little Time: How Do We Read, and Can Speed Reading Help? Psychological Science in the Public Interest, 2016. https://doi.org/10.1177/1529100615623267
Gollwitzer P. M., Sheeran P. Implementation Intentions and Goal Achievement: A Meta-analysis of Effects and Processes. Advances in Experimental Social Psychology, 2006. https://doi.org/10.1016/S0065-2601(06)38002-1

Product Security Fast Track: готовлю практическую брошюру для инженеров, которые хотят двигаться дальше

Ivan's Cybersecurity Notes — Mon, 21 Sep 2026 05:00:00 +0000

Последние годы я собирал собственную систему подготовки по Application Security, DevSecOps и Product Security: рабочие заметки, реальные кейсы, вопросы с интервью, архитектурные сценарии, ошибки, метрики и подходы, которые действительно приходилось использовать на практике.

В какой-то момент понял, что из этого уже получается не очередной набор заметок, а вполне самостоятельное пособие. Так появился Product Security Fast Track — практическая брошюра для тех, кто хочет систематизировать знания, подготовиться к техническим интервью и постепенно перейти от отдельных инженерных задач к более целостному мышлению Product Security Engineer / Lead.

Брошюра скоро появится в продаже.

Что внутри

Я специально строил материал не вокруг списка модных инструментов, а вокруг жизненного цикла продукта и вопроса: как сделать продукт безопаснее от идеи и архитектуры до production — и как добиться того, чтобы найденный риск действительно был устранён?

Теоретическая база

Поэтому внутри есть фундамент Product Security, Secure SDLC и DevSecOps, Threat Modeling, SAST/SCA/DAST/IAST, vulnerability management, API Security, identity и authorization, software supply chain, CI/CD security, Cloud, IaC, containers, Kubernetes, PSIRT и security program management. Отдельно рассматриваются современные Web/API-атаки, архитектурные сценарии и risk-based подходы вроде CVSS, EPSS, KEV, VEX, ASPM/CNAPP, SSDF и SAMM.

Но основная ценность для меня не в количестве терминов. Я сделал материал, который помогает объяснять и применять знания, а не просто помнить определения.

Например, если на интервью спрашивают про security review нового продукта, задача не в том, чтобы быстрее назвать SAST. Сначала нужно увидеть assets, trust boundaries, privileged paths, attack surface и business context — а уже затем выбирать controls и tooling. Именно такое мышление я стараюсь тренировать на протяжении всей брошюры.

Практика вместо энциклопедии

Внутри есть технические и архитектурные кейсы, whiteboard-сценарии, insecure configurations, CI/CD, Kubernetes, API, AWS/Azure-задачи и большой набор сложных вопросов для интервью.

Для части вопросов есть короткий ответ на 30–60 секунд, затем более глубокий разбор и follow-up questions. Идея простая: не заучивать текст, а учиться думать и объяснять решение вслух.

Отдельный блок посвящён уровню Senior / Lead / Director.

Там разговор уже не только о том, какой control использовать, но и о том, как встроить его в engineering workflow, назначить ownership, определить SLA, измерить эффективность и не превратить Security в бесконечную фабрику findings.

Как показать результат своей работы

Мне хотелось отдельно закрыть проблему, которую я постоянно вижу у сильных инженеров: человек сделал много полезного, но на интервью рассказывает об этом как о списке действий.

«Настроил SAST. Внедрил DevSecOps. Работал с Kubernetes.»

Для senior-level позиции этого мало. Нужно уметь показать:

problem → decision → action → measurable outcome → business/security impact.

Поэтому в брошюре есть работа с метриками, результатами и STAR stories: как превратить технический опыт в понятный рассказ для интервьюера и показать не только activity, но и реальный outcome. Сам документ отдельно делает акцент на measurable results и business value как на сильном differentiator кандидата.

Английский для реального технического интервью

Ещё один отдельный слой — American English для Product Security interviews. Не учебниковый английский, а формулировки, которыми удобно:

структурировать технический ответ;
объяснять trade-offs;
корректно спорить с premise интервьюера;
говорить о risk и residual risk;
объяснять архитектурное решение;
описывать incident или failure;
отвечать на follow-up;
презентовать собственный результат без ненужного пафоса.

В расширенной interview-части есть отдельные English answer templates, а STAR-кейсы также переводятся в формат, пригодный для behavioural interview.

Онбординг после оффера и первые 100 дней работы

И это не заканчивается получением offer. Я намеренно добавил ещё один блок, которого обычно нет в материалах «как пройти интервью»:

что делать, если интервью уже пройдено и вы получили роль.

Внутри есть Product Security operating approach и подробная логика 30/60/90 Days — от discovery и поиска реальных P0/P1 рисков до operating model, roadmap, metrics, champions, budget и executive reporting.

Потому что конечная цель всё-таки не научиться красиво отвечать на вопросы. Цель — уметь выполнять эту работу.

Для кого брошюра

Product Security Fast Track я делаю прежде всего для AppSec / DevSecOps / Security Engineers, которые хотят систематизировать фундамент, подготовиться к серьёзным Product Security интервью и со временем двигаться от выполнения отдельных технических задач к архитектурному и leadership-мышлению.

Внутри будет необходимая теория, но основной фокус — практические модели мышления, реальные сценарии, интервью, кейсы и применение знаний.

Скоро расскажу подробнее о формате, содержании и публикации. Следи за лентой White2Hack канала и других официальных ресурсах.

Автор: Ivan Piskunov
White2Hack

"Почем безопасность?" Или о том как складывается цена на услуги ИБ в Product Security

Ivan's Cybersecurity Notes — Fri, 18 Sep 2026 17:56:16 +0000

Прозрачное ценообразование в кибербезопасности, стоимость senior-экспертизы и экономика честного коммерческого предложения

Коммерческое предложение по безопасности часто выглядит как одно число.

К примеру, сумма в разделе "Прайс" на сайте или презентации\визитки. Это, может быть $4,500 или $12,000, а то и $25,000, а так же почасовка как $150 в час или $8,000 в месяц и т.д.

Для клиента возникает вполне нормальный вопрос: из чего именно получилась эта сумма? На этот вопрос должен существовать более содержательный ответ, чем "такой рынок", "это premium expertise" или "безопасность просто дорого стоит". Хм... разберемся в этой теме.

Хорошая цена должна выдерживать декомпозицию. Должно быть понятно, что именно входит в работу, какие роли нужны для delivery, сколько инженерного времени требует scope, какие инструменты и инфраструктура используются, сколько времени уходит на координацию, QA и подготовку результата, какие assumptions заложены в оценку и какие изменения действительно могут изменить итоговую стоимость.

Именно на этом принципе я строю коммерческую модель Bulwark Advisory.

Честная цена в Security - это не минимальная цена. Это цена, которую можно объяснить, разложить, проверить и связать с конкретным результатом. Работа (услуга) стоит своих денег когда это подкреплено фактами

Эта статья о том, как такой подход работает на практике, почему высокий hourly rate senior-специалиста не обязательно означает дорогой результат, почему зарплату сотрудника нельзя напрямую сравнивать с consulting rate и в каких случаях консалтинг вообще оказывается неправильной экономической моделью. Цель материала не в том, чтобы оправдать "дорогую" безопасность, высокий прайс. Цель в том, чтобы сделать экономику Security достаточно прозрачной для нормального бизнес-решения. Ну, а уже адекватные люди (собственники бизнеса, заказчики) сами выберут что ом по душе и по карману.

1. Cost, rate, price и value - это четыре разных понятия

Разговор о цене быстро становится бессмысленным, если смешивать четыре разные сущности. Рассмотрим их подробнее.

Cost - реальная себестоимость выполнения работы. Сюда входят труд, benefits или contractor cost, non-billable time, tooling, инфраструктура, страхование, административные расходы, presale, QA и delivery risk.
Rate - коммерческая единица стоимости времени. Часовая или дневная ставка удобна для расчета, но сама по себе она еще не является итоговой ценой проекта.
Price - сумма, которую клиент согласовал за конкретный engagement. Если scope зафиксирован, fixed price не должен расти только потому, что исполнитель ошибся в собственной оценке трудозатрат.
Value - экономический эффект результата. Это может быть снижение риска, высвобождение времени engineering-команды, снятие blocker для enterprise-сделки, сокращение release delay, отказ от дублирующего tooling, закрытие критического attack path или снижение управленческой неопределенности.

Зрелая коммерческая модель учитывает все четыре уровня. Слабая модель смотрит только на hourly rate. Нечестная модель скрывает scope. Убыточная модель считает только часы инженера и забывает обо всем, что делает delivery профессиональным. Value-blind подход предполагает, что самый дорогой вариант автоматически лучший. И все четыре ошибки одинаково опасны.

2. Базовая формула ценообразования

Большинство Security-услуг можно разложить до достаточно простой операционной модели.

Expected Effort
= Σ(Task Units × Hours per Unit × Complexity Factor)

Затем:

Labor Component
= Σ(Role Hours × Commercial Role Rate)

Добавляются прямые delivery costs:

Direct Costs
= Tooling + Temporary Infrastructure + Travel + Specialist/Subcontractor Cost + Other Pass-Through Costs

И отдельно учитывается работа, которую легко забыть:

Delivery Basis
= Labor
+ Direct Costs
+ Coordination
+ QA / Peer Review
+ Reporting
+ Commercial / Delivery Risk Reserve

Для хорошо ограниченного fixed-scope engagement из этой модели получается фиксированная цена проекта. И это норм! Здесь не требуется сложная финансовая математика (мы хоть и инженеры, но таки не бухгалтеры и не экономисты шарить за все эти нюансы расчетов). Важнее другое: каждая существенная часть цены должна иметь связь с delivery model.

В Bulwark Advisory оценка начинается со scope и ожидаемой трудоемкости, а не с числа, которое кажется приемлемым для конкретного клиента.

3. Scope - первый фактор цены

Одинаковое название услуги может скрывать совершенно разный объем работы.

К примеру, одна из услуг "AWS Security Assessment" может означать:

один небольшой AWS account;
AWS Organizations с 40 accounts;
EKS, serverless, IAM Identity Center, несколько регионов, десятки data stores и несколько CI/CD paths;
только read-only architecture review;
assessment вместе с validation, implementation, Terraform changes и remediation support.

Это разные проекты. Разный скоуп, разный ценник, разный outcome на выходе. Это не значит, что какой-то "плохо" или не нужный, а какой-то проект хороший и делать нужно только его или больше никак. Кастомизации и выполнение запроса клиента (заказчика) при соблюдении технических компетенций - это то что отличает профессионала от любителя.

То же самое относится к penetration testing. API с 30 документированными endpoints и одной auth-моделью нельзя сравнивать с multi-tenant SaaS, в котором несколько ролей, сложная authorization logic, GraphQL, asynchronous workflows, third-party integrations и business-logic abuse cases. Разница чествуется уже при прочтении... А покажи это тру пентестеру и он объяснит все более детальнее, но суть при этом остается той же.

Авторитетный фреймворк OWASP прямо указывает, что глубина тестирования должна зависеть от архитектуры, чувствительности данных, threat model и risk tolerance. Web Security Testing Guide также подчеркивает, что техническое тестирование является только частью consultancy assessment. Scope, limitations, reproducibility, reporting, remediation guidance и executive communication также входят в полноценный deliverable.

Поэтому нормальный scope должен фиксировать как минимум:

Параметр	Пример
Target	1 web app, 1 AWS account, 2 clusters, 50 API endpoints
Access model	Black-box, authenticated, source-assisted, read-only cloud access
Roles / tenants	Admin, standard user, partner, customer tenant
Evidence	Repositories, diagrams, pipelines, IAM exports, scanner output
Deliverables	Findings, risk model, roadmap, executive readout, retest
Constraints	Production restrictions, testing windows, excluded systems
Client dependencies	VPN, test account, VM, allowlisting, interviews
Timeline	Standard, accelerated, hard deadline

Цена без этого контекста мало что означает. Цена это итог, но профессионал всегда может рассказать, объяснить из чего она складывается.

4. Клиент тоже тратит время, даже если vendor выставил fixed fee

Это одна из самых недооцененных частей экономики Security-проекта.
Для penetration test инженер клиента может быть обязан:

подготовить VM;
создать временные credentials;
настроить VPN tunnel;
добавить IP тестировщика в allowlist;
установить agent;
подготовить staging environment;
загрузить репрезентативные test data;
объяснить архитектуру и trust boundaries;
воспроизвести finding;
координировать remediation и retest.

Это реальные трудозатраты. Vendor их может не выставлять в invoice, но компания все равно за них платит.

Поэтому более честная формула выглядит так:

Total Client Economic Cost
= Vendor Fee
+ Internal Preparation Hours
+ Internal Coordination Hours
+ Remediation Effort
+ Temporary Infrastructure
+ Opportunity Cost of Delayed Engineering Work

Хороший поставщик должен показывать client-side dependencies еще на стадии scoping. Если этого не делать, предложение может выглядеть искусственно дешевым, а реальная часть затрат просто переедет в engineering-команду клиента. Это не профессионально.

Низкий vendor fee не всегда означает дешевый engagement.

5. Почему зарплату сотрудника (в найме) нельзя сравнивать с consulting rate

Типичный procurement-аргумент выглядит примерно так:

"Security engineer получает около $130K в год. Это примерно $62 в час. Почему консультант должен стоить $150 или $200 в час?"

Арифметика простая. Экономическая модель неверная. И сейчас я объясню почему так. По данным U.S. Bureau of Labor Statistics, медианная годовая зарплата Information Security Analyst в мае 2025 года составляла $129,180, а верхние 10% получали более $199,850. По данным BLS за март 2026 года, wages составляли около 69.9% total compensation в private industry, а benefits - около 30.1%.

Если использовать это соотношение только как грубую нормализацию:

$129,180 / 0.699 ≈ $184,807 loaded compensation

Для уровня BLS top 10%:

$199,850 / 0.699 ≈ $285,908 loaded compensation

И это еще без company-specific расходов на recruiting, оборудование, security tooling, management time, обучение, офис и стоимость неудачного найма.

Данные SHRM в Recruiting Benchmarking 2026 указывает 39 календарных дней median time-to-fill для nonexecutive positions. В 2025 benchmark средняя стоимость nonexecutive hire составляла $5,475. CyberSeek также отмечал, что cybersecurity-роли в среднем закрываются дольше других технологических вакансий. И отсюда есть вываод. А какой? Читаем дальше.

По итогу деление salary на 2,080 часов не показывает реальную стоимость приобретения и эксплуатации capability. Кроме того, оно предполагает, что каждый оплаченный час превращается в productive security work. Так не работает ни одна инженерная организация.

Meetings, planning, documentation, internal projects, incidents, training, PTO, context switching и организационная нагрузка тоже потребляют время (а мы помним, что формальный трудовой день = 8 часов). Если компании нужен specialist на bounded project объемом 80 часов, full-time hire (найм в штат) не является покупкой этих самых 80 часов. Это решение о постоянной capacity, то есть перманентно, на долго, "на постоянку" с полноценной загрузкой от месяца к месяцу.

6. Почему consulting hour также не равен зарплатному часу

На стороне provider действует та же логика. Консалтинговая компания не может продать клиентам каждый оплаченный час команды.

Sales calls обычно не billable. Proposal writing не billable. Internal training, research, maintenance внутренних инструментов, accounting, contract review, marketing, productization, quality systems, bench time и проигранные presales также не billable. То есть время то тратишь, ресурсы тоже, ездишь к клиенту, ждешь его, а денег за это не спрашиваешь. Таков цикл продаж и реалии бизнеса.

В 2026 SPI Professional Services Maturity Benchmark, который разбирает Certinia, billable utilization за 2025 год снизился до 66.4%, минимального значения за историю benchmark. Это не целевой показатель Bulwark Advisory и не универсальная норма. Он показывает структурный факт: billable hour финансирует часть non-billable деятельности сервисного бизнеса.

ПО ИТОГУ: из $150 billed hour нельзя сделать вывод, что $150 превращаются в зарплату или прибыль.

Более же реалистичная формула выглядит так:

Required Commercial Rate
≈ (Annual People Cost + Operating Overhead + Tools + Insurance + Non-Billable Cost + Risk + Target Operating Margin)
  / Expected Billable Hours

Поэтому invoice rate и base salary rate - две разные экономические величины. И кто их понимает - тот профессионал (не в смысле только инженер, а в смысле Security как бизнеса).

7. Актуальные рыночные ориентиры без попытки придумать одну "правильную цену"

Цены в cybersecurity сильно зависят от geography, specialization, бренда, liability, urgency и scope. Публичные значения полезны как reference points, но не как тарифная сетка. В этом плане, например, США - топ, ЕС - меньше, Африка - сам понимаешь:)

На сентябрь 2026 года можно использовать несколько ориентиров:

Публичный ориентир	Опубликованное значение	Что этот показатель реально показывает
Clutch Cybersecurity Pricing Guide	$100-$149/hour average provider cost на Clutch	Широкий marketplace anchor для cybersecurity providers
vCISO.com market overview	$3,000-$15,000/month за vCISO retainers; $200-$400/hour за hourly consulting	Публичный commercial reference для senior/fractional leadership
Atlant Security	API pentest from $4,000, web pentest from $5,000, cloud pentest from $6,000	Публичные starting prices специализированного security provider
UK IT Jobs Watch	Median Security Consultant contract rate £563/day за 6 месяцев до 17 Sep 2026	Сигнал contractor labor market, а не клиентская цена consulting company
Eurostat	EU average whole-economy labor cost €34.9/hour в 2025, euro area €38.2/hour	Employer labor-cost baseline, а не ставка cybersecurity consulting

Eurostat хорошо показывает, почему понятие "средняя европейская ставка" часто бессмысленно. В 2025 году whole-economy hourly labor cost в ЕС находился в диапазоне от €12.0 в Болгарии до €56.8 в Люксембурге. Non-wage costs составляли 24.8% total labor cost в EU.

И, вот после этого geography накладывается на specialization. Затем на цену влияют liability, insurance, требования к data handling, contractual risk и уровень качества deliverable.

8. Публичные starting prices Bulwark Advisory - это planning anchors

Bulwark Advisory публикует starting prices для сфокусированного baseline scope, а не прячет любое число за кнопкой "request a quote".

Некоторые ориентиры 2026 года:

Service	Публичный baseline	Typical bounded delivery
Product Security Baseline Sprint	from $3,500	5-7 business days
Product Security Program Assessment	from $4,500	1-3 weeks
Secure Architecture & Threat Modeling	from $3,500	3-10 business days
DevSecOps & CI/CD Security Assessment	from $4,500	1-2 weeks
AWS Security Assessment	from $3,500	1-3 weeks
Kubernetes & Container Security	from $4,000	1-2 weeks
AppSec Toolchain Optimization	from $3,500	1-2 weeks
Metrics & Executive Reporting	from $2,500	3-10 business days
Fractional Product Security Leadership	from $4,000/month	recurring
Web Application Security Testing	from $4,500	7-10 business days
API Security Testing	from $3,500	5-7 business days
Cloud Penetration Testing	from $5,000	7-10 business days

У слова "from" здесь есть конкретный смысл. Это tightly bounded baseline scope с нормальным доступом к evidence и stakeholders.

Multi-product environment, неясный ownership, hard deadline, implementation-heavy work, большое количество cloud accounts, сложный Kubernetes estate, нестандартные legal requirements, travel или расширенный retest закономерно меняют оценку.

Final scope, assumptions, exclusions, timeline и fixed price фиксируются до начала delivery. Это 100% правило. Без исключений. Так можно одновременно сохранить прозрачность и не делать вид, что все инфраструктуры одинаковы.

9. Модельный пример: что реально может находиться внутри assessment за $18K

Следующий расчет является демонстрационной моделью. Это не Bulwark quote и не отраслевой benchmark. Предположим, компании нужен authenticated web/API security assessment customer-facing SaaS-продукта.

Scope:

одно web application;
около 35 API endpoints;
три значимых user roles;
один staging environment;
architecture walkthrough;
manual authorization и business-logic testing;
автоматизация там, где она полезна;
exploit validation;
executive и technical reporting;
remediation readout;
один bounded retest.

Effort model может выглядеть так:

Work package	Role	Modeled hours
Scoping, ROE, success criteria	Principal	4
Architecture and evidence review	Senior security engineer	10
Access validation and test setup	Senior security engineer	6
Test design and attack-path mapping	Senior security engineer	10
Manual web/API testing	Senior security engineer	32
Tool-assisted discovery and validation	Senior security engineer	8
Finding reproduction and de-duplication	Senior security engineer	8
Technical report and remediation guidance	Senior security engineer	12
Principal QA / challenge review	Principal	6
Executive and engineering readout	Principal	2
Bounded retest	Senior security engineer	6
Total		104 hours

Далее применяется условный role mix:

Senior: 92 h × $150 = $13,800
Principal: 12 h × $220 = $2,640
Temporary tooling / infrastructure = $450
Modeled delivery basis = $16,890

Fixed commercial price около $18K-$19K для такого модельного scope может быть абсолютно рациональным после учета разумного delivery uncertainty и fixed-fee risk. Это не rate card. Это демонстрация происхождения числа.

NIST разделяет penetration testing как минимум на planning, discovery, attack и reporting. OWASP еще прямее отмечает, что** technical testing - только половина assessment process.** Нормальный проект должен превратить evidence в результат, который developer способен воспроизвести, manager способен приоритизировать, а бизнес способен использовать в решении. На это требуется экспертное время. А время, как мы знаем, деньги. А время = это твоя жизнь. И если ты в найме, то как раз за время и продаешь себя. Так что "время" это фундаментальная категория.

10. Client-side effort в том же сценарии

Со стороны клиента также может понадобиться:

Client activity	Modeled internal hours
Engineering setup, test users, environment checks	6-10
VPN / allowlisting / access support	2-4
Architecture и threat-context interviews	3-5
Security / PM coordination	3-5
Finding clarification и retest support	4-8
Total client-side effort	18-32 hours

Именно поэтому хороший scoping имеет экономическую ценность еще до тестирования. Если provider способен заранее сформулировать evidence requests, пакетно провести интервью, быстро настроить доступы, не задавать повторно одни и те же вопросы и выдавать воспроизводимые findings, клиент экономит внутреннее engineering time. Эта экономия редко появляется в invoice, но является частью качества услуги.

11. Senior rate против junior rate: правильная формула

Высокий hourly rate не означает дорогой результат. Единица измерения должна быть не cost per hour, а скорее cost per accepted result.

Для двух специалистов, которые должны выдать сопоставимое по качеству решение:

Senior Cost = Senior Rate × Senior Hours
Junior Cost = Junior Rate × Junior Hours + Review + Rework + Delay Cost

Если пока убрать review и rework, senior оказывается дешевле, когда:

Senior Hours / Junior Hours < Junior Rate / Senior Rate

Например:

senior rate: $200/hour;
junior rate: $80/hour;
senior стоит по rate в 2.5 раза дороже.

Но по чистому labor senior уже экономически выгоднее, если ему требуется менее 40% времени junior.

Модель:

Senior: 24 h × $200 = $4,800
Junior: 60 h × $80 = $4,800
+ Senior QA: 8 h × $200 = $1,600
Total junior-led delivery = $6,400

Низкий hourly rate дал более дорогой outcome. Теперь крайний sensitivity example. Senior rate выше в 5 раз, но тот же приемлемый результат получается в 10 раз быстрее.

Senior = 5R × H/10 = 0.5RH
Junior = R × H = 1.0RH

Даже здесь senior обходится на 50% дешевле до учета rework, ошибок, management overhead и delay. Это не означает, что senior должен выполнять все задачи. Есть огромное количество repeatable work, где junior, analyst, automation workflow или managed service экономически правильнее.

Вывод же здесь несколько другой:

Hourly rate - плохой procurement metric, когда productivity, judgment, error rate и review burden заметно различаются.

12. Senior expertise не должна применяться ко всему подряд

Прозрачность означает также отказ от ситуации, когда principal-level expertise оплачивается за commodity work, где она не нужна.

Экономичный role mix может выглядеть так:

Тип работы	Рациональная модель
Architecture judgment, risk acceptance support	Principal / senior
Complex authorization logic testing	Senior specialist
Threat modeling facilitation	Senior / principal
Standard evidence collection	Analyst / automation
Repeatable scanning	Automation / platform
Initial finding normalization	Analyst / automation
High-impact finding validation	Senior
Executive translation and prioritization	Principal / senior
Continuous commodity monitoring	Managed service, если оправдано

Именно поэтому productized services часто экономически эффективнее completely bespoke delivery. И важно понимать, что Reusable checklists, evidence requests, templates, scripts, dashboards и report structures уменьшают low-value manual effort. Они не заменяют экспертное judgment. Они концентрируют экспертное время там, где оно действительно нужно.

13. Fixed fee, T&M, retainer, outstaffing, MSSP или full-time hire?

Универсально лучшей коммерческой модели не существует. Все зависит от формы спроса на capability.

Модель	Где работает лучше всего	Экономическое преимущество	Ограничение
Fixed-scope project	Bounded assessment, architecture review, pentest, roadmap	Predictable budget, ориентация на deliverable	Требует качественного scoping
Time & Materials	Discovery-heavy или неопределенная engineering work	Гибкость при изменении реальности	Больше duration risk у клиента
Retainer / fractional leadership	Регулярные senior decisions без full-time потребности	Senior judgment на частичной capacity	Плохо подходит для постоянной hands-on execution
Outstaffing / contractor	Embedded capacity внутри client backlog	Быстрое расширение capacity	Management и prioritization остаются у клиента
Managed service / MSSP / MDR	Repeatable continuous operations	Масштаб, coverage, operational leverage	Меньше product-specific context
Full-time hire	Стабильная постоянная workload и ownership	Глубокий контекст, долгосрочное ownership	Hiring time, fixed annual commitment, utilization risk
Tooling-only	Массовое repeatable detection при уже выстроенном workflow	Automation и scale	Tool output не равен risk judgment и remediation ownership

Вопрос не должен звучать как "consultant или employee?" Гораздо полезнее будет узнать:

Как выглядит спрос, насколько он постоянный и какая operating model покупает нужный outcome с минимальным waste?

14. Простой break-even для consulting против найма

Предположим, компании нужна senior security capability для bounded project и небольшого follow-up. Если использовать BLS median wage только как отправную точку, нормализованный loaded compensation получился примерно $185K/year. Для специалиста верхнего диапазона эта цифра легко становится заметно выше.

Упрощенная in-house модель:

Annualized In-House Cost
= Loaded Compensation
+ Recruiting
+ Tooling
+ Equipment
+ Training
+ Management Overhead
+ Vacancy / Onboarding Cost

External specialist:

External Specialist Cost
= Project / Retainer Fees
+ Client Coordination Cost
+ Pass-Through Expenses

Если организации ежегодно требуется 1,400-1,700 часов постоянного security ownership, full-time hire может оказаться очевидным решением. Если нужен 150-hour architecture review, 100-hour assessment или временный senior decision-maker на переходный период, permanent hire может оказаться экономически бессмысленным. Не потому, что сотрудники менее эффективны. Причина проще: fixed capacity слишком дорога при intermittent demand.

НО! И обратное также верно. Если компания годами покупает по 160 consulting hours каждый месяц, стоит проверить, не пора ли часть capability перенести in-house. Честный консультант должен быть способен это сказать.

15. Tooling является альтернативой только тогда, когда проблема действительно решается tooling

Частый вопрос: "Зачем платить за assessment, если scanner subscription стоит дешевле?"

Иногда это абсолютно правильный вопрос. Если задача состоит в повторяемом detection известных vulnerability classes в большом масштабе, automation может быть лучшей инвестицией.

Но scanner сам по себе не дает:

architecture context;
business-logic testing;
сложный authorization analysis;
exploitability validation;
finding de-duplication между несколькими tools;
business impact translation;
prioritization с учетом продукта;
ownership decisions;
remediation design;
executive communication.

OWASP отдельно рассматривает source review, penetration testing и automated SAST/DAST/SCA именно потому, что эти методы решают разные части задачи.

Корректная модель не "human или tool". Она выглядит так:

Best Delivery Cost
= Automation for Repeatable Work
+ Human Judgment for Ambiguous / High-Context Work

Чем больше первой категории безопасно автоматизируется, тем больше senior time остается для второй. Это выгодно обеим сторонам. Profit!

16. Value cross-check: Security-проект вообще стоит своих денег?

Transparent pricing не означает, что любой security project нужно покупать. Некоторые покупать не нужно.

Control может быть технически правильным и экономически неоправданным. Compliance activity может быть реальной, но преждевременной. Tool может быть хорошим, но дублирующим. Assessment может быть слишком широким для решения, которое бизнес пытается принять. Поэтому цена должна проходить value cross-check.

Упрощенно:

Security Value
≈ Expected Loss Reduced
+ Engineering Time Recovered
+ Release Delay Avoided
+ Revenue / Procurement Enabled
+ Tooling or Operating Cost Removed
- Implementation and Remediation Cost

Для risk reduction:

Expected Loss Reduction
= (Probability_before × Impact_before)
- (Probability_after × Impact_after)

Это scenario analysis, а не попытка предсказать будущее.

Probability и impact обычно неопределенны, поэтому range часто честнее одной красивой цифры.

Assessment за $15K, который позволяет убрать $80K duplicated annual tooling, сокращает recurring release delays и дает рабочую control model, экономически совершенно не равен другому assessment за $15K, после которого остается PDF, который никто не использует.

Invoice одинаковый. Value разный.

Security value появляется только тогда, когда результат меняет решение, control, engineering behavior или material risk.

17. Что бизнес должен видеть в прозрачном proposal

Нормальное предложение делает экономику проверяемой, не превращая proposal в публикацию внутренней бухгалтерии provider.

Минимально должны быть понятны следующие вещи:

Что входит в scope?
Что явно находится out of scope?
Какие deliverables включены?
От каких assumptions зависит price?
Какой access и preparation нужны от клиента?
Какой delivery window?
Включен ли retest?
Что происходит при scope change?
Travel, tooling, infrastructure и third-party costs включены или pass-through?
Какие senior roles отвечают за technical quality и final judgment?
Как выглядит acceptance?
Что происходит после выдачи findings?

Для fixed-scope engagement ответ не должен быть: "мы потратили больше часов, поэтому счет вырос". Если scope не изменился, а provider ошибся в estimate, это в нормальной fixed-fee модели его estimation risk.

Если клиент добавил три applications, два cloud accounts, новые roles или implementation work, это уже scope change. Он оформляется до выполнения дополнительной работы. Так защищаются обе стороны. Это нормально. Это бизнес, это Profit для всех участников.

18. Pricing anti-patterns

Дорогой quote не обязательно нечестный. Дешевый quote не обязательно выгодный. Есть несколько моделей, на которые стоит смотреть особенно внимательно.

Senior rate, junior delivery

В proposal продается principal-level expertise, но большая часть delivery незаметно уходит inexperienced staff без соответствующей корректировки economics и QA.

Scanner pass-through под видом consulting

Запускается стандартный tool, raw output немного форматируется, а клиент платит за "expert assessment" без meaningful validation и prioritization.

Искусственно низкий entry price

Публичный "from" невозможно получить ни при каком реалистичном scope. Он нужен только как lead magnet.

Hidden coordination fees

PM, reporting, calls, retesting или базовый QA не включены, а после старта превращаются в доплаты.

Overstaffed delivery

Несколько людей присутствуют на одних и тех же встречах или многократно проверяют одну работу без понятной value, а buyer финансирует внутреннюю неэффективность provider.

Senior занимается analyst work

Обратная ошибка. Дорогая expertise расходуется на data collection, formatting и repeatable checks, которые можно автоматизировать или делегировать.

Margin спрятан в ненужном scope

Вместо честной цены небольшой задачи engagement расширяется только для того, чтобы достичь target contract value.

"Compliance требует" без applicability analysis

Controls, audits или tools продаются как mandatory до проверки реальной contractual или regulatory applicability.

А какой из всего этого вывод? ВОТ ОН: Transparent pricing снижает риск всех этих сценариев.

19. Практическая модель Bulwark Advisory

Процесс намеренно выглядит просто. Это преимущество, а не недостаток.

1. Scope

Targets, evidence, deliverables, assumptions, exclusions, authorization, success criteria и client dependencies фиксируются до оценки.

2. Decompose

Проект разбивается на work packages и measurable scope units.

3. Estimate

Используются realistic effort ranges, основанные на прошлой delivery, complexity и качестве access.

4. Role mix

Senior/principal time резервируется для judgment-heavy work. Repeatable work уходит в automation или lower-cost execution там, где это не снижает качество.

5. Direct costs

Tooling, temporary cloud infrastructure, travel, contractor support и special data-handling requirements попадают в модель явно.

6. QA и reporting

Это часть продукта, а не бесплатная административная надстройка.

7. Fixed-scope risk

Fixed fee переносит разумный estimation risk на provider. Этот риск должен быть учтен в цене, а не автоматически перевыставлен клиенту как дополнительные часы.

8. Value sanity check

Если outcome не оправдывает cost, нужно уменьшить scope, сменить delivery model или не продавать работу.

9. Confirm in writing

Final scope, timeline, price, assumptions и exclusions попадают в proposal / SOW / ROE в зависимости от услуги.

10. Scope change только явно

Никаких surprise hourly overages. Material expansion сначала оформляется как change order, а уже потом выполняется.

Так price становится объяснимым, а не произвольным. Понятные условия = адекватное доверие, взаимовыгодное сотрудничество = контракт.

Заключение: задача не в том, чтобы сделать Security дешевым

Качественная cybersecurity expertise действительно может стоить дорого. Senior expertise формируется годами через production incidents, architecture decisions, неудачные подходы, testing, research, certifications, code, cloud environments, pipelines, investigations, reports, customer conversations и сложные tradeoffs.

Но экономическая ценность опыта появляется только тогда, когда он снижает стоимость достижения правильного результата. Высокий rate с небольшим waste может быть дешевле низкого rate с большим количеством часов, слабым judgment, rework и management overhead.

Consultant может быть дешевле hire, если demand временный.
Hire может быть дешевле consultant, если demand постоянный.
Managed service может выиграть у обоих для repeatable 24x7 operations.
Automation может быть выгоднее всех для deterministic repetitive work.

А иногда экономически правильное решение - вообще не покупать конкретную Security-услугу. Это принципиальный момент.

Transparent pricing не обещает, что любые затраты на security имеют положительный ROI. Он делает assumptions достаточно видимыми, чтобы это можно было проверить.

Цель не в максимизации Security spend. Цель в покупке правильного количества квалифицированного judgment, engineering effort и operating capability под тот риск и business outcome, которые реально существуют.

Для Bulwark Advisory именно это лежит в основе pricing model: ясный scope, понятные assumptions, senior ownership, right-sized delivery и отсутствие искусственно созданной работы ради более крупного invoice.

Security должна быть достаточно измеримой, чтобы ее можно было оспаривать. Pricing тоже.

Источники и рыночные ориентиры

U.S. Bureau of Labor Statistics, Information Security Analysts, May 2025 wage data: https://www.bls.gov/ooh/computer-and-information-technology/information-security-analysts.htm
U.S. Bureau of Labor Statistics, Employer Costs for Employee Compensation, March/June 2026: https://www.bls.gov/ecec/factsheets/compensation-percentile-estimates.htm и https://www.bls.gov/news.release/ecec.nr0.htm
SHRM, 2026 Recruiting Executives Benchmarking: https://www.shrm.org/topics-tools/research/recruiting-benchmarking
SHRM, 2025 Benchmarking Reports, включая cost-per-hire: https://www.shrm.org/about/press-room/shrm-releases-2025-benchmarking-reports--how-does-your-organizat
CyberSeek, U.S. cybersecurity workforce data: https://www.cyberseek.org/
Clutch, Cybersecurity Pricing Guide, September 2026: https://clutch.co/it-services/cybersecurity/pricing
Atlant Security, public cybersecurity pricing: https://atlantsecurity.com/pricing
vCISO.com, public 2026 vCISO / consulting pricing overview: https://www.vciso.com/vciso-cost
IT Jobs Watch, UK Security Consultant contract rates, September 2026: https://www.itjobswatch.co.uk/contracts/uk/security%20consultant.do
Eurostat, EU hourly labour costs in 2025: https://ec.europa.eu/eurostat/en/web/products-eurostat-news/w/ddn-20260331-2
Certinia, summary of the 2026 SPI Professional Services Maturity Benchmark: https://www.certinia.com/blog/analyzing-the-2026-spi-research-professional-services-maturity-benchmark-report/
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/pubs/sp/800/115/final
OWASP, Web Security Testing Guide: https://wstg.owasp.org/latest/5-Reporting/01-Reporting_Structure/ и https://wstg.owasp.org/latest/2-Introduction/

Методологическая оговорка (DISCLAIMER)

Все project calculations в статье являются illustrative planning models. Это не заявления об универсальной отраслевой трудоемкости, фактических счетах клиентов или гарантированном ROI. Реальная цена зависит от scope, access, complexity, timeline, geography, contractual requirements, third-party cost и delivery risk.

Технический английский для security engineer: База о том как писать, говорить и проходить интервью

Ivan's Cybersecurity Notes — Sun, 13 Sep 2026 22:00:00 +0000

Preview

Hey, you'all

Не секрет, что у многих русскоязычных IT/security-специалистов (РФ, СНГ) английский ассоциируется с чем-то огромным и неприятным: времена, артикли, неправильные глаголы, идеальное произношение, «надо сначала подтянуть уровень, а потом уже пробовать». И так по кругу, до бесконечности: их идеал — недостижим, а реальный же английский — это инструмент, который нужен уже сегодня, а не завтра. Просто интсрумет, просто еще один скилл что бы жить полноценно.

На практике в международной команде всё намного приземлённее. Тебе не нужно сначала стать филологом. Тебе нужно уметь делать вот это базовые рабочие вещи:

написать status update;
уточнить scope;
попросить доступ;
объяснить finding;
описать risk и impact;
не звучать грубо в Slack;
не потеряться на митинге;
пройти HR screening;
рассказать о себе на интервью;
задать нормальный вопрос, когда что-то непонятно.

Это другой подход. Не «выучить весь английский», а собрать рабочий набор фраз, сценариев и паттернов.

Я сам долго воспринимал английский как школьно-университетский предмет: слова, тексты, упражнения, оценки. Но реальная рабочая коммуникация — созвоны, письма, security reports, американские рекрутеры, обсуждение findings с engineering-командами — быстро показывает, что язык нужен не «для галочки». Английский — обязательный поинт для работы в иностранной компании, новые возможности для нетворкинга, опора в путешествиях и релокейте, документация в оригинале и не только. Как же его освоить быстро и эффективно? - об этом и перетрем в нашей сегодняшней статье.

Английский в IT — это рабочий интерфейс. Через него ты объясняешь задачи, риски, решения и собственную ценность.

Главная проблема: люди знают термины, но не умеют ими работать

У русскоязычных специалистов часто проблема не в том, что они «совсем не знают английский». Часто картина такая:

читают документацию, но боятся писать;
знают слова vulnerability, endpoint, credentials, но не могут объяснить impact;
переводят русские фразы буквально/дословно;
звучат резче (грубовато для носителя), чем хотели;
на митингах молчат, потому что боятся ошибиться или жуют «кашу»;
в интервью отвечают либо слишком коротко, либо слишком хаотично;
пишут отчёты языком Google Translate;
знают инструмент/фреймворк, но не могут описать результат своей работы.

В security это особенно заметно. Мы часто говорим о неприятных вещах: баги, риски, инциденты, дедлайны, ownership, remediation, false positives, blockers.Если написать слишком резко — разработчики услышат обвинение. Если написать слишком размыто — никто не поймёт, что делать дальше.

Хороший technical English — это не сложный английский. Это понятный, спокойный и actionable English.

1. Рабочая формула: clarity, ownership, next steps

В международной IT-команде ценят не красоту языка, а понятность. Хорошее сообщение обычно отвечает на три вопроса:

Что происходит?
Кто владелец / от кого зависит следующий шаг?
Что делаем дальше?

Плохо:

There is some problem with scanner.

Лучше:

The scanner cannot reach the staging endpoint because VPN access is missing. I’m checking with the platform team and will update the ticket today.

Почему лучше:

есть конкретная проблема;
есть причина;
есть dependency;
есть следующий шаг;
есть срок.

Это и есть рабочий английский. Не надо писать сложно. Надо писать так, чтобы другой человек мог принять решение или выполнить действие.

2. Не надо учить «весь английский»

Для старта в IT/security достаточно собрать рабочий минимум. Помним правило Парето? — 20% усилий дают покрытие 80% всех потребностей.

Что учить	Минимум	Что это даёт
General English	1000–2000 частотных слов	Понимать письма, чаты, интервью
Grammar	Present / Past / Future + questions	Объяснять статус, действия, планы
Security vocabulary	300–400 терминов	Читать findings, reports, tickets
Patterns	50–100 готовых фраз	Писать и говорить без паники
Pronunciation	10–20 сложных слов/звуков	Быть понятным на звонках

A2–B1 уже можно превратить в рабочий инструмент, если не пытаться говорить как профессор. Говорящий A2 на живом английском зачастую даст фору академическому B2.

Базовые конструкции закрывают огромную часть задач:

Смысл	Pattern	Пример
Что делаю сейчас	`I’m working on…`	I’m working on the remediation plan.
Что нашли	`We found…`	We found a logging gap yesterday.
Что показал сканер	`The scan detected…`	The scan detected three medium-severity issues.
Что уже сделали	`We have completed…`	We have completed the access review.
Следующий шаг	`The next step is…`	The next step is to validate the fix.
Блокер	`I’m blocked by…`	I’m blocked by missing VPN access.

Для новичка хорошая фраза:

I’m blocked by missing access.

намного ценнее, чем сложная, но сломанная конструкция на пять строк.

3. Почему «русский стиль» в английском часто звучит грубо

Русский рабочий стиль часто прямой:

Сделай сегодня (приказной\давящий тон).
Почему ты это сделал?
Это неправильно. Косяк!
Вы задерживаете релиз. Харэ гнать свою безопаность, нам работать нужно!
Пришли отчёт. До вечера

В английском такая прямота легко звучит как наезд. Нужно поступать мягче и профессиональнее.

Хотел сказать	Слишком резко	Лучше
Сделай сегодня	Do it today.	Could you take a look at this today?
Это неправильно	This is wrong.	I think there may be an issue here.
Я не понял	I don’t understand.	Could you clarify this part for me?
Это не моя задача	It’s not my task.	I think this may be owned by another team.
Ты задерживаешь релиз	You are blocking the release.	This dependency is currently blocking the release.

Смысл не исчезает. Просто фокус смещается с человека на проблему, риск или зависимость. Для security это критично. Если команда воспринимает тебя как человека, который приходит только обвинять и блокировать, с тобой быстро перестанут нормально взаимодействовать.

4. Don’t translate literally: типичные ошибки

Одна из главных проблем — калька с русского. Смотрим внимательно.

Хотел сказать	Неудачно	Лучше
Я согласен	I am agree with you.	I agree with you.
Я хочу уточнить	I want to specify.	I’d like to clarify.
У меня есть сомнения	I have doubts.	I have some concerns.
Мы обсудили вопрос	We discussed about this question.	We discussed this issue.
Я участвовал в проекте	I participated in the project.	I worked on the project / I was involved in the project.
Я отвечал за безопасность	I answered for security.	I was responsible for security.
Сделал анализ уязвимостей	I made vulnerability analysis.	I performed a vulnerability assessment.
Зайти на митинг	Enter the meeting.	Join the meeting / jump on the call.
Закрыть задачу	Close the task.	Close the ticket / mark the task as done.

Мини-правило:

Если русская фраза содержит «осуществить», «провести», «выполнить мероприятие», в английском почти всегда можно заменить это одним сильным глаголом: perform, run, review, validate, monitor, investigate, fix, mitigate, document.

Плохо:

Carry out monitoring of information security.

Лучше:

Monitor security events.

Плохо:

Make analysis of vulnerabilities.

Лучше:

Perform a vulnerability assessment.

Ну, думаю, общую суть ты уловил! Идём дальше.

5. Professional, not robotic

Professional English — это не сухой бюрократический английский. Хороший рабочий стиль звучит спокойно, ясно и уважительно. Особенно когда вы пишете о риске.

Плохо:

This is bad. You need to fix it immediately.

Лучше:

This may create a security gap because logging is incomplete. I’d recommend adding authentication and authorization logs before launch.

Во втором варианте есть:

причина;
security impact;
рекомендация;
контекст по сроку.

Это не «мягкотелость». Это нормальная профессиональная коммуникация.

Hedging: как говорить о риске

В security нельзя всё превращать в critical disaster. Но и размывать проблему нельзя.

Полезные конструкции:

Фраза	Когда использовать
This may introduce additional risk.	Когда риск возможен, но не доказан окончательно
My main concern is…	Когда нужно объяснить основную проблему
From a security perspective…	Когда важно отделить security view от product/business view
I wouldn’t call it critical yet, but it’s worth reviewing.	Когда не хочется overclaim
The risk seems manageable if we add compensating controls.	Когда есть временное решение
I’d recommend treating this as high priority.	Когда нужно аккуратно поднять важность

Пример:

I see why we want to keep the timeline. My concern is that without auth logs, we may have a hard time investigating suspicious activity. One option might be to add a minimal logging control before launch and complete the full implementation after release.

Это хороший security tone: без драмы, но с понятным риском и вариантом решения.

6. Email, Slack и Teams: коротко, по делу

Email обычно строится так:

greeting → purpose → context → ask → deadline → closing

Slack/Teams короче, но контекст всё равно нужен.

Плохо:

Hi

И тишина, пока человек не ответит.

Лучше:

Hey Alex, quick question when you have a minute. I’m reviewing the DAST findings and need to confirm who owns the staging API. Do you know the right owner?

Сразу понятно:

кто пишет;
зачем;
по какой задаче;
какой конкретный ask.

Полезные фразы для email

Задача	Фраза
Сразу к делу	I’m reaching out about the upcoming security review.
Уточнить ожидания	Could you clarify what level of detail you expect in the report?
Уточнить срок	Just to confirm, is the deadline still Friday, May 15?
Попросить контекст	Could you share a bit more context on the business impact?
Сообщить о блокере	We’re currently blocked by missing access to the staging environment.
Предложить следующий шаг	The next step would be to validate the finding with the application owner.
Мягко не согласиться	I see your point. My concern is that this may increase the attack surface.
Эскалировать аккуратно	I’d like to flag this as a timeline risk so we can agree on the best path forward.

Шаблон: request access

Hi [Name],

I’m working on [task/project] and need read-only access to [system/logs/repository] to complete the review. Could you please grant access or point me to the right owner?

Context: [one sentence explaining why].
Target date: [date].

Thanks,
[Your Name]

Шаблон: status update

Hi team,

Quick update on [project/review]:

Completed: [what is done]
In progress: [what you are doing now]
Blockers: [dependency, if any]
Next step: [specific action]
ETA: [date/time]

Please let me know if you see any gaps or concerns.

Thanks,
[Your Name]

Slack/Teams: сухо vs нормально

Сухо / грубо	Лучше
Send me the report.	Could you send me the report when you get a chance?
Explain.	Could you give me a bit more context?
Why did you do that?	Could you walk me through the reasoning here?
Fixed.	Fixed — could you please verify on your side?
Not working.	I’m still seeing the issue on my side.

7. Meeting survival kit: как не теряться на созвонах

Митинг — это не экзамен по английскому. Обычно он держится на простой структуре:

goal → status → blocker → decision → next step

Полезные фразы:

Ситуация	Фраза
Открыть встречу	Thanks everyone for joining. Let’s start with the goals for today.
Дать agenda	We have three items on the agenda: scope, risks, and next steps.
Дать статус	I completed the threat model draft and I’m waiting for feedback from the backend team.
Назвать blocker	My main blocker is missing access to the production-like dataset.
Попросить помощь	I’d appreciate your help validating whether this is a false positive.
Вернуть фокус	That’s a good point. To stay on track, let’s park it and come back after the meeting.
Подвести итог	To recap, we agreed on three action items.
Закрыть встречу	Thanks everyone. I’ll send the notes and owners right after this call.

Если не расслышали:

Sorry, I didn’t catch that. Could you repeat it?

Если связь плохая, глюки сети, микрофона:

You’re breaking up a bit. Could you say that again?

Если нужно еще время что-то пофиксить\подготовиться:

Let me think about it for a second.

Если не знаете ответ:

I don’t have the answer right now, but I can check and follow up.

Лучше уточнить, чем молча согласиться и потом сделать не то.

8. Ask better questions: формула хорошего вопроса

Плохой вопрос:

I have a problem with scanner.

Он слишком общий. Непонятно, что случилось, что уже проверили и какая помощь нужна.

Хороший вопрос строится так:

Context → Problem → What I tried → What I need

Шаблон:

I’m working on [task]. I ran into [problem]. I already tried [steps]. Could you help me with [specific ask]?

Пример:

I’m having an issue with the scanner. It fails during authentication with a 401 error. I checked the token and network access, but the issue still happens. Could you help me verify the scanner configuration?

Другой пример:

I can’t access the staging logs. The VPN works, but Kibana returns a 403. Could you confirm whether my role includes read-only log access?

Ещё пример:

The scanner reports SQL injection on /search, but I can’t reproduce it manually. Could you help me validate whether this is a false positive?

Такой вопрос показывает, что человек не просто «просит помочь», а уже провёл первичную диагностику.

9. Security communication: finding → risk → remediation

Security-коммуникация должна быть calm, evidence-based and actionable.

Не надо писать:

Всё плохо, это опасно, срочно чинить.

Лучше:

We identified a high-severity finding related to broken access control. The issue appears exploitable by authenticated users with a specific role. Recommended remediation: enforce object-level authorization on the server side. Validation plan: retest with two users from different tenants.

Хороший security report block отвечает на вопросы:

что нашли;
где нашли;
насколько серьёзно;
какой impact;
какие evidence;
что делать;
кто owner;
как проверим fix.

Security report block

Блок	Формула	Пример
Summary	We identified [severity] [issue] in [component].	We identified a high-severity access control issue in the admin API.
Impact	This may allow [actor] to [impact].	This may allow an authenticated user to access another tenant’s records.
Evidence	Evidence: [log/screenshot/request/response].	Evidence: request ID 8f2a…, response includes another `tenant_id`.
Recommendation	Recommended remediation: [specific action].	Recommended remediation: enforce tenant-level authorization on the server side.
Owner/date	Owner: [team]. Target date: [date].	Owner: Backend Team. Target date: 2026-05-20.
Validation	Validation plan: [how you will verify].	Validation plan: retest with two users from different tenants.

Важно не overclaim.

Плохо:

This is definitely exploitable by anyone.

Лучше:

Based on current evidence, the issue appears exploitable by authenticated users with [role]. Further validation is needed to confirm external exposure.

10. Incident communication: факты вместо паники

В incident communication важно не выглядеть так, будто вы либо скрываете проблему, либо разгоняете пожар.

Нормальная структура:

what happened → current status → impact → actions → next update

Примеры:

Initial update

We are currently investigating suspicious activity affecting [system]. At this stage, we do not have evidence of data exfiltration, but we are validating logs and access patterns.

Containment

We have isolated the affected host and revoked the potentially compromised credentials.

Executive update

The issue is contained. Business impact appears limited to [scope]. We will provide a full post-incident report after log review is complete.

Follow-up

We identified the likely root cause and are implementing preventive controls.

Security — это не только найти проблему. Это ещё и объяснить её так, чтобы команда могла принять решение.

11. Severity, priority, risk: не смешивайте всё в одно слово

Русскоязычные специалисты часто используют «критично», «приоритетно», «опасно» почти как синонимы.

В рабочем английском лучше разделять:

Термин	Смысл
Severity	Насколько серьёзна уязвимость технически
Priority	Насколько срочно это чинить именно сейчас
Risk	Likelihood + impact в конкретном business context
Impact	Что может произойти, если риск реализуется
Likelihood	Насколько вероятно, что риск реализуется
Mitigation	Как снизить риск
Remediation	Как устранить проблему полностью
Compensating control	Временная мера, снижающая риск

Хорошая фраза:

The technical severity is high, but the business priority may be medium because the affected system is internal and access is restricted.

Она звучит зрелее, чем просто:

It is critical.

12. Как объяснять техническое простыми словами

Security-инженер часто говорит не только с security-инженерами. Нужно уметь переводить technical detail в decision-ready language.

Технически	Для бизнеса / менеджмента
The token is exposed in the client-side code.	A secret key is visible to users, which could allow unauthorized access.
The endpoint lacks authorization checks.	Users may access data they are not supposed to see.
The dependency has a known CVE.	We are using a component with a publicly known security issue.
The S3 bucket is public.	Sensitive files may be accessible from the internet.
MFA is not enforced.	Accounts are easier to compromise if passwords are stolen.

Это не «упрощение для глупых». Это часть работы: объяснить риск так, чтобы с ним можно было что-то сделать.

13. Jira, documentation и action plan

Документация в security должна быть понятной для инженера, менеджера и аудитора.

Хороший документ отвечает на вопросы:

what, why, impact, owner, deadline, evidence, validation

Пример action plan:

Finding: Missing object-level authorization
Risk: Users may access records from another tenant
Business impact: Potential data exposure between tenants
Recommended action: Add tenant-level authorization checks on the server side
Owner: Backend Team
Target date: 2026-05-20
Dependency: Confirm affected endpoints
Validation: Security retest with users from different tenants
Status: In progress

Полезные глаголы для Jira и reports:

investigate;
validate;
reproduce;
confirm;
mitigate;
escalate;
document.

Примеры:

Investigate repeated authentication failures.
Validate whether this finding is reproducible.
Reproduce the issue in staging.
Mitigate the risk with a temporary control.
Document the decision and risk acceptance.

14. Interview English: не отвечайте как словарь

На интервью проверяют не только английский. Проверяют, можете ли вы структурно объяснить опыт. Это важный этап где рекрутёр понимает стоит ли с тобой идти в processing дальше или нет.

Типичный процесс:

Этап	Что проверяют	Как отвечать
Recruiter screening	Опыт, мотивация, English, compensation, location, timeline	Коротко, без глубоких технических деталей
Hiring manager	Scope роли, ownership, прошлые проекты, maturity	Показывать impact, приоритеты, decision-making
Technical interview	AppSec / Cloud / IR / DevSecOps / AD / etc.	Думать вслух, уточнять assumptions, признавать неопределённость
Behavioral / culture fit	Collaboration, conflict, ambiguity	Использовать STAR
Final / team fit	Как будете работать с командой	Задавать вопросы про process, expectations, success criteria

Self-introduction formula

Шаблон:

I’m a [role] with [X years / background] in [domain]. I mostly focus on [2-3 areas]. Recently, I worked on [project/result]. I’m now looking for a role where I can [value you bring].

Пример:

I’m an application security engineer with a background in software development. I focus on threat modeling, secure code review, and vulnerability management. Recently, I helped improve remediation SLAs by building a risk-based triage process. I’m looking for a role where I can work closely with engineering teams and improve secure SDLC at scale.

Weak → Better → Strong

Вопрос	Weak	Better	Strong
Tell me about yourself	I am security engineer. I worked with vulnerabilities and tools.	I’m a cybersecurity specialist with experience in vulnerability management, application security, and security process improvement.	I’m a cybersecurity specialist focused on helping engineering teams reduce real business risk. My experience includes AppSec reviews, remediation planning, and improving security processes across product teams.
How do you prioritize vulnerabilities?	I use CVSS.	I start with severity, exploitability, asset exposure, and business impact.	I combine technical severity with business context: exposure, exploitability, data sensitivity, compensating controls, and release timelines.
How do you work with developers?	I tell them what to fix.	I explain the risk and recommend practical remediation steps.	I try to be a partner, not a gatekeeper: I explain the risk, give clear examples, propose realistic fixes, and align on timelines.
Tell me about a conflict	We disagreed and I proved I was right.	We disagreed on priority, so I shared risk context and we aligned on a plan.	I listened to constraints, reframed the issue as business risk, proposed a compensating control, and we agreed on staged remediation.

15. Small talk и произношение: не идеально, а понятно

Small talk — это не пустая болтовня. Это способ мягко войти в разговор и показать, что с вами комфортно работать. Такова традиция англоязычного мира. Да, это несколько не привычно для носителей славянкого этноса. Но ко вему можно адаптироваться. И вот, например, так.

Безопасные фразы:

How was your weekend?
Hope your day is going well so far.
Welcome back! Hope you had a chance to recharge.
I’m still on my first coffee, so bear with me.

IT/security-specific:

How did the release go last night?
Hope on-call wasn’t too rough this week.
Any interesting findings from the latest review?
Did the regression run finish cleanly?

Темы, которых лучше избегать: политика, религия, семейное положение, возраст, здоровье, иммиграционный статус, чужие зарплаты, войны, стереотипы о национальностях. С произношением цель простая: быть понятным, а не «убрать акцент».

Русскоязычным специалистам чаще всего мешают:

Звук / ошибка	Примеры	На что обратить внимание
W vs V	west / vest, vulnerability	W — губы округляются; V — зубы касаются нижней губы
R	risk, report, remediation	American R не вибрирует
TH	threat, this, authentication	Это не s/z и не t/d
H	host, header, hardening	Не пропускайте H
Stress	vulnerability, analysis, incident	Ударение часто важнее идеального акцента

Слова, которые стоит отдельно потренировать:

vulnerability;
credentials;
phishing;
breach;
threat;
audit;
repository;
authentication;
authorization;
cache;
queue;
suite.

16. Практика: 10 минут в день — база которая тебя сделает

Брошюры и таблицы бесполезны, если не превращать их в повторяемую практику. Учить придется, да. Повторять придется, никто не отменял. Ошибки в речи или письме будут, но с каждым разом все меньше и меньше.

Например, вот тебе простой 7-дневный цикл:

День	Фокус	Задание
Day 1	Self-intro	Напишите 5 предложений о себе
Day 2	Status updates	Сделайте 3 апдейта: completed / in progress / blocker / next step
Day 3	Email templates	Напишите request access, follow-up, meeting recap
Day 4	Security findings	Опишите один finding: summary, impact, evidence, remediation
Day 5	Meetings	Проговорите standup update и фразы “I’m blocked by…”, “Could you clarify…”
Day 6	Interview	Подготовьте 3 STAR stories: conflict, failure, ambiguity
Day 7	Pronunciation	Запишите себя на 60 секунд и проверьте 10 сложных слов

Мини-рутина на 5 минут:

1 минута — 5 security terms вслух;
2 минуты — один status update;
1 минута — email opener + closing;
1 минута — одно tricky word через словарь с аудио.

Повторять две недели. Это скучнее, чем «выучу английский за месяц», но работает намного лучше.

Итог

Технический английский — это не про идеальные времена и не про отсутствие акцента.

Это про способность:

написать понятный емейл;
объяснить риск адекватными словами без шаблонов;
задать хороший вопрос на митинге;
дать status update за 1 минуты на утреннем stand up ;
описать blocker;
провести security review пончтными словами для всей команды;
пройти screening перед интервью;
рассказать о себе и показать свои сильыне стороны;
не теряться на созвоне;
звучать спокойно и профессионально, без пафоса.

Не обязательно говорить идеально. Важно говорить понятно.

Clarity beats perfection.

Я собрал для себя отдельную практическую шпаргалку по Technical English for Cybersecurity: письма, Slack/Teams, митинги, security reports, HR screening, interviews, pronunciation и короткие упражнения. Часть идей из неё использовал в этой статье.

А если нужен персональный разбор английской самопрезентации, CV или interview answers под конкретную IT/security-роль — контакты можно найти в профиле. ЕЕее, мен! Удачи! See you soon

Основы Product Security для автомобилей и зарядных станций: термины, архитектура, фреймворки

Ivan's Cybersecurity Notes — Wed, 02 Sep 2026 09:15:05 +0000

Preview

Современный автомобиль и зарядная станция — это уже не просто «железо», а сложные программно-аппаратные продукты, кратко можно сказать как "комп на колесах". В этой статье разберем базовые основные термины, архитектуру, ключевые фреймворки и типовые риски с точки зрения Product Security. Гоу!

Почему это может быть интересно и востребовано в индустрии?

EV, connected car, software-defined vehicle и зарядная инфраструктура сегодня находятся на стыке embedded-разработки, облачных сервисов, мобильных приложений, телематики, OTA-обновлений и эксплуатации в реальном мире. Поэтому и модель безопасности здесь отличается от классического веб-приложения.

Если в обычном SaaS мы чаще думаем об утечке данных, сломанной авторизации или уязвимой библиотеке, то в автомобильной и EV-среде последствия могут быть шире, а именно: нарушение работы систем, компрометация OTA-обновления, злоупотребление удалёнными командами, потеря доступности зарядной инфраструктуры или масштабная operational-проблема на уровне парка устройств. Если говорить проще и короче - это риск не только для авто как технического средства, но и риск для здоровья и жизни водителя\пассажиров если что-то "пойдет не так".

И почему же я пишу об этом? Моя тема ведь ProdSec и как это ложится на электронные тачки? А вот так. Product Security в этой области — это не только поиск багов. Это управление доверием, архитектурой, жизненным циклом ПО, облачными и встроенными компонентами, а также безопасностью операций.

Основы Product Security для автомобилей и зарядных станций: термины, архитектура, фреймворки и практические кейсы

Зачем вообще нужен отдельный разговор про Product Security в автомобилях и EVSE?

Порасуждаем об этом вместе. И так, господа, ниже самая база.

Автомобиль и зарядная станция сегодня — это не один компонент, а целая экосистема:

встроенное ПО и ECU;
внутренние шины и сети автомобиля;
телематика и удалённая связь;
мобильные приложения и веб-порталы;
облачный backend;
OTA-обновления;
аналитика и мониторинг;
поставщики аппаратных и программных компонентов;
эксплуатация и field-operations.

Именно поэтому вопрос «есть ли у нас уязвимость?» недостаточен.

Гораздо полезнее спрашивать так:

Может ли эта слабость повлиять на архитектуру доверия, жизненный цикл продукта или операционную безопасность?

Это уже язык Product Security.

1. Что такое современный автомобиль с программным управлением

Часто говорят, что современный автомобиль — это «компьютер на колёсах». В этом есть большая доля правды.

Внутри автомобиля работают десятки электронных блоков управления — ECU (Electronic Control Units). Они отвечают за разные функции:

движение и управление;
торможение и устойчивость;
комфорт и кузовные системы;
инфотейнмент;
телематику;
ADAS и автопилот-подобные функции;
управление батареей в EV.

Для Product Security важно понимать: автомобиль — это не только один ECU и не только прошивка. Это связанная система, где hardware, firmware, сети, облако, мобильный клиент и эксплуатационные процессы образуют единый продукт.

2. Что такое EVSE и почему это тоже Product Security-задача

EVSE (Electric Vehicle Supply Equipment) — это не только «зарядка как стойка». На практике речь идёт о связанной инфраструктуре:

зарядные станции;
прошивки и настройки устройств;
протоколы связи с backend;
операторский портал;
мобильное приложение клиента;
биллинг и тарифы;
управление сессиями зарядки;
OTA-обновления;
мониторинг и телеметрия.

С точки зрения Product Security это значит, что защита нужна не только веб-части или API, но и всему operational-контуру: устройствам, идентичности станции, удалённым командам, обновлениям и процессам восстановления.

3. Из чего состоит архитектура современного автомобиля и EV-экосистемы

Для вводной статьи удобно смотреть на систему в четырёх крупных слоях:

Пользовательский слой — водитель, пассажиры, мобильное приложение.
Автомобиль — ECU, инфотейнмент, телематика, ADAS, батарея и внутренние функции.
Сети и соединения — CAN/LIN/FlexRay, Automotive Ethernet, 4G/5G, Wi‑Fi/Bluetooth, GNSS.
Облако и сервисы — OTA, аналитика, удалённые команды, API, хранилища данных.

Из чего состоит архитектура современного автомобиля и EV-экосистемы

Эта модель полезна тем, что показывает: риски и контрольные меры распределены по нескольким уровням, а не только по «железу» или только по backend.

4. Базовые термины, которые стоит понимать

Ниже — набор терминов, без которых сложно говорить о теме предметно.

ECU (Electronic Control Unit)

Электронный блок управления, который отвечает за конкретную функцию автомобиля.

TCU (Telematics Control Unit)

Телематический блок, обеспечивающий связь автомобиля с внешним миром и облачными сервисами.

ADAS

Advanced Driver Assistance Systems — системы помощи водителю.

OTA (Over-the-Air)

Удалённая доставка обновлений программного обеспечения без физического посещения сервиса.

Infotainment

Системы мультимедиа, навигации, пользовательского интерфейса и цифрового опыта водителя/пассажира.

OCPP

Один из ключевых протоколов взаимодействия зарядной станции и backend-системы в экосистеме EVSE.

Firmware

Встроенное программное обеспечение устройств и блоков управления.

CAN / LIN / FlexRay / Automotive Ethernet

Ключевые автомобильные шины и сети для обмена данными между блоками.

SBOM

Software Bill of Materials — структурированный перечень компонентов, входящих в состав программного артефакта.

TARA

Threat Analysis and Risk Assessment — подход к анализу угроз и оценке рисков, распространённый в automotive security.

5. На что именно смотрит Product Security в этой области

Product Security в автомобилях и EVSE — это про то, как защищается продукт как система. Обычно внимание концентрируется вокруг нескольких тем.

5.1 Границы доверия и trust boundaries

Где система принимает внешние данные? Где кончается доверенная зона? Какие компоненты связывают автомобиль, облако, мобильное приложение и зарядную инфраструктуру?

5.2 Идентичность и аутентификация

Как устройство доказывает, что оно именно то, за кого себя выдаёт? Как аутентифицируется зарядная станция? Как защищаются привилегированные пользователи, администраторы и support-процессы?

5.3 Сегментация и архитектура

Могут ли менее доверенные компоненты повлиять на более чувствительные? Есть ли разумные границы между infotainment, телематикой, safety-adjacent и cloud-компонентами?

5.4 Обновления и жизненный цикл ПО

Как планируется, разрабатывается, тестируется, подписывается и выкатывается ПО? Как проходит OTA? Что будет при rollback? Как выглядит evidence-цепочка релиза?

5.5 Телеметрия, мониторинг и восстановление

Сумеет ли команда увидеть аномалию? Отличить outage от security-инцидента? Понять, какое обновление дошло до какой когорты устройств? Быстро откатить rollout?

6. Зоны доверия и границы безопасности

Один из лучших способов быстро понять систему — разложить её по trust zones.

Зоны доверия и границы безопасности

Упрощённо модель выглядит так:

Внешний мир — интернет, атакующие, вредоносные сайты, сторонние приложения.
Пограничные системы — телематика, VPN/TLS, firewall, IDS/IPS.
Внутренние сети автомобиля — CAN FD, FlexRay, LIN, Automotive Ethernet, ECU по доменам.
Облако и backend — API gateway, сервисы аутентификации, OTA, аналитика.

Для Product Security здесь критично не просто «закрыть доступ», а понять, как перемещается доверие и где нужна сегментация, микросегментация, проверка идентичности и мониторинг.

7. Жизненный цикл ПО и OTA-обновлений

Product Security почти всегда должен смотреть на продукт не только в рантайме, но и по всему SDLC.

Жизненный цикл ПО и OTA-обновлений

Типовой поток выглядит так:

Планирование и требования безопасности.
Разработка и secure coding.
Сборка и SBOM / анализ зависимостей.
Тестирование, включая security testing.
Подписание артефактов и контроль целостности.
Выпуск и одобрение релиза.
Доставка OTA по когортам.
Эксплуатация, телеметрия и обратная связь.

Почему это важно? Потому что в software-defined vehicle и EVSE мире релиз — это уже не просто кнопка deploy. Ошибка в release governance может превратиться в масштабную проблему в field.

8. Ключевые фреймворки и ориентиры

Для вводного уровня полезно знать несколько ориентиров, которые регулярно всплывают в реальной практике.

ISO/SAE 21434

Один из ключевых отраслевых стандартов по automotive cybersecurity engineering.

UNECE R155

Регуляторная основа, которая продвинула идею системного управления кибербезопасностью автомобиля на уровне процессов и жизненного цикла.

UNECE R156

Связана с управлением обновлениями ПО и организацией software update management.

TARA

Подход к анализу угроз и рисков: что атакуемо, каковы последствия, каков приоритет контрмер.

Secure SDLC / DevSecOps

Критично для backend, cloud, mobile apps, CI/CD, OTA и цифровых платформ вокруг автомобиля или EVSE.

Zero Trust / Least Privilege

Полезны как принципы для аутентификации, сервисных аккаунтов, облачных ролей и управления доступом.

9. Типовые риски и сценарии атак

Ниже — типовые категории рисков, о которых стоит думать Product Security-команде.

Типовые риски и сценарии атак

9.1 Компрометация цепочки поставок

Уязвимые зависимости, подмена артефактов, небезопасные поставщики, слабые процессы подписи и сборки.

9.2 Уязвимости ECU и прошивки

Ошибки в embedded-компонентах, небезопасная логика обновлений, проблемы с целостностью firmware.

9.3 Атаки на сети автомобиля

Неправильная сегментация, слабые точки на boundary-компонентах, избыточное доверие между доменами.

9.4 Компрометация OTA

Недостаточно защищённая цепочка release → signing → delivery → rollout → rollback.

9.5 Облачные угрозы

Слабая авторизация, избыточные IAM-права, ошибки в API, проблемы с secrets и CI/CD.

9.6 Физический доступ

Доступ к диагностическим интерфейсам, локальным портам, устройствам, стендам, станции или внутренней инфраструктуре.

Типовые последствия при этом тоже выходят за рамки «утечки данных»:

потеря управления отдельными функциями;
нарушение работы систем;
недоступность сервиса;
финансовые потери;
репутационный ущерб;
риск безопасности людей.

10. Практические кейсы, которые повлияли на индустрию

Кейс 1. Исследования удалённой компрометации connected car

Публичные исследования, показавшие возможность удалённого воздействия на connected car через внешнюю поверхность атаки, сильно повлияли на индустрию. Они наглядно продемонстрировали, что проблема не ограничивается одной прошивкой или одним ECU: уязвимость в boundary-компоненте или телематическом контуре может иметь большие последствия.

Почему это было важно:

стала очевиднее необходимость security-by-design;
усилилось внимание к сегментации и boundary-компонентам;
выросла роль процессов OTA, мониторинга и coordinated response.

Кейс 2. Relay-атаки и злоупотребление цифровым доступом

Даже если атака не выглядит как «взлом прошивки», она всё равно может менять восприятие модели риска. Кейсы с relay-атаками и злоупотреблением системами доступа показали, что автомобиль — это не только software bug, но и продуктовая модель доверия.

Что это изменило:

вырос интерес к layered security;
стало важнее смотреть на пользовательские сценарии злоупотребления;
Product Security пришлось теснее работать с hardware, UX и operational-командами.

Кейс 3. EVSE и exposed charging infrastructure

В экосистеме зарядных станций исследователи неоднократно показывали, что слабые настройки, дефолтные учётные данные, неправильная аутентификация или проблемы на backend-стороне способны повлиять не только на данные, но и на реальные charging operations.

Почему это важно:

зарядная станция — это cyber-physical asset;
backend API, cloud, support-процессы и device identity становятся критичными;
одна ошибка может масштабироваться сразу на парк устройств.

11. Как мыслит Product Security-лид в этой теме

Хороший Product Security-подход в automotive и EVSE обычно задаёт такие вопросы:

Какие компоненты являются crown jewels?
Где находятся boundary-системы?
Какие удалённые действия вообще разрешены?
Как защищается release path?
Можно ли доказать происхождение артефакта?
Какие действия требуют step-up authentication или dual control?
Есть ли безопасный rollback?
Достаточно ли telemetry и detection?
Как быстро команда поймёт, что происходит в field?

Эти вопросы переводят разговор из «есть ли CVE» в «можем ли мы безопасно управлять продуктом». Именно это и есть язык Product Security.

12. С чего начать новичку или лидеру, который входит в тему

Если тебе нужно быстро сориентироваться в теме, я бы рекомендовал идти в такой последовательности:

Понять базовую архитектуру автомобиля, EVSE и cloud-экосистемы.
Разобраться с жизненным циклом ПО и OTA.
Освоить базовые термины: ECU, TCU, ADAS, OCPP, OTA, SBOM, TARA.
Посмотреть на trust boundaries и product authority.
Разобрать 3–5 типовых attack-chain сценариев.
Понять, как сочетаются embedded, cloud, mobile и operational controls.
Научиться говорить о риске не только языком уязвимостей, но и языком воздействия, обнаружения и восстановления.

13. Final thought

Безопасность автомобиля, software-defined vehicle и зарядной инфраструктуры — это уже давно не только задача embedded-инженеров и не только задача AppSec.

Это область, где встречаются:

архитектура;
безопасная разработка;
cloud security;
OTA governance;
identity и trust;
supply chain;
device security;
operational resilience.

Именно поэтому Mindset Product Security здесь особенно полезен: он помогает смотреть на продукт не как на набор разрозненных компонентов, а как на систему, которую нужно безопасно проектировать, выпускать, обновлять, эксплуатировать и восстанавливать.

и еще несколько слов в заключение

Эта статья — вводный обзор и часть более крупной работы, которую я сейчас финально полирую: брошюры по безопасности электромобилей и зарядных станций. В полной версии материал глубже раскрывает архитектуру, attack-chain thinking, Product Security operating model, OTA governance, OTA/EVSE риски, практические контрольные меры и управленческий взгляд на тему. выйдет в релиз осенью 2026 года, так что следите за новостями!

И, YO, гайс, кто еще не знает также я публикую полезные материалы, заметки и ссылки по кибербезопасности в моем Telegram-канале White2Hack. Join and be safer

Теги: product security, automotive security, EV, EVSE, OCPP, OTA, ECU, SBOM, secure SDLC, DevSecOps

От нетворкинга к MVP: как мы превратили боль русскоязычных newcomers в США в концепт TaxBridge

Ivan's Cybersecurity Notes — Sat, 25 Jul 2026 15:37:51 +0000

О ЧЕМ МАТЕРИАЛ:

Здарово, парни! на ссязи Ivan | White2hack

Эта статья не про «успешный успех», не про очередной стартап с нищеброда до миллионера:) который уже завтра должен стать единорогом, и не про то, что всем срочно нужно бежать в какую-то ассоциацию, чтобы через неделю получить оффер, инвестиции и команду мечты.

Она про более спокойную, но очень практическую вещь: как профессиональное окружение помогает превратить разрозненную боль юзеров в работающий продуктовый MVP. И я сам прошел это на собственном пути! Так что есть о чем рассказать)) Погнали?

СУТЬ МАТЕРИАЛА КОРОТКО

История началась не с pitch deck, как это часто бывает. Она началась с обычного профессионального роста: чтения, статей, курсов, самообучения, разговоров с инженерами, обсуждений в комьюнити и постепенного расширения круга людей, с которыми можно говорить не только о вакансиях, но и о реальных проблемах, которые можно решить продуктом.

В какой-то момент я оказался внутри международной IT Association Grow Cluster. Там были разработчики, дизайнеры, архитекторы, специалисты по безопасности, люди, которые уже запускали проекты, и те, кто только искал следующую сильную идею. Мы начали общаться, обмениваться опытом и довольно быстро увидели пересечение: миграция, адаптация в США, первые документы, первый налоговый год, языковой барьер и страх перед системой, которая для новичка выглядит непрозрачно.

Но у сильной идеи есть ещё один неприятный момент: одного нетворкинга мало, это правда. Люди могут увидеть проблему, собрать гипотезу, накидать первые экраны и даже договориться о ролях, но для превращения идеи в MVP почти всегда нужен второй слой — акселерационный: разбор проекта, деньги (о, да как же без них:), документы, юридико-организационная рамка, бренд, договорённости, упаковка для партнёров и инвесторов.

В нашем случае таким слоем стал Startup-accelerator KrokIT. Если Grow Cluster помог собрать вокруг идеи людей, доверие и профессиональный контекст, то KrokIT помог посмотреть на TaxBridge уже как на проект: что именно мы строим, за счёт чего это может быть полезно, где проходит граница MVP, какие документы нужны, как упаковать идею для партнёров, как думать о pre-seed / seed-логике и что нужно подготовить, чтобы проект можно было показывать не только друзьям из комьюнити, но и потенциальным клиентам, партнёрам или инвесторам.

Для меня это важное различие: community рождает доверие и команду, accelerator помогает превратить это в проектную дисциплину.

Так появился концепт TaxBridge — bilingual tax onboarding platform для русскоязычных newcomers в США.

DISCLAIMER

!!!Сразу важная граница!!!: TaxBridge — это не “замена CPA”, не legal advice, не tax advice и не “магическая кнопка отправить декларацию в IRS”. В текущей версии это продуктовый концепт / визуальный прототип tax-readiness layer: он помогает пользователю понять вероятный filing route, организовать документы, получить summary / organizer и при необходимости передать всё на professional review.

Именно эта граница делает кейс интересным для инженерной аудитории. Потому что в чувствительных доменах хороший продукт начинается не с автоматизации всего подряд, а с вопроса: что мы можем упростить безопасно, честно и полезно?

Коротко, если читать по диагонали ( TL;DR так сказать)

Нетворкинг полезен не потому, что «у кого-то есть связи», а потому что он создаёт граф доверия, в котором идеи быстрее проходят проверку реальностью.
TaxBridge родился из пересечения нескольких компетенций: migration context, UX, frontend/prototyping, product thinking, security и понимания боли русскоязычных newcomers.
Мы не пытались построить полноценный tax filing engine. На уровне MVP гораздо разумнее было проверить guided onboarding → route assessment → document checklist → organizer/report → human review.
Главная продуктовая идея: newcomer не всегда готов сразу «заполнять декларацию». Сначала ему нужна карта: где он находится, какие документы нужны, какие риски есть, где можно self-service, а где нужен специалист. Экономим деньги, время и нервы! Profit
В таких продуктах security, privacy, объяснимость и legal boundaries должны появляться в самом начале, а не после релиза.
После того как идея прошла первичную проверку внутри профессионального круга, понадобился акселерационный слой: разбор проекта, финансирование, документы, бренд, юридико-организационный контур, подготовка материалов для партнёров и логика pre-seed / seed-переговоров.

Нетворкинг — это не список контактов. Это инфраструктура доверия.

В такой инфраструктуре важны пять вещей. Смотрим внимательно.

Что важно	Как это проявляется на практике
Контекст	Люди понимают, чем ты занимаешься, где твоя экспертиза, а где твои ограничения.
Повторяемость	Вы общаетесь не один раз, а возвращаетесь к идеям, ошибкам и результатам.
Разные роли	Разработчик, дизайнер, founder, security engineer и domain expert видят одну проблему по-разному.
Честная обратная связь	Кто-то может сказать: «это слишком сложно для MVP», «здесь риск legal advice», «здесь нужен human review».
Доступ к реальным историям	Самые ценные инсайты часто приходят не из отчётов, а из опыта людей, которые уже проходили похожую боль.

В Grow Cluster это стало особенно заметно. Когда в одном кругу появляются разработчики, дизайнеры, архитекторы, security-специалисты и люди с миграционным опытом, идея перестаёт быть заметкой в блокноте. Она начинает проходить через фильтр разных компетенций.

И это очень похоже на нормальный engineering process: гипотеза, feedback, constraints, risk assessment, iteration.

Слой	Что дал проекту	Почему это важно
Grow Cluster IT Association	Люди, доверие, разные роли, профессиональный контекст, первые обсуждения, обратная связь.	Идея перестала быть заметкой в блокноте и прошла через фильтр разработчиков, дизайнеров, security-специалистов, архитекторов и людей с миграционным опытом.
Startup-accelerator KrokIT	Разбор проекта, акселерационную рамку, финансирование, помощь с документами, упаковкой, брендом, регистрационным и инвестиционным контуром.	Идея начала превращаться в проект, который можно показывать партнёрам, потенциальным клиентам и инвесторам.
Партнёрская экосистема	Возможность рассматривать TaxBridge не как изолированное приложение, а как onboarding / tax-readiness слой внутри более широкой системы услуг.	MVP получает не только экраны, но и потенциальный канал внедрения, проверки и дальнейшего масштабирования.

Пользовательская боль: первый налоговый год в США выглядит страшнее, чем должен

Для человека, который недавно переехал в США, особенно если он говорит по-русски и ещё не привык к локальной терминологии, налоговая система часто выглядит как набор несвязанных слов:

resident alien / nonresident alien;
green card test;
substantial presence test;
Form 1040 / Form 1040-NR;
W-2 / 1099;
federal return / state return;
estimated payments;
foreign accounts;
self-employment;
filing status;
dependents;
ITIN / SSN.

Проблема не только в английском языке. Проблема в том, что пользователь не понимает модель принятия решений. Юзер, он же клиент - это же обычной парень ка к ты и я только что имитировавший, откуда ему ведать все тонкости налоговой системы США?

Ему не всегда нужно сразу заполнять форму. Сначала ему нужно понять:

какой у него вероятный tax residency status;
какие документы вообще нужны;
где сценарий простой, а где уже нужен специалист;
какие вопросы критичны для routing;
что можно подготовить самому
что нельзя автоматизировать без риска;
когда стоит идти к CPA, EA или другому professional reviewer.

IRS описывает базовую рамку так: если человек не является гражданином США, он считается nonresident для целей U.S. tax, пока не проходит один из двух тестов — green card test или substantial presence test. При этом возможны исключения и специальные сценарии, включая dual-status year, closer connection, treaty logic и другие ситуации, которые нельзя аккуратно закрыть простым UX-текстом.

Именно здесь появилась продуктовая гипотеза:

Что если делать не «ещё один tax filing tool», а спокойный tax-readiness layer для первого шага?

Первая формулировка продукта: не “налоговый комбайн”, а onboarding layer

TaxBridge мы не думали как универсальный сервис «сделаем всё за вас». Это опасная ловушка для раннего MVP, особенно в домене, где ошибка может стоить пользователю денег, времени и нервов.

Идея была другой:

Дать пользователю понятный bilingual flow, который превращает хаос первого налогового года в структурированный маршрут: interview → likely filing route → document checklist → organizer/report → self-service или handoff к специалисту.

Это звучит менее громко, чем “AI-powered tax automation platform”. Зато это ближе к реальной боли.

На уровне продукта мы выделили четыре базовых сценария.

Сценарий	Что хочет пользователь	Что должен сделать продукт
Tax Interview	Ответить на вопросы простым языком.	Собрать контекст: residency, income, state, dependents, accounts, forms.
Filing Route Assessment	Понять вероятный путь.	Показать route, confidence, risk flags и next steps.
Document Checklist	Не забыть документы.	Разделить документы на required / missing / optional / under review.
Reports & Organizer	Получить понятный результат.	Сформировать readable summary / organizer для self-filing или reviewer handoff.

Ключевое решение было простым: не начинать с “заполните форму”, а начинать с “давайте разберём вашу ситуацию”.

Для человека, который только переехал, это психологически намного важнее, чем кажется. Он не хочет ещё одну сложную систему. Он хочет сначала почувствовать, что у него появилась карта.

Persona и Jobs To Be Done: без этого MVP легко становится игрушкой

Одна из правок, которую я бы обязательно сделал в любой такой истории: нельзя описывать продукт только через фичи. Нужно описывать пользователя и его задачу. Условная persona для TaxBridge выглядела бы так:

Русскоязычный newcomer в США. Недавно получил green card, переехал или находится в переходном статусе, работает по найму или как self-employed, плохо понимает американскую tax terminology, боится пропустить важный документ и не хочет сразу платить за дорогую консультацию, если его сценарий простой.

Его job-to-be-done можно сформулировать так:

«Когда я впервые сталкиваюсь с U.S. tax season, я хочу понять свой вероятный filing route и список документов простым языком, чтобы не паниковать, не потерять сроки и прийти к self-filing или специалисту уже подготовленным».

Persona / JTBD: фокус MVP

Вопрос	Правильный фокус MVP
Пользователь хочет «налоговую магию»?	Нет. Он хочет понятный первый шаг.
Ему нужен полный tax engine?	Не на первом этапе.
Ему нужна форма 1040 прямо сейчас?	Иногда да, но чаще сначала нужен routing и checklist.
Нужно ли обещать filing?	Нет, если нет production-grade compliance и professional review.
Что можно дать безопасно?	Education, organizer, document clarity, next steps, risk flags.

Именно поэтому TaxBridge лучше описывать как tax-readiness / onboarding product, а не как tax filing replacement.

Scope и non-goals: что мы делаем и чего сознательно не делаем

Для MVP в чувствительном домене список non-goals не менее важен, чем список features. И так, глянем что мы сверстали как базу:

В scope MVP	Не в scope MVP на раннем этапе
Guided interview	Автоматическая подача декларации в IRS.
Bilingual explanations	Налоговая консультация.
Likely filing route	Юридическое заключение.
Document checklist	Гарантия правильности filing strategy.
Risk flags	Полная замена CPA / EA / tax professional.
Organizer / report	Обработка всех сложных cross-border сценариев.
Handoff to reviewer	Интерпретация tax treaties без эксперта.

На ранней стадии продукту не нужно казаться всемогущим. Ему нужно быть полезным и честным.

Почему bilingual UX — это не перевод кнопок

Если продукт ориентирован на русскоязычных пользователей, кажется, что достаточно перевести интерфейс. Но в tax workflow перевод — это только часть работы.

Настоящая сложность в другом: надо переводить не слова, а ментальную модель.

Пользователь может понимать, что такое «налоговая декларация» в своей стране, но не понимать:

почему в США есть federal и state filing;
почему tax residency не всегда совпадает с бытовым пониманием иммиграционного статуса;
почему W-2 и 1099 ведут к разным вопросам;
почему self-employment меняет набор документов и рисков;
почему один и тот же человек в год переезда может попасть в сложный сценарий;
почему система иногда должна сказать: «дальше нужен professional review».

Хороший bilingual UX должен делать несколько вещей одновременно:

сохранять английские термины там, где они нужны для документов;
давать русское объяснение без искажения смысла;
показывать, где продукт уверен, а где нужна проверка;
не создавать иллюзию налогового совета;
не превращать интерфейс в учебник на 200 страниц.

MVP: что именно нужно было проверить

В ранних продуктах самая опасная ошибка — перепутать MVP с маленькой версией большой мечты.

MVP TaxBridge не должен был сразу стать competitor to TurboTax или production tax filing engine. Для такой задачи нужны более серьёзные процессы: tax expertise, legal review, e-file integration, identity controls, audit, compliance, support, incident response и многое другое.

На первом этапе нас интересовали другие вопросы. Заценим их кратко:

Гипотеза	Как можно проверить
Пользователь понимает ценность structured onboarding.	Проходит ли он interview до конца.
Bilingual flow снижает тревожность.	Может ли пользователь объяснить next step своими словами.
Route summary полезен.	Сохраняет ли пользователь report / organizer.
Checklist уменьшает хаос.	Загружает ли пользователь документы по категориям.
Risk flags помогают, а не пугают.	Понимает ли пользователь, почему нужен reviewer.
Handoff к специалисту ценен.	Может ли reviewer быстрее разобраться в ситуации.

Это нормальный MVP-вопрос. Не «можем ли мы автоматизировать всю налоговую систему», а можем ли мы сделать первый шаг менее страшным и более структурированным.

Как выглядела логика продукта

Условно TaxBridge можно разложить на несколько слоёв. Это упрощенно, но для понимая на старте хватит.

Слой	Задача	Почему это важно
Landing layer	Объяснить продукт за 30–60 секунд.	Пользователь должен быстро понять, что это onboarding tool, а не «налоговая магия».
Interview layer	Собрать базовый контекст.	Residency, income, state, dependents, documents, risk conditions.
Decision-support layer	Показать вероятный filing route.	Не финальный tax advice, а structured recommendation / next step.
Document layer	Собрать и упорядочить документы.	У пользователя появляется checklist вместо хаоса.
Report layer	Сформировать organizer.	Его можно использовать самому или передать reviewer.
Handoff layer	Понять, когда нужен человек.	Сложные сценарии не надо притворно автоматизировать.
Knowledge layer	Объяснять термины.	Пользователь учится на каждом шаге.
Security layer	Защитить данные и ожидания.	Налоговые документы и персональные данные требуют осторожности.

На скриншотах это выглядит как обычное приложение: dashboard, interview, documents, reports, organizer, secure sharing, version history.

Но важнее не экраны. Важнее то, что за ними есть процесс:

text Newcomer context
↓
Guided interview
↓
Decision-support logic
↓
Risk flags + explainability
↓
Document checklist ↓ Organizer / report
↓
Self-service OR professional review

Как выглядела логика продукта

Если убрать из этой схемы explainability или human review, продукт быстро станет опаснее. Если убрать document layer, он станет просто красивой анкетой. Если убрать risk flags, пользователь может уйти с ложной уверенностью.

Почему report иногда ценнее, чем submit

В consumer-продуктах часто хочется сразу прийти к финальному действию: нажал кнопку — всё отправилось.Но в чувствительных сценариях такой подход может быть опасным. Для налогового онбординга новичка важен промежуточный артефакт: организованный report / organizer.

Он может содержать:

базовый профиль пользователя;
tax year;
предполагаемый filing route;
причины, почему система предложила этот route;
список recommended forms;
список missing documents;
risk flags;
next steps;
данные, которые можно проверить до финального filing.

Такой артефакт полезен сразу нескольким сторонам.

Кому полезен organizer	Почему
Пользователю	Он наконец видит структуру, а не хаос документов.
Reviewer	Он не начинает консультацию с нуля.
Support-команде	Меньше хаотичных вопросов и скриншотов в мессенджере.
Product-команде	Видно, где пользователи чаще всего застревают.

С точки зрения product thinking, report — это не «документ ради документа». Это boundary object: общий артефакт, через который пользователь, продукт и специалист могут говорить на одном языке.

Что в таком продукте нельзя делать бездумно

Когда продукт касается tax workflow, особенно для иммигрантов, есть несколько красных зон.

1. Нельзя выдавать предположение за tax advice

Можно объяснить вероятный route. Можно показать risk flags. Можно сформировать organizer. Но если сценарий сложный, продукт должен честно отправлять к специалисту.

2. Нельзя обещать экономию любой ценой

Да, хороший onboarding может снизить хаос и уменьшить количество лишних консультаций. Но цель не в том, чтобы любой ценой заменить CPA или tax professional. Цель — чтобы человек пришёл подготовленным и понимал, где self-service уместен, а где нет.

3. Нельзя забывать про privacy

Налоговый продукт почти сразу касается sensitive data: identity, SSN/ITIN, address, income, bank statements, foreign accounts, immigration-related context. Даже если это MVP, нельзя относиться к таким данным как к обычной форме обратной связи.

4. Нельзя строить интерфейс только вокруг forms

Новичку нужна не форма. Ему нужна последовательность: answer → understand → prepare → move forward.

5. Нельзя игнорировать explainability

Если система показывает “Likely Resident Alien” или “Federal 1040 + State Return”, пользователь должен понимать, почему. Иначе это не product guidance, а ещё один чёрный ящик.

6. Нельзя скрывать uncertainty

В некоторых сценариях продукт обязан сказать: «мы не можем дать уверенный route без professional review». Это не слабость продукта. Это признак зрелости.

Product Security угол: мой выход:)

Поскольку мой основной профессиональный фокус связан с Product Security, я не могу смотреть на такой продукт только как на UX или business idea. Если MVP двигается дальше в production, security baseline должен появиться до сбора настоящих документов.

Область	Что нужно предусмотреть
Data minimization	Не собирать данные, которые не нужны для route assessment / organizer.
Encryption	Шифрование чувствительных данных at rest и in transit.
Access control	Разделение ролей: user, reviewer, support, admin.
Secure sharing	Time-limited links, revocation, audit trail.
Audit log	Кто смотрел, скачивал, изменял, отправлял.
Retention	Ясная политика хранения и удаления документов.
Secrets management	Никаких ключей и токенов в frontend/build artifacts.
Abuse cases	Что если ссылку переслали, аккаунт украли, пользователь загрузил чужой документ.
Legal boundaries	Чёткая маркировка: где education / organizer, а где professional advice.
Incident readiness	План реакции на утечку или неправильный access.

Отдельно я бы сделал маленький threat model ещё до production.

Threat / abuse case	Почему важно	Возможный control
Пользователь делится secure link не с тем человеком.	В report могут быть sensitive данные.	Expiring links, revocation, access log.
Reviewer получает больше данных, чем нужно.	Риск privacy exposure.	Role-based access, scoped sharing.
Пользователь загружает чужой документ.	Legal/privacy risk.	Warnings, document ownership attestation.
Неверный route выглядит слишком уверенно.	Пользователь может принять неправильное решение.	Confidence, reasoning, escalation to reviewer.
Данные хранятся бесконечно.	Ненужный риск компрометации.	Retention policy, deletion flow.
Саппорт видит sensitive data без необходимости.	Internal misuse / accidental exposure.	Support redaction, least privilege.

Это тот случай, где Product Security — не отдельный отдел. Это часть product design.

Где здесь no-code, low-code и обычная Dev разработка

Ранние MVP часто выглядят не так героически, как хочется рассказывать на конференциях.

Часть продукта можно собрать как статический лендинг. Часть — как интерактивный UI-прототип. Часть — как no-code/low-code flow. Часть — как обычный frontend. Часть логики на первом этапе вообще может быть полу-ручной, если цель — проверить пользовательский сценарий, а не сразу построить production-grade tax engine. И это нормально. Едем дальше!

No-code — это не “несерьёзно”. Несерьёзно — это строить дорогую архитектуру до того, как ты проверил, нужна ли людям твоя логика.

Для такого MVP гораздо важнее:

быстро собрать понятный flow;
проверить формулировки;
увидеть, где пользователь путается;
понять, какие документы он реально может подготовить;
выяснить, где нужен human review;
собрать обратную связь от людей из целевой аудитории.

После этого уже можно думать о полноценной архитектуре: backend, rules engine, encrypted storage, audit logs, secure sharing, role-based access, retention policy, integrations, e-file provider, compliance review и так далее.

MVP-архитектуру без пафоса

На ранней стадии архитектура TaxBridge могла бы быть такой.

text Landing / acquisition ↓ Guided interview UI ↓ Rules / decision-support layer ↓ Risk flags + explanations ↓ Document checklist / upload flow ↓ Report generator ↓ Secure sharing / reviewer handoff ↓ Analytics + feedback loop

Главное здесь — не стек. Главное — разделение ответственности.

Компонент	Главный вопрос
Interview UI	Понимает ли пользователь вопрос?
Rules layer	Почему система предлагает этот route?
Document layer	Какие документы нужны и зачем?
Report generator	Можно ли передать результат человеку?
Secure sharing	Кто получил доступ и на сколько времени?
Analytics	Где пользователи застревают?
Reviewer flow	Где автоматизация должна остановиться?

Если делать production-версию, я бы не начинал с «давайте подключим всё ко всему». Я сначала добился сильного ядра: interview → route reasoning → checklist → organizer → review.

Где помогла IT Association

Самое интересное в этой истории для меня — не сам интерфейс. Интерфейсы можно нарисовать, лендинг можно собрать, прототип можно сверстать.

Гораздо важнее то, как идея стала возможной благодаря профессиональному кругу.

В одиночку человек часто застревает в одном из режимов:

инженер видит архитектуру, но не всегда видит go-to-market;
дизайнер видит flow, но ему нужен доменный контекст;
founder видит рынок, но ему нужен реалистичный технический scope;
security-специалист видит риски, но может слишком рано усложнить MVP;
domain expert видит боль, но не всегда понимает, как превратить её в продукт.

Когда эти люди начинают говорить друг с другом, появляется баланс.

В нашем случае ассоциация дала не «волшебную команду», а гораздо более важную вещь — среду доверия. Там можно было обсуждать идею не как pitch, а как рабочую гипотезу:

кому это нужно;
какая боль первична;
какой scope реалистичен за несколько месяцев;
что не стоит обещать;
где нужен человек, а не automation;
как показать продукт партнёрам;
как объяснить идею без агрессивного маркетинга.

Так за несколько месяцев из разговоров, черновиков, обсуждений, экранов и итераций родился MVP-концепт, который можно показать пользователю, партнёру, команде или потенциальному интегратору.

Где помог Startup-accelerator KrokIT

Если IT Association дала среду доверия, то акселератор помог добавить к этой истории проектную дисциплину.

В какой-то момент стало понятно: у нас есть боль, есть аудитория, есть первые экраны, есть люди, которые готовы обсуждать продукт всерьёз. Но между «у нас есть хорошая идея» и «у нас есть MVP, который можно показывать партнёрам» лежит довольно большая прослойка работы.

Там появляются вопросы, которые уже не решаются только дружеским обсуждением:

как описать проект так, чтобы его понял не только разработчик;
сколько денег нужно на первый полезный MVP;
что именно входит в MVP, а что надо сознательно отложить;
как упаковать продукт для партнёров, клиентов и потенциальных инвесторов;
какие документы нужны для бренда, компании, договорённостей и инвестиций;
как говорить про pre-seed / seed, не превращая продукт в фантазию про будущего единорога;
где проекту нужен юридический, финансовый или организационный контур.

Именно здесь оказался полезен Startup-accelerator KrokIT. Он помог не просто «поверить в идею», а разобрать её как проект: оценить реалистичность, подготовить пакет материалов, подумать о финансировании, о юридико-организационной части, о регистрации бренда / компании, о возможной структуре инвестиционных договорённостей и о том, как этот MVP может жить внутри партнёрской экосистемы.

В таком виде история становится честнее. TaxBridge появился не потому, что кто-то однажды сказал: «давайте сделаем стартап». Он появился из связки трёх вещей:

личное самообучение и погружение в проблему;
профессиональное сообщество, где появились люди, доверие и обратная связь;
акселерационная поддержка, которая помогла перевести идею в проектный формат.

Это хороший урок для начинающих founder'ов: нетворкинг может привести к людям и идее, но дальше всё равно нужна дисциплина — scope, документы, деньги, ответственность, roadmap, договорённости и нормальная упаковка проекта

Я вижу это так:

Grow Cluster помог найти людей и контекст. KrokIT помог превратить идею в проект, который можно обсуждать с партнёрами, клиентами и инвесторами.

Что в этой истории увидит стартапер, студент и состоявшийся ИТ\ИБ эксперт

Я специально добавил этот раздел, потому что один и тот же кейс полезен разным читателям по-разному.

Если вы стартапер

Главный вывод: не начинайте с фичей, начните с ограничения обещаний.

В regulated / sensitive domain пользовательская боль может быть большой, но это не значит, что продукт должен сразу обещать полный outcome. Иногда правильный продукт — это не “мы всё сделаем за вас”, а “мы поможем вам безопасно пройти первый слой неопределённости”.

Для стартапа это не слабая позиция. Это способ не утонуть в рисках до первой проверки гипотезы.

Если вы студент или начинающий специалист

Главный вывод: pet project становится сильнее, когда у него есть реальная боль.

Сделать dashboard можно за выходные. Сделать dashboard, который помогает реальному человеку понять сложный процесс, — совсем другой уровень. Здесь нужны тексты, интервью, ограничения, security thinking, empathy, domain research и способность объяснять.

Это и есть разница между «я написал интерфейс» и «я начал мыслить как product engineer».

Если вы уже состоявшийся эксперт в найме

Главный вывод: community projects могут прокачивать не только портфолио, но и leadership.

Когда вы участвуете в таком проекте, вы учитесь:

формулировать scope;
спорить без разрушения команды;
объяснять риски не-security людям;
принимать компромиссы;
видеть продукт шире своей специализации;
понимать, где автоматизация должна остановиться.

Это навыки, которые очень трудно прокачать только через Jira tickets.

Если вы техлид или CTO

Главный вывод: MVP в sensitive domain требует не меньше дисциплины, чем enterprise-проект, просто дисциплина другая.

На ранней стадии не нужны все controls сразу. Но нужны правильные границы: data minimization, no false advice, review escalation, audit thinking, retention thinking, secure-by-design mindset.

Метрики: как понять, что такой продукт действительно полезен

Чтобы статья не оставалась красивой историей, важно спросить: как вообще измерять пользу такого MVP? Хм.. и вот что я тогда выбрал с командой.

Возможный набор метрик:

Метрика	Что показывает
Interview completion rate	Достаточно ли понятен flow.
Time to first route	Быстро ли пользователь получает первый meaningful result.
Checklist completion rate	Помогает ли продукт собрать документы.
Report download / share rate	Ценен ли organizer как артефакт.
Reviewer handoff rate	Где автоматизация упирается в сложность.
Support questions per user	Уменьшается ли хаос.
User confidence after flow	Стало ли пользователю понятнее, что делать дальше.
False confidence incidents	Не создаёт ли продукт опасную уверенность.
Sensitive data deletion requests	Понятен ли пользователю контроль над данными.

Последняя метрика особенно важна. В sensitive-домене нельзя мерить успех только conversion rate. Иногда хороший продукт должен не конвертировать, а остановить пользователя и отправить его к специалисту.

Почему это не история про “мы стали единорогом”

Мне неинтересно делать вид, что каждый MVP обязан закончиться большим раундом, взрывным ростом или публикацией в TechCrunch (а было бы круто, конечно:)

Иногда хороший результат выглядит намного спокойнее:

мы нашли конкретную боль;
собрали людей вокруг идеи;
быстро сделали концепт (pre-MVP);
проверили, как это может выглядеть в продукте;
поняли границы автоматизации, посчитали cost проекта;
получили материал для дальнейших разговоров, подготовили MVP Product Brief;
увидели, как это можно встроить в партнёрскую экосистему (ИТ Акселератор как точка старта);
сделали что-то полезное для своей аудитории.

Это уже много. Я со-владелец продукта! Ееее, парни, свершилось! :)

Отдельно важным результатом стало то, что проект прошёл не только community-фильтр, но и accelerator-фильтр. Это разные вещи. В комьюнити ты проверяешь боль, язык, роли и доверие. В акселераторе — упаковку, деньги, документы, партнёрскую применимость, инвестиционный сценарий и реалистичность следующего шага.

Именно эта связка сделала историю более взрослой: не просто “мы придумали приложение”, а “мы прошли путь от боли и разговоров до проектного пакета, MVP-логики и потенциальной интеграции в партнёрскую экосистему”.

Для меня TaxBridge — это не история про быстрые деньги. Это история про то, как профессиональный рост, нетворкинг и доверие могут привести к практическому результату. И, как видно, разговор шире чем кибербез (хотя как же без него обойтись:)

Да, такой продукт можно развивать дальше. Его можно масштабировать. Его можно интегрировать в более крупную платформу. Его можно передать компании, у которой уже есть compliance, tax expertise и distribution. Его можно оставить как onboarding layer внутри партнёрской экосистемы.

Но даже как MVP он уже показывает важную мысль: сообщество может быть не только местом для разговоров, но и местом, где идеи становятся продуктами.

Практический чеклист: если вы хотите повторить такой путь

Не обязательно делать tax product. Логика применима почти к любому сложному домену. Помни: я смог, ты тоже сможешь!(если готов)

1. Найдите боль, которую можно объяснить одним абзацем

Если вы не можете простыми словами объяснить, кому больно и почему, вы пока не нашли продуктовую проблему.

2. Соберите маленький круг людей с разными углами зрения

Нужны не только разработчики. Нужны люди, которые видят UX, рынок, домен, безопасность, ограничения и коммуникацию.

3. Опишите non-goals

Что вы точно не делаете? Что не обещаете? Где нужен человек? Где продукт должен остановиться?

4. Сделайте артефакт, который можно показать (pre MVP)

Landing, prototype, clickable flow, report mockup, decision tree, checklist — что угодно, что делает идею обсуждаемой.

5. Проверьте не “нравится ли”, а “стало ли понятнее”

Хороший вопрос пользователю: «Что вы теперь будете делать следующим шагом?» Если он не может ответить, UX не сработал.

6. Добавьте security thinking до сбора данных

Даже если это MVP, заранее решите, какие данные вы не собираете, что храните, кто видит, как удалить, где риски.

7. Не стесняйтесь оставить human-in-the-loop

В сложных доменах человек в процессе — это не слабость. Это control.

Несколько выводов для инженеров

1. Нетворкинг работает, когда вы приносите ценность до запроса

Не надо знакомиться только тогда, когда нужна рекомендация, работа или инвестиции. Лучше регулярно делиться знаниями, помогать, писать, обсуждать, давать feedback.

2. Хороший MVP начинается с узкой боли\проблемы

TaxBridge не пытается решить все налоги США. Он начинается с конкретного сценария: русскоязычный newcomer, первый tax cycle, confusion, documents, route, organizer.

3. Не автоматизируйте то, что ещё не поняли

Сначала надо понять пользовательский процесс. Потом workflow. Потом границы ответственности. И только потом глубокую автоматизацию.

4. В sensitive-доменах честность важнее wow-эффекта

Если продукт касается tax, immigration, healthcare, finance или legal, лучше честно сказать «здесь нужен professional review», чем красиво обмануть пользователя ощущением полной автоматизации.

5. Коммуникация — это инженерный навык, да!

Умение объяснить идею дизайнеру, разработчику, пользователю, партнёру и reviewer — это такая же часть engineering, как код и архитектура.

6. Сообщество может быть частью engineering process

Не как рекламный фон, а как среда, где появляются вопросы, обратная связь, первые пользователи, первые партнёры и первые честные ограничения.

Вместо заключения

Профессиональная карьера растет не только от того, сколько технологий ты выучил и сколько сертификатов получил. Хард скиллы - база на старте, без "Б" это так, и мощный двигатель на карьерном треке. И наступает момент, когда что бы расти дальше требуется нечто большее чем "все знать".

Да, мен, технологии важны. Самообучение важно и очень! Писать статьи, строить портфолио, развиваться в Product Security, DevSecOps, Software Engineering — всё это важно. Но в какой-то момент следующий уровень появляется через людей. Это коммуникации, мышление теми кто окружает в едином треке. Поиск новых возможностей (и часто это не hire staff), ну, ты надеюсь уже понял о чем я:)

Через тех, кто задаёт неудобный вопрос. Через тех, кто даёт честную обратную связь. Через тех, кто предлагает посмотреть на проблему иначе. Через тех, кто может сесть рядом и сказать: «Окей, давай не обсуждать абстрактно, давай соберём MVP».

Так профессиональное окружение перестаёт быть фоном. Оно становится частью engineering process. И иногда именно из такого окружения рождается продукт: небольшой, неидеальный, не претендующий на революцию, но решающий конкретную человеческую проблему.

Для меня TaxBridge — именно такой пример.

Идем дальше! Keep forward!

P.S. За связью с автором, сотрудничеством, коллоборацией - пиши на официальные аккаунты

Источники и полезные ссылки:

IRS: Determining an individual’s tax residency status: https://www.irs.gov/individuals/international-taxpayers/determining-an-individuals-tax-residency-status
IRS: U.S. tax residency — Green card test: https://www.irs.gov/individuals/international-taxpayers/us-tax-residency-green-card-test
IRS: Substantial presence test: https://www.irs.gov/individuals/international-taxpayers/substantial-presence-test
IRS: Free tax return preparation for qualifying taxpayers: https://www.irs.gov/individuals/free-tax-return-preparation-for-qualifying-taxpayers
Grow Cluster IT Association: https://growcluster.com/en/
Startup-accelerator IT Krokit https://krokit.org/en/

Disclaimer: статья описывает продуктовый и инженерный подход. Это не налоговая, юридическая или бухгалтерская консультация.

DEV Community: Ivan's Cybersecurity Notes

Учимся триажить баги и оценивать их влияние на продукт. Или о том как Product Security превращает finding в риск-решение

DISCLAIMER

Field card: карта triage, которую удобно держать перед глазами

Почему классическая модель «CVSS = Priority» больше не работает

Полевая терминология

Mindset инженера: не «закрыть CVE», а доказать (бизнес) риск

Восемь вопросов, которые я задаю до назначения priority

1. Finding настоящий?

2. Где этот компонент живёт (слой, сегмент, сервис)?

3. Есть ли exposure?

4. Reachable ли vulnerable path?

Лестница reachability evidence

5. Насколько exploit weaponizable?

EPSS: probability != percentile

6. Что получит attacker после первого шага?

7. Какой blast radius?

8. Как быстрее всего разорвать attack path?

Полный processing chain: как finding превращается в решение

Как выглядит хороший triage ticket

Плохой ответ

Хороший ответ

Severity, Risk и Priority — не путайте эти слова

Severity

Risk

Priority

Risk Priority != Remediation Difficulty

Практическая decision matrix

P0 / Critical

P1 / High

P2 / Medium

P3 / Low / Temporarily Accepted

Где здесь CVSS v4, EPSS, KEV, SSVC и VEX и как, с*ка это все запомнить

Кейс 1: CVSS 9.8, но attack path отсутствует

Что делает inexperienced engineer

Что делает Senior Product Security Engineer

Reachability verdict

Решение

Кейс 2: формально «не RCE», но priority становится Critical

Exposure

Reachability

Identity context

Blast radius

Что делать

Итог

Кейс 3: TeamCity CVE-2023-42793 — когда почти все сигналы смотрят в одну сторону

Хороший response

Ещё три коротких real-world anchor’а

Jenkins CVE-2024-23897

XZ Utils CVE-2024-3094

HTTP/2 Rapid Reset CVE-2023-44487

Compensating controls: не верьте архитектурной диаграмме на слово

Что значит «влиять на решение» как Senior Engineer

Security приносит описание\расшифровку

Engineering (DEV) приносит

Product / Business owner приносит

Leadership принимает или делегирует decision

Risk treatment: у вас больше вариантов, чем «patch / no patch»

Кто участвует в assessment

Три уровня мышления: Junior, Senior, Lead

Если вы Junior / кандидат, новичок

Если вы Senior Engineer

Если вы Tech Lead / Security Lead

Рекомендации для молодого инженера

Как ответить на интервью: «How do you prioritize vulnerabilities?»

Что автоматизировать, а что оставить человеку

Типовые ошибки\заблуждения, которые могут сэконоить время

Ошибка 1. CVSS = риск

Ошибка 2. Package present = vulnerable path reachable

Ошибка 3. Internal = safe

Ошибка 4. Есть WAF = mitigated

Ошибка 5. Нет public PoC = можно забыть

Ошибка 6. Patch deployed = ticket можно закрыть

Ошибка 7. Risk accepted = навсегда

Ошибка 8. Security должен всегда требовать fix

Небольшой practical model для команды

Финальная модель

Главное

Бесплатный toolbox: куда я захожу во время vulnerability triage

Zero-budget triage в Excel / Google Sheets