Как выстраивать SSDLC
Часто на тех. интервью встречается вопрос: как бы вы выстраивали SSDLC.
У этого вопроса нет одного точного ответа, потому что любой бизнес — это уникальная система со своими процессами, ограничениями и приоритетами. В этом посте хочу рассказать, как я сам отвечаю на такой вопрос и какой подход считаю правильным.
━━━━━━━━━ Что такое SSDLC ━━━━━━━━━
SSDLC (Secure Software Development Life Cycle) — это жизненный цикл безопасной разработки ПО.
Если проще, то это набор практик, требований и проверок безопасности, которые накладываются на процесс разработки и поставки продукта. • CI/CD — автоматизированный подход к сборке, тестированию и выпуску ПО • SSDLC — слой безопасности, который встраивается в этот процесс на разных этапах
То есть по мере разработки мы добавляем инструменты и практики безопасности, а перед релизом проводим итоговый аудит/код ревью, чтобы понять, насколько безопасным получился сервис.
━━━━━━━━━━ Как я выстраиваю SSDLC ━━━━━━━━━━
Как я и сказал в начале, “идеального” единого формата SSDLC не существует. Есть целевая картина, к которой стоит стремиться, но бизнес почти всегда внесёт в неё свои правки. И это нужно учитывать сразу. ⠀ ⠀ 1 Этап ➥ На старте разработки, когда уже есть ТЗ и понимание того, что хочет заказчик, я бы сразу накинул базовые требования безопасности к будущему функционалу.
Условно: • ограничения на размер и характер входящих данных, чтобы снижать риск DoS • корректную реализацию идентификаторов и публичных сущностей, чтобы избежать перебора и брутфорса • контроль атомарности операций, чтобы не допускать Race Condition • учёт типовых рисков для конкретных endpoint’ов, бизнес-логики и пользовательских сценариев
То есть безопасность должна появляться не после написания кода, а ещё на уровне проектирования функционала ⠀ ⠀ 2 Этап ➥ Уже в процессе разработки можно подключать IDE-плагины и ранние проверки, например решения уровня SonarQube, чтобы разработчик ещё до коммита видел базовые алерты.
SAST из коробки может заметно фолзить, и его результаты нельзя воспринимать как истину. Но как ранний сигнал для разработчика это полезно • быстрее замечать небезопасные паттерны • видеть устаревшие методы шифрования • обращать внимание на потенциальные инъекции и иные слабые места ещё до пайплайна ⠀ ⠀ 3 Этап ➥ Следом я бы интегрировал в pipeline основные инструменты безопасности: • SAST • DAST • SCA / OSA
В идеальной картине результаты таких проверок лучше сводить в централизированное место. • ASOC — класс платформ, которые помогают автоматизировать, координировать и агрегировать результаты проверок безопасности приложений.
Это удобно, потому что у тебя не десять разрозненных отчётов, а более цельная картина по рискам. ⠀ ⠀ 4 Этап ➥ Перед релизом я бы обязательно проводил финальный аудит/код ревью, который позволяет уже вручную и глубже ответить на вопрос: насколько текущий релиз действительно безопасен.
Лично я в таком этапе обычно: • прохожусь руками по коду и логике функционала • смотрю на потенциально опасные точки входа • отдельно проверяю динамику возможных уязвимостей • локально прогоняю SAST, чтобы перепроверить отчёт и контекст находок • завершаю всё динамическим анализом
После этого отдельно стоит проверить: • актуальность версий компонентов и окружении • транзитивные зависимости • политики безопасности в Docker / VM
Если стек давно не обновлялся, то за 1.5–2 года там уже вполне могут появиться готовые эксплоиты или публичные HIGH / CRITICAL уязвимости.
━━━━━━━━━━ Итог ━━━━━━━━━━
SSDLC почти всегда можно усиливать дальше: • вводить proxy-блокировки • строить security gates • усиливать автоматическую проверку политик безопасности
Но не каждый бизнес готов идти в такую зрелость сразу. Без понимания того, что бизнес готов внедрять, какие риски хочет закрывать и чем готов платить за безопасность в скорости разработки, выстроить SSDLC “правильно” просто нельзя.
