Безопасность начинается не с кода, а с понимания, что мы защищаем

Современная разработка всё чаще движется по принципу «сначала скорость — потом безопасность». Однако в эпоху DevSecOps такой подход становится рискованным. Без формализованных требований и встроенных практик безопасности любая автоматизация превращается в иллюзию контроля. Запуск сканеров и проверок кода лишь верхушка айсберга, если в основе нет понятных правил, архитектурных принципов и живого цикла работы с угрозами.

Редакция CISOCLUB пообщалась с Андреем Жаркевичем, экспертом по информационной безопасности
в Start X, о том, почему компании по-прежнему путают «инструменты» с «процессами», как сделать требования безопасности действительно работающими, как встроить их в CI/CD без потери темпа разработки и какие тренды в управлении требованиями станут ключевыми в ближайшие годы.

Почему многие компании начинают работу над безопасностью с запуска сканеров и проверки кода, минуя этап формализации требований?

Это классическая ловушка «быстрых побед». Руководство хочет видеть результат, команда разработки — продолжать писать код, а запуск сканера дает иллюзию, что «мы что-то делаем». Но по факту это как строить дом без плана — да, вы можете начать класть кирпичи, но непонятно, что в итоге получится.

Проблема в том, что без четких требований к безопасности невозможно понять, что именно мы защищаем и от каких угроз. В итоге сканер находит 500 уязвимостей, половина из которых не критична для конкретного бизнеса, а действительно важные риски остаются за кадром.

Часто это происходит от недостатка компетенций: проще купить инструмент и нажать кнопку, чем сесть и продумать, какие данные у нас критичны, кто к ним имеет доступ, и что будет, если они утекут.

Как убедиться, что требования безопасности реально исполняются, а не остаются формальностью в документах?

Главное — связать требования с конкретными проверками в процессе разработки. Если требование нельзя автоматически проверить или хотя бы явно протестировать, оно с высокой вероятностью останется на бумаге.

Практический подход: каждое требование должно превращаться либо в автоматический тест (например, «JWT-токены должны истекать через 15 минут» → тест в CI/CD), либо в чек-лист для code review, либо в конфигурацию инфраструктуры как код.

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

Можно ли синхронизировать внутренние требования безопасности с внешними нормативами и стандартами без ручного труда?

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

На практике это выглядит так: вы формулируете свои требования в терминах рисков и контролей (например, «критичные данные должны быть зашифрованы при хранении»), а дальше создаете матрицу соответствия, которая показывает, какие пункты каких стандартов это требование покрывает, будь то 187-ФЗ, PCI DSS или внутренние политики.

Современные платформы управления требованиями позволяют поддерживать такие матрицы в полуавтоматическом режиме. Но первичная настройка все равно требует экспертизы — нужно понимать и бизнес-контекст, и нюансы стандартов.

Где чаще всего возникают проблемы при переходе от требований к их реализации — на уровне архитектуры, разработки или тестирования?

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

Архитекторы часто не понимают в деталях, какие именно угрозы критичны для бизнеса, а специалисты по безопасности не всегда знакомы с технологическими ограничениями конкретного стека. В итоге получается «защитите все от всех» с одной стороны и «это невозможно реализовать» с другой.

Второе проблемное место — тестирование. У нас в культуре сильны функциональные тесты, но security-тестирование часто воспринимается как что-то опциональное. Либо его делают в самом конце, когда уже поздно что-то менять без больших затрат.

Решение — вовлекать Security Champions из команд разработки и делать security review частью процесса проектирования, а не финальной проверкой.

Как адаптировать требования безопасности при эволюции архитектуры — переходе на микросервисы, активном использовании API?

Это больная тема для многих. Переход на микросервисы радикально меняет модель угроз: вместо одного монолита с четким периметром появляются десятки сервисов, общающихся по сети.

Ключевой принцип здесь — Zero Trust (нулевое доверие) и «безопасность по умолчанию». Каждый сервис должен аутентифицировать запросы, каждое API — иметь rate limiting и валидацию входных данных, всё взаимодействие — быть зашифрованным.

