Гайнуллина Екатерина, Security Vision

Введение

В этом году мне удалось выступить на PHDays Fest 2025 и сегодня хочу поделиться краткими выкладками из своего доклада.

По мере увеличения числа инцидентов, связанных с уязвимостями в приложениях, компании пересматривают свои процессы и ищут инструменты, позволяющие строить по-настоящему защищённые продукты. Но почему так часто внедрение процессов безопасной разработки (SSDLC) оборачивается формальностью, а результат лишь видимость безопасности?

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

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

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

Почему разработка и безопасность говорят на разных языках

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

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

SSDLC: красивая теория, суровая практика

Большинство компаний в теории декларируют внедрение SSDLC: прописывают шаги по безопасности на всех этапах разработки, включают анализ угроз, проверки кода и тесты на проникновение. На практике процесс часто начинается слишком поздно — безопасность подключается лишь к концу проекта, когда основные решения уже приняты и продукт практически готов.

В результате команды сталкиваются с внезапным валом требований и багов по безопасности, зачастую когда сроки поджимают и всё внимание сосредоточено на релизе. Отчёты безопасности становятся "галочкой", а найденные уязвимости — нерешёнными проблемами, которые никто не спешит устранять. Формальный подход приводит к иллюзии контроля вместо реального результата.

Чек-листы и политика — не гарантия безопасности

Многие организации полагаются на чек-листы и подробные политики, считая их достаточным инструментом для обеспечения безопасности. Однако даже самый детальный регламент не защитит от ошибок, если не встраивается в реальную работу команды. Формальный контроль создаёт ложное чувство защищённости: разработчик может расписаться в ознакомлении, пройти по всем пунктам, но пропустить критическую уязвимость просто потому, что не получил своевременной обратной связи в момент написания кода.

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

PDF вместо диалога: потеря времени и доверия

Одна из главных проблем это отсутствие оперативного двустороннего общения между безопасниками и разработчиками. Вместо живого диалога команды обмениваются тяжёлыми PDF-отчётами, которые приходят с большим опозданием. Разработчики, получая такие отчёты, уже находятся мыслями на других задачах и зачастую не понимают сути проблем или не готовы возвращаться к старому коду. Итог: затягивание исправлений, снижение мотивации и ухудшение качества работы.

Поздно = дорого

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

Почему процессы не приживаются

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

Безопасность — не проверка, а сопровождение

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

Четыре принципа SSDLC без барьеров

Для построения работающего процесса безопасной разработки важны четыре принципа:

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

Интеграция безопасности там, где работает команда

Безопасность должна быть встроена в привычные инструменты — GitHub, Jira, IDE. Например, результаты анализа кода должны появляться прямо в pull request’ах, а тикеты по безопасности — автоматически попадать в трекер задач. Такой подход позволяет команде реагировать на проблемы своевременно и устранять их в процессе, а не в конце разработки.

Полезный фидбэк — конкретные действия

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

Когда команда становится единым потоком

Главный эффект встроенной безопасности — исчезновение “стен” между разработчиками, тестировщиками и безопасниками. Вместо разрозненных этапов появляется единый поток: вопросы безопасности решаются там, где возникает задача, а не откладываются до финального аудита.

Платформа мечты: безопасность на всех этапах

Идеальный SSDLC — это непрерывное сопровождение на всех стадиях: от идеи и архитектуры, через код и CI/CD, до релиза и поддержки. Безопасность становится частью требований, архитектурных решений, кода, автоматических тестов, настроек продакшена и даже пост-релизного мониторинга. Такой подход не требует особых усилий для интеграции — процессы просто работают в фоновом режиме и помогают команде не спотыкаться о старые баги.

Почему внедрять надо уже сейчас

Мир ускоряется, и тянуть с безопасностью нельзя. Некоторые факты: после обнаружения новой уязвимости у атакующих уходит около 24 часов, чтобы разработать эксплоит. Представьте: выходит новость о баге, и уже на следующий день по сети бродят скрипты, ищущие уязвимые системы. Если у вас процесс починки уязвимости – неделя, месяц, квартал, вы просто не успеваете.

Российский регулятор, ФСТЭК, в своих рекомендациях говорит: критические уязвимости необходимо устранять в тот же день, когда они выявлены. В некоторых отраслях это жёсткое требование. И это логично: когда счёт идёт на часы, безопасность должна реагировать мгновенно.

Отсюда появился и ставший модным лозунг «Shift security left» – сдвиг безопасности влево, то есть на ранние этапы. Но хочу подчеркнуть: «безопасность влево» – это не просто тренд, это неизбежность. Это ответ на реальную ситуацию: если вы тянете безопасность к концу цикла, вы в проигрыше. В идеале, как мы обсуждали, она должна идти рука об руку с разработкой с самого начала.

Реальные примеры: цена ошибок

Истории с миллиардными убытками из-за ошибок в процессах безопасности — не редкость. Примеры из индустрии (Ariane 5, CrowdStrike и другие) показывают, что отсутствие выстроенного процесса приводит к катастрофам, которые можно было бы избежать, инвестировав заранее в культуру безопасности.

Как выглядит SSDLC без барьеров на практике

В процессе разработки безопасное поведение должно формироваться на каждом этапе:

Уже на стадии идеи обсуждаются не только фичи, но и угрозы.
Архитектурные решения принимаются с учётом рисков и границ доверия.
При написании кода работают анализаторы, линтеры, безопасные практики.
В CI/CD-пайплайне автоматически запускаются тесты, сканеры, проверки зависимостей.
Перед релизом финальные настройки и контроль качества.
После релиза — регулярный мониторинг, анализ новых уязвимостей и оперативное реагирование на инциденты.

Всё это — единый процесс, где безопасность встроена и воспринимается как часть ДНК команды, а не внешнее требование.

Результаты: зачем это бизнесу

Главные выгоды подхода:

Быстрее и безопаснее вывод новых продуктов на рынок.
Меньше конфликтов и "сюрпризов" перед релизом.
Реальное снижение рисков, прозрачность и контроль.
Экономия ресурсов и рост доверия внутри команды

С чего начать: пять простых шагов

Внедрить хотя бы одну автоматическую проверку в CI/CD.
Давать обратную связь по безопасности прямо в pull request’ах.
Проводить совместные архитектурные сессии с участием безопасников и разработчиков.
Связывать найденные угрозы и рекомендации с задачами в общем трекере.
Измерять скорость реакции на уязвимости, а не просто их количество.

Каждый из этих шагов не требует огромных ресурсов, но запускает процесс изменений.

Формула SSDLC: ясность, поток, доверие

Работающая безопасная разработка — это сочетание трёх вещей: ясность процессов, единый поток работы и доверие между всеми участниками. Если удаётся их реализовать, безопасность перестаёт быть барьером и становится поддержкой для бизнеса, давая команде уверенность и свободу для роста.

Безопасная разработка без барьеров — это реальность, если двигаться шаг за шагом, начиная с простых изменений и делая безопасность естественной частью ежедневной работы.

Безопасная разработка без барьеров: как построить SSDLC, который реально работает