Гайнуллина Екатерина, Security Vision
Введение
В этом году мне удалось выступить на PHDays Fest 2025 и сегодня хочу поделиться краткими выкладками из своего доклада.
По мере увеличения числа инцидентов, связанных с уязвимостями в приложениях, компании пересматривают свои процессы и ищут инструменты, позволяющие строить по-настоящему защищённые продукты. Но почему так часто внедрение процессов безопасной разработки (SSDLC) оборачивается формальностью, а результат — лишь видимость безопасности?
От разовых аудитов к реальному процессу
Традиционный подход к безопасности часто сводится к разовым аудитам: раз в полгода продукт тестируется на уязвимости, формируется внушительный отчёт, и на этом процесс считается завершённым. На практике подобный формат редко приводит к росту защищённости. Причина в том, что безопасность воспринимается как событие, а не как постоянное свойство процесса разработки.
Организации, вводя множество регламентов и чек-листов, надеются закрыть риски, но сталкиваются с сопротивлением команды. Процессы, которые мешают работать, обходят или формально выполняют для галочки. Настоящая безопасность достигается тогда, когда она встроена в ежедневный поток разработки и не воспринимается как внешний контроль. Это требует смены акцента — от бюрократии к интеграции безопасности на всех этапах жизненного цикла продукта.
Почему разработка и безопасность говорят на разных языках
В основе многих неудач лежит разрыв между тремя основными сторонами: разработчиками, бизнесом и безопасниками. У каждого — своя оптика. Разработчики ориентированы на скорость и выпуск новых фич, бизнес — на прибыль и сроки, безопасность — на минимизацию рисков и соответствие политикам.
Без общего контекста и диалога процессы безопасности воспринимаются как препятствие: бизнес видит в безопасниках тормоз, разработчики — в бюрократах, а сами безопасники чувствуют, что им не дают достаточно полномочий. Всё это питает конфликт, в результате которого формальный SSDLC не даёт реального результата.
SSDLC: красивая теория, суровая практика
Большинство компаний в теории декларируют внедрение SSDLC: прописывают шаги по безопасности на всех этапах разработки, включают анализ угроз, проверки кода и тесты на проникновение. На практике процесс часто начинается слишком поздно — безопасность подключается лишь к концу проекта, когда основные решения уже приняты и продукт практически готов.
В результате команды сталкиваются с внезапным валом требований и багов по безопасности, зачастую, когда сроки поджимают и всё внимание сосредоточено на релизе. Отчёты безопасности становятся «галочкой», а найденные уязвимости — нерешёнными проблемами, которые никто не спешит устранять. Формальный подход приводит к иллюзии контроля вместо реального результата.
Чек-листы и политика — не гарантия безопасности
Многие организации полагаются на чек-листы и подробные политики, считая их достаточным инструментом для обеспечения безопасности. Однако даже самый детальный регламент не защитит от ошибок, если не встраивается в реальную работу команды. Формальный контроль создаёт ложное чувство защищённости: разработчик может расписаться в ознакомлении, пройти по всем пунктам, но пропустить критическую уязвимость просто потому, что не получил своевременной обратной связи в момент написания кода.
Безопасность — это не набор формальных требований, а живая часть культуры разработки. Чек-листы должны быть не просто бюрократической процедурой, а полезной подсказкой, помогающей избежать ошибок там, где это реально важно.
PDF вместо диалога: потеря времени и доверия
Одна из главных проблем — отсутствие оперативного двустороннего общения между безопасниками и разработчиками. Вместо живого диалога команды обмениваются тяжёлыми PDF-отчётами, которые приходят с большим опозданием. Разработчики, получая такие отчёты, уже находятся мыслями на других задачах и зачастую не понимают сути проблем или не готовы возвращаться к старому коду. Итог — затягивание исправлений, снижение мотивации и ухудшение качества работы.
Поздно = дорого
Чем позже выявлена уязвимость, тем выше цена её исправления. Найденная перед релизом ошибка способна остановить запуск продукта, вызвать аврал и большие финансовые потери. Команды вынуждены срочно переделывать уже протестированный функционал, откладывать релизы и нарушать бизнес-планы. Пытаясь ускорить работу, компании нередко отодвигают безопасность на второй план, в итоге рискуя потерять гораздо больше — как в деньгах, так и в репутации.
Почему процессы не приживаются
Когда безопасность внедряется как внешний и неудобный процесс, команды начинают искать способы его обойти. Всё, что ломает привычный поток работы (flow), вызывает сопротивление: проверки выполняются формально или игнорируются, поиск уязвимостей превращается в ещё одну рутинную обязанность. Единственный путь сделать безопасность эффективной — интегрировать её в привычные инструменты и процессы команды, сделать частью ежедневной рутины, а не навязанной извне обязанностью.
Безопасность — не проверка, а сопровождение
Современный подход требует переосмысления роли безопасности: из внешнего контролёра она должна превратиться в наставника и партнёра, который сопровождает команду на каждом этапе. Как функция автосохранения в текстовом редакторе, безопасность должна быть незаметной, но постоянно поддерживать рабочий процесс и защищать от критических ошибок.
Четыре принципа SSDLC без барьеров
Для построения работающего процесса безопасной разработки важны четыре принципа:
1. Ясность: понятные и прозрачные требования, отсутствие «магии» и непонятных инструкций.
2. Контекст: рекомендации и обратная связь даются применительно к конкретным задачам и коду.
3. Автоматизация: всё, что можно автоматизировать, должно быть автоматизировано, чтобы не перегружать людей ручной работой.
4. Невидимость: процессы безопасности встраиваются в привычные шаги работы, чтобы не мешать разработчикам, а незаметно поддерживать их.
Интеграция безопасности там, где работает команда
Безопасность должна быть встроена в привычные инструменты — GitHub, Jira, IDE. Например, результаты анализа кода должны появляться прямо в pull request’ах, а тикеты по безопасности — автоматически попадать в трекер задач. Такой подход позволяет команде реагировать на проблемы своевременно и устранять их в процессе, а не в конце разработки.
Полезный фидбэк — конкретные действия
Обратная связь по безопасности должна быть чёткой и actionable — не просто «есть баг», а что и как нужно исправить. Идеально, когда такая рекомендация автоматически превращается в задачу в системе управления проектом. Это сокращает время исправления и снижает стресс для команды.
Когда команда становится единым потоком
Главный эффект встроенной безопасности — исчезновение «стен» между разработчиками, тестировщиками и безопасниками. Вместо разрозненных этапов появляется единый поток: вопросы безопасности решаются там, где возникает задача, а не откладываются до финального аудита.
Платформа мечты: безопасность на всех этапах
Идеальный SSDLC — это непрерывное сопровождение на всех стадиях: от идеи и архитектуры, через код и CI/CD, до релиза и поддержки. Безопасность становится частью требований, архитектурных решений, кода, автоматических тестов, настроек продакшена и даже пост-релизного мониторинга. Такой подход не требует особых усилий для интеграции — процессы просто работают в фоновом режиме и помогают команде не спотыкаться о старые баги.
Почему внедрять надо уже сейчас
Мир ускоряется, и тянуть с безопасностью нельзя. Некоторые факты: после обнаружения новой уязвимости у атакующих уходит около 24 часов, чтобы разработать эксплоит. Представьте: выходит новость о баге, и уже на следующий день по сети бродят скрипты, ищущие уязвимые системы. Если у вас процесс починки уязвимости – неделя, месяц, квартал, вы просто не успеваете.
Российский регулятор, ФСТЭК, в своих рекомендациях вообще говорит: критические уязвимости необходимо устранять в тот же день, когда они выявлены. В некоторых отраслях это жёсткое требование. И это логично: когда счёт идёт на часы, безопасность должна реагировать мгновенно.
Отсюда появился и ставший модным лозунг "Shift security left" – сдвиг безопасности влево, то есть на ранние этапы. Но хочу подчеркнуть: «безопасность влево» – это не просто тренд, это неизбежность. Это ответ на реальную ситуацию: если вы тянете безопасность к концу цикла, вы в проигрыше. В идеале, как мы обсуждали, она должна идти рука об руку с разработкой с самого начала.
Реальные примеры: цена ошибок
Истории с миллиардными убытками из-за ошибок в процессах безопасности — не редкость. Примеры из индустрии (Ariane 5, CrowdStrike и другие) показывают, что отсутствие выстроенного процесса приводит к катастрофам, которые можно было бы избежать, инвестировав заранее в культуру безопасности.
Как выглядит SSDLC без барьеров на практике
В процессе разработки безопасное поведение должно формироваться на каждом этапе:
-
Уже на стадии идеи обсуждаются не только фичи, но и угрозы.
-
Архитектурные решения принимаются с учётом рисков и границ доверия.
-
При написании кода работают анализаторы, линтеры, безопасные практики.
-
В CI/CD-пайплайне автоматически запускаются тесты, сканеры, проверки зависимостей.
-
Перед релизом финальные настройки и контроль качества.
-
После релиза — регулярный мониторинг, анализ новых уязвимостей и оперативное реагирование на инциденты.
Всё это — единый процесс, где безопасность встроена и воспринимается как часть ДНК команды, а не внешнее требование.
Результаты: зачем это бизнесу
Главные выгоды подхода:
-
Быстрее и безопаснее вывод новых продуктов на рынок.
-
Меньше конфликтов и «сюрпризов» перед релизом.
-
Реальное снижение рисков, прозрачность и контроль.
-
Экономия ресурсов и рост доверия внутри команды.
С чего начать: пять простых шагов
1. Внедрить хотя бы одну автоматическую проверку в CI/CD.
2. Давать обратную связь по безопасности прямо в pull request’ах.
3. Проводить совместные архитектурные сессии с участием безопасников и разработчиков.
4. Связывать найденные угрозы и рекомендации с задачами в общем трекере.
5. Измерять скорость реакции на уязвимости, а не просто их количество.
Каждый из этих шагов не требует огромных ресурсов, но запускает процесс изменений.
Формула SSDLC: ясность, поток, доверие
Работающая безопасная разработка — это сочетание трёх вещей: ясность процессов, единый поток работы и доверие между всеми участниками. Если удаётся их реализовать, безопасность перестаёт быть барьером и становится поддержкой для бизнеса, давая команде уверенность и свободу для роста.
Безопасная разработка без барьеров — это реальность, если двигаться шаг за шагом, начиная с простых изменений и делая безопасность естественной частью ежедневной работы.