На практике это означает, что требования нужно переформулировать с «защитить периметр» на «защитить каждое взаимодействие». И здесь критически важна автоматизация: умная сеть сервисов (service mesh) для управления трафиком, API Gateway с встроенными политиками безопасности, автоматический мониторинг аномалий.

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

Какие метрики помогают понять, что требования безопасности реально работают и снижают количество уязвимостей?

Метрики — это то, где многие спотыкаются, потому что пытаются измерить процесс вместо результата.

Плохие метрики:
«количество проведенных аудитов», «процент закрытых требований». Они ничего не говорят о реальном уровне защищенности.

Хорошие метрики:

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

процент компонентов с актуальными зависимостями без известных CVE;

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

процент новых функций, прошедших threat modeling до разработки.

Важно смотреть на тренды: если внедрили новые требования, а количество инцидентов по связанным темам снизилось — это работает.

Как разрешать конфликты между требованиями безопасности, когда они противоречат друг другу?

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

Решение всегда лежит в плоскости оценки рисков. Нужно явно проговорить: какой риск мы снижаем каждым требованием и какой риск создаем. Дальше — приоритезация на основе потенциального ущерба для бизнеса.

Часто помогает разделение на контексты. Например, для публичных API одни требования, для внутренних сервисов — другие. Или разные уровни строгости для разных категорий данных.

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

Как встраивать практики Security as Code в современные CI/CD-пайплайны?

Security as Code — это когда политики безопасности описаны в виде кода и автоматически применяются на всех этапах. Главное преимущество — воспроизводимость и прозрачность.

Практические шаги:

статический анализ кода (SAST) на этапе commit или pull request — не дает влить небезопасный код;

проверка зависимостей (SCA) — автоматический поиск известных уязвимостей в библиотеках;

политики инфраструктуры как код — например, через Open Policy Agent проверяем, что Kubernetes-манифесты соответствуют требованиям (нет root-контейнеров, есть resource limits);

динамическое тестирование (DAST) на этапе сборки тестовых окружений;

автоматизированный threat modeling — генерация диаграмм потоков данных и выявление потенциальных угроз.

Критично не превратить это в «конвейер блокировок». Лучше начинать в режиме предупреждений, собирать метрики, настраивать пороги, и только потом включать жесткие блокировки для критичных проблем.

Как предотвратить деградацию требований — когда они устаревают, забываются или исключаются из архитектуры?

Это проблема «технического долга безопасности». Система развивается, появляются новые компоненты, старые уходят в legacy, а требования остаются написанными три года назад.

Работающие практики:

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

привязка требований к компонентам системы — если компонент удалили или заменили, требования автоматически попадают на ревью;

автоматический мониторинг покрытия — видим, какие требования больше не проверяются тестами;

threat modeling как живой процесс — не одноразовое упражнение на старте проекта, а регулярная практика.

Еще помогает культура: если требования безопасности — часть Definition of Done (критериев готовности) для фич, они естественным образом обновляются вместе с продуктом.

Какие тренды в управлении требованиями безопасности в DevSecOps вы видите на ближайшие 2-3 года?

Вот несколько заметных направлений:

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

Экстремальный Shift Left — безопасность будет встраиваться еще раньше, на уровень проектирования в IDE разработчика. Уже сейчас появляются инструменты, которые подсвечивают потенциальные проблемы безопасности прямо в процессе написания кода.

Стандартизация форматов описания требований — движение в сторону machine-readable security requirements, которые можно автоматически транслировать в тесты и проверки.

Интеграция с экосистемами платформ инженерии — когда требования безопасности «зашиты» в компоненты инфраструктуры, и команды разработки получают их автоматически.

Развитие практик Supply Chain Security — более строгий контроль зависимостей, автоматическая генерация SBOM (Software Bill of Materials), проверка подписей артефактов.

Главный тренд — автоматизация и смещение ответственности за безопасность ближе к разработке, но при сохранении централизованного управления политиками. Это золотая середина между гибкостью и контролем.