Привет всем! Меня зовут Николай Комисарчук, я руководитель группы автоматизации процессов разработки безопасного программного обеспечения Crosstech Solutions Group. Статья написана совместно с Александром Сорокатым, руководителем группы безопасной разработки и автоматизации.
В материале мы разберемся, чем на практике занимается DevSecOps, какие инструменты используются в повседневной работе. Поговорим об SSDLC и откуда в этой аббревиатуре появилось слово «Security», а также в какой момент проекту стоит задуматься о внедрении безопасного жизненного цикла разработки. Отдельно остановимся на том, как внедрять SSDLC без вреда для проекта и обсудим чек-лист оценки зрелости. Погрузимся в облако тегов DevSecOps, разберем ключевые практики и инструменты, а также поговорим о том, что делать после того, как все эти процессы уже внедрены.
Возникновение SSDLC
Начнем с разбора SSDLC и понимания того, как он связан с DevSecOps. Стандартный жизненный цикл разработки программного обеспечения принято называть SDLC. Как правило, он состоит из нескольких последовательных этапов: планирования задач, дизайна системы, разработки, тестирования и деплоя, то есть отправки готового решения в прод.
Однако по мере роста цифровых продуктов и усложнения ИТ-ландшафта, стандартных подходов становится недостаточно. С учетом оценки рисков для бизнеса, появления новых уязвимостей и увеличения угроз от внешних факторов, стандартные методы требуют пересмотра привычного процесса разработки. Поэтому на всех этапах жизненного цикла, процесс создания продуктов обрел фокус на безопасность.
Так возникает SSDLC – расширенная модель SDLC, в которой безопасность становитс�� неотъемлемой частью всего процесса создания программного обеспечения. SSDLC включает в себя оценку рисков, моделирование различных угроз или дизайн безопасной архитектуры. Все дополнения нужны, чтобы разрабатываемый продукт изначально проектировался как безопасный, и в нем были решены задачи с учетом потенциальной поверхности атак.
На практике SSDLC опирается на набор процессов и инструментов. В него входят статистические анализаторы (SAST), SCA-анализаторы, динамическое тестирование безопасности (DAST) и другие методики. В этом же процессе участвует код-ревью, когда разработчики смотрят код друг друга: как код написан, соответствует заданным условиям работы в компании.
Последним в цепочке жизненного цикла проводят Security Assessment. Этап, во время которого разбирается проблематика появления угрозы, ее «дырки» и анализируются возможные последствия. На основе исследования формируется рабочая группа и выстраивается процесс по устранению проблемы.
Отличия DevOps от DevSecOps
Сама по себе модель SSDLC не работает. Реализацию берут на себя DevOps и DevSecOps – подходы, которые отвечают за реализацию процессов разработки и эксплуатации на практике.
DevOps в классическом понимании фокусируется на автоматизации процессов сборки, доставки и развертывания программного обеспечения. В его зону ответственности входят CI/CD-пайплайны, упаковка приложения в артефакты или контейнеры, автоматизация тестирования, в том числе юнит-тестов, а также ускорение и стабилизация релизного цикла.
Современные DevOps-команды все чаще затрагивают и вопросы безопасности: используют менеджеры секретов, такие как Vault или Vaultwarden, следят за базовой гигиеной инфраструктуры. Однако, как показывает практика, эти меры внедрены далеко не везде и часто носят фрагментарный характер.
В этот момент появляется DevSecOps. В отличие от DevOps, он фокусируется на встраивании безопасности во все этапы CI/CD-процесса. Основная задача DevSecOps – автоматизация и интеграция инструментов безопасности: статического анализа кода (SAST), анализа зависимостей (SCA), динамического тестирования (DAST), проверки инфраструктуры как кода (IaC), а также сканирования репозиториев на наличие секретов.
Хороший пример такой практики – использование open-source-инструментов вроде Gitleaks, которые позволяют автоматически проверять репозитории на утечки паролей, ключей и сертификатов. При необходимости такие инструменты масштабируются и донастраиваются под конкретные требования компании, например, с помощью регулярных выражений для поиска специфичных данных.
На более зрелом уровне развития DevSecOps-подход дополняется механизмами quality gates. Это заранее определенные правила, при которых сборка или релиз блокируются после обнаружения критических уязвимостей. К примеру, внутри компании могут завершить деплой при наличии хотя бы одного крита. В таком случае пайплайн автоматически останавливается, команда получает уведомление, а продукт не выходит в прод до устранения проблемы.
Как понять, когда необходим SSDLC?
Понять, что проекту пора внедрять практики SSDLC, можно, задав себе несколько базовых вопросов. Все же решение о переходе к безопасному жизненному циклу разработки не возникает на пустом месте. Ему почти всегда предшествуют конкретные проблемы и сигналы внутри команды или продукта.
Первый и самый очевидный признак – частые уязвимости в релизах. Если проблемы безопасности регулярно появляются уже после выхода продукта, значит, что существующие процессы не позволяют выявлять риски на ранних этапах разработки.
Второй сигнал – конфликты между разработчиками и специалистами по безопасности. Когда безопасность подключается только на финальных стадиях, команды начинают работать в противофазе: разработка стремится быстрее выпускать новые фичи, а безопасность – останавливать релизы из-за найденных уязвимостей. В результате страдают и сроки, и качество продукта.
Третья проблема – сложности с отслеживанием зависимостей и лицензий. Отсутствие прозрачности в используемых компонентах приводит к пропущенным уязвимостям в сторонних библиотеках, рискам использования запрещенных лицензий и невозможности быстро оценить влияние новых CVE на продукт.
Еще один важный фактор – пропущенные уязвимости на проде. Если криты обнаруживаются уже в рабочей среде, это не только увеличивает стоимость их устранения, но и создает прямые риски для бизнеса и пользователей.
Наконец, внедрение SSDLC становится практически неизбежным, если проекту необходимо проходить сертификацию или соответствовать требованиям регуляторов, в том числе ФСТЭК.
Если хотя бы несколько из этих пунктов актуальны для проекта, это явный сигнал: пора задуматься о внедрении SSDLC. В то же время важно помнить, что само по себе наличие проблем еще не означает готовность к изменениям.
Оценка зрелости проекта
Прежде чем внедрять практики безопасной разработки, необходимо оценить зрелость проекта, иначе можно не только не получить ожидаемого эффекта, но и навредить команде и процессам.
В первую очередь важно наличие CI/CD-процессов. Автоматизированная сборка и доставка значительно упрощают внедрение практик безопасности и снижают трудозатраты на проведение security assessment на финальных этапах. Чем выше уровень автоматизации, тем легче встраивать проверки безопасности без ручного вмешательства.
Следующий важный элемент – процессы код-ревью. В команде должен быть выстроен понятный и устойчивый процесс проверки кода, а также определен ответственный техлид, который контролирует качество и соблюдение стандартов разработки. Код-ревью – это одна из ключевых практик SSDLC, позволяющая выявлять проблемы еще до запуска автоматизированных анализаторов.
Не менее важно наличие юнит-тестов и автотестов. После исправления уязвимостей, обнаруженных SAST, DAST и другими инструментами, необходимо быть уверенными, что изменения не ломают функциональность продукта. Автотесты позволяют безопасно вносить правки и снижать риск регрессий.
Отдельного внимания требует уровень понимания безопасности у самих разработчиков. Команда должна понимать природу уязвимостей и способы их эксплуатации. Без этого разработчики либо не смогут корректно устранять проблемы, либо рискуют внести изменения, которые приведут к деградации продукта.
Важным показателем зрелости является и наличие SLA по исправлению дефектов безопасности. Использование систем трекинга задач, таких как Jira, позволяет отслеживать сроки устранения уязвимостей и контролировать выполнение обязательств по безопасности. В этот же процесс могут быть интегрированы системы управления уязвимостями, такие как ASOC.
Также необходимо проверить, соблюдаются ли руководства по безопасной разработке. В частности, существуют методические рекомендации и ГОСТы, а также руководство ФСТЭК по разработке безопасного программного обеспечения.
Еще один аспект – обучение разработчиков. Регулярное посещение баз CVE/CWE и развитие навыков безопасной разработки снижают количество уязвимостей еще на этапе написания кода.
В конце стоит обратить внимание на использование lock-файлов и пакетных менеджеров. Они необходимы для корректного компонентного анализа и позволяют точно определить, какие библиотеки и версии используются в проекте. Это особенно важно для последующего внедрения SCA и управления зависимостями.
Если большинство этих пунктов реализованы или находятся в стадии внедрения, проект можно считать готовым к постепенному переходу на SSDLC. В противном случае стоит начать именно с выстраивания базовых процессов и только после этого переходить к автоматизации безопасности.
Облако тегов DevSecOps
После оценки зрелости проекта можно перейти к практической стороне DevSecOps и посмотреть, из каких элементов он состоит. Часто этот набор называют «облаком тегов DevSecOps». Важно понимать, что речь идет не о конкретных инструментах, а о классах практик и подходов, которые используются для встраивания безопасности в процесс разработки.
Одним из базовых элементов выступает SAST – статический анализ кода. Эти инструменты анализируют исходный код и позволяют выявлять уязвимости еще до запуска приложения. SAST помогает находить потенциальные проблемы в логике, работе с данными и использовании небезопасных конструкций.
Отдельным классом выделяется SCA – компонентный анализ. Он отвечает за анализ сторонних библиотек и зависимостей, используемых в проекте. SCA позволяет выявлять известные уязвимости в компонентах, находить устаревшие и транзитивные зависимости, а также контролировать использование лицензий, включая запретные или нежелательные.
DAST – динамическое тестирование безопасности применяется уже после деплоя приложения. В этом случае на работающее приложение «натравливаются» тесты безопасности, чаще всего в формате blackbox. Такой подход позволяет оценить продукт с точки зрения внешнего злоумышленника и выявить уязвимости, которые невозможно обнаружить в исходном коде.
Промежуточным звеном между статическим и динамическим анализом являются IAST – интерактивные анализаторы. Они работают в среде выполнения приложения и позволяют получить больше контекста при поиске уязвимостей, сочетая SAST и DAST.
Важную роль в практике DevSecOps играет Container Security. Этот класс практик включает анализ Docker-файлов, сканирование контейнерных образов на уязвимости компонентов, поиск секретов и небезопасных конфигураций, а также контроль избыточных привилегий. В более зрелых реализациях сюда добавляется защита кластера на этапе выполнения.
В компании мы используем решение по защите контейнерных сред – CrossTech Container Security. Помимо базовых функций, которыми обладают решения по контейнерной безопасности, продукт минимизирует поверхность атак при помощи однонаправленных соединений, а также защищает хосты вне оркестрации.
Отдельным направлением является Infrastructure as Code Security – проверка манифестов и конфигураций инфраструктуры. Проверки позволяют находить секреты, небезопасные настройки, избыточные права и слабые криптографические алгоритмы еще до развертывания инфраструктуры.
Центральным элементом экосистемы часто становится ASOC – система агрегации и управления уязвимостями. Для защиты пайплайнов и управления секретами используются Keystore Manager.
Дополняет экосистему OSA – практики отслеживания компонентов и их состояния, которые во многом пересекаются с SCA, но предоставляют более расширенные возможности контроля и анализа.
Все эти элементы образуют экосистему практик DevSecOps, в которой каждый тег закрывает свою зону ответственности. В зависимости от зрелости проекта и требований бизнеса этот набор может быть реализован частично или полностью, но именно их сочетание позволяет выстроить полноценный SSDLC на практике.
Детальный разбор инструментов DevSecOps
Мы прошлись по верхам составляющих облака тегов DevSecOps, теперь подробнее разберем ключевые классы инструментов и поймем, какие задачи они решают и как применяются на практике
Выделяется три основных подхода к статистическому анализу. Первый – анализ на основе сигнатур и правил. Он состоит из базы шаблонов и регулярных выражений, которые описывают потенциально уязвимые конструкции в коде. Такой подход прост в реализации, но может давать большое количество ложных срабатываний.
Второй подход – taint/dataflow-анализ, при котором отслеживаются потоки данных внутри приложения. Он позволяет лучше понимать, как данные проходят через код, и снижает количество ложных срабатываний. При этом минусом является более длительное время выполнения анализа, особенно на больших кодовых базах.
Третий подход – символьное исполнение. Он учитывает специфику кода и различные пути выполнения программы, что позволяет минимизировать количество ложных срабатываний. Но такие решения чаще всего являются коммерческими и требуют регулярной поддержки.
В качестве примеров SAST-инструментов можно привести SonarQube, Checkmarx, Fortify и Semgrep.
У динамического тестирования безопасности также выделяются три основных подхода. Blackbox-тестирование проводится без доступа к исходному коду. Его плюсы – максимальная реалистичность и независимость от используемых технологий. Минусы – сложность локализации уязвимостей и высокий риск пропуска внутренних ошибок.
Greybox-тестирование предполагает частичный доступ к информации о системе. Как правило, используется агент в среде выполнения, который позволяет получать больше контекста. Такой подход требует меньше ресурсов, чем whitebox, и упрощает поиск уязвимых участков кода, но ограничен уровнем предоставляемого доступа.
Whitebox-тестирование проводится при полном доступе к исходному коду и архитектуре приложения. Часто включает фаззинг и глубокий анализ логики. Оно обеспечивает высокий уровень покрытия и точное определение мест уязвимостей, но требует высокой квалификации и значительных временных затрат.
Среди DAST-инструментов можно выделить OWASP ZAP, Burp Suite, Acunetix и Nessus.
SCA, как мы писали ранее, отвечает за анализ сторонних библиотек и зависимостей, используемых в проекте. С его помощью выявляются известные уязвимости в компонентах, устаревшие и транзитивные зависимости, а также риски, связанные с лицензированием, например, использование GPL.
Работа SCA строится на формировании SBOM (Software Bill of Materials) – списка всех компонентов продукта с указанием их версий. Этот список сопоставляется с базами уязвимостей, за счет чего можно выявлять известные CVE.
Инструменты, которые часто используются: Dependency-Track и CycloneDX.
Container Security охватывает безопасность контейнеров и среды их выполнения. Для сканирования образов используется Trivy. Как это работает: берем образ, загружаем в SCA, находим избыточные привилегии и проблемы в окружении контейнера. В более зрелых реализациях добавляется защита кластера в runtime. Класс инструментов Infrastructure as Code применяется для анализа инфраструктурных манифестов, в частности в Kubernetes. Проверки позволяют выявлять секреты, небезопасные конфигурации, избыточные права и слабые криптографические алгоритмы еще до развертывания инфраструктуры.
Следующий подход – RASP, который позволяет выявлять атаки, пропущенные на этапе разработки, и обеспечивает самозащиту приложения без необходимости ручной настройки правил. Несмотря на то, что технология пока не получила массового распространения, ее популярность постепенно растет.
Для защиты CI/CD-пайплайнов используются Keystore Manager – решения, позволяющие безопасно хранить пароли, токены и ключи, не размещая их в коде или конфигурациях. Это обязательный элемент зрелого DevSecOps-процесса.
И последнее, но не по важности – ASOC. Система играет роль централизованного сбора и управления результатами всех проверок. В нее загружаются отчеты от SAST, DAST, SCA и других инструментов. ASOC позволяет дедуплицировать уязвимости, отслеживать SLA по их устранению, формировать отчеты по продукту и интегрироваться с системами управления задачами. Часто пользователями таких систем становятся специалисты по триажу уязвимостей, которые оценивают риски и формируют задачи для команд разработки.
Куда встраивать инструменты DevSecOps?
Чтобы инструменты DevSecOps приносили пользу, важно не только выбрать правильные решения, но и корректно встроить их в процесс разработки. Мы рассмотрим процесс на примере классического CI/CD-пайплайна.
Все начинается с разработчика. Он пишет код и коммитит изменения в репозиторий, после чего автоматически запускается пайплайн. В качестве CI/CD-систем чаще всего используются open-source-решения: GitLab CI или Jenkins.
На ранних этапах пайплайна запускаются проверки, связанные с безопасностью исходного кода и зависимостей. SCA и SAST могут выполняться еще до сборки или параллельно с ней. Компонентный анализ зачастую запускается первым – это позволяет выявить критические уязвимости в зависимостях и при необходимости остановить сборку еще до того, как будут затрачены ресурсы на дальнейшие этапы.
После успешного прохождения SCA и SAST начинается этап сборки. Готовый артефакт формируется и загружается в хранилище, например, в Nexus, Artifactory или аналогичные системы.
Далее продукт разворачивается в тестовом окружении, где запускаются автоматические тесты. Если после автотестов приложение не деградирует по функциональности или производительности, оно передается на этап DAST. Динамический анализ проверяет уже развернутое приложение на наличие инъекции, XSS-атак или других уязвимостей.
После успешного прохождения всех проверок пайплайн завершается, и формируется итоговый security-отчет. Этот отчет поступает в ASOC. В системе собираются данные от всех анализаторов, выполняется дедупликация находок и формируется единая картина состояния безопасности продукта.
Параллельно с основным пайплайном обычно работают вспомогательные системы – мониторинг состояния процессов и анализаторов, а также менеджеры секретов.
В случае сложных или многомодульных продуктов каждый модуль может проверяться отдельно, а все результаты агрегируются в ASOC. Это позволяет получить целостное представление о безопасности продукта, даже если он состоит из большого количества компонентов и репозиториев.
Примерно так инструменты DevSecOps распределяются по всему жизненному циклу разработки: от коммита кода и сборки до тестирования, деплоя и анализа результатов. Именно такой подход позволяет выстроить устойчивый и масштабируемый процесс безопасной разработки.
Надеемся, что статья помогла лучше разобраться в SSDLC и DevSecOps на практике, понять, когда имеет смысл внедрять эти подходы. До встречи в следующих публикациях!
