Из-за большого количества терминов и информационного шума в сфере кибербезопасности такие разные термины, как AppSec и DevSecOps, время от времени путают. Последняя волна контента, сгенерированного искусственным интеллектом, только мешает найти правду. Поэтому далее проанализируем сходства, различия и пересечения между AppSec и DevSecOps.
Действительно ли это два разных термина?
На первый взгляд, эти два термина довольно четкие и отличные. AppSec это сокращение от application security – области кибербезопасности, занимающейся созданием безопасного программного обеспечения, его запуском без уязвимостей и защитой от атак. Это очень широкая сфера: она охватывает анализ кода, тестирование исправных приложений, защиту развертываний и многое другое с использованием различных методологий и инструментов. В технической индустрии AppSec часто используется в узком смысле — для поиска и устранения уязвимостей в веб-приложениях.
DevSecOps – это термин, описывающий рабочий процесс и культуру включения безопасности в DevOps, методологию, которая объединяет разработку приложений и операции в один интегрированный, высокоавтоматизированный и непрерывный процесс. DevSecOps (или SecDevOps) появился, поскольку команды DevOps значительно опережали традиционные методы тестирования и устранения уязвимостей. Чтобы минимизировать риски безопасности без замедления быстрой разработки и доставки программного обеспечения, в пайплайн пришлось добавить автоматизированные инструменты безопасности и рабочие процессы – и “Sec” добавилось к “DevOps.”
Имея эти определения, разберёмся, как эти два понятия пересекаются и почему они могут путаться.
Разные подходы к практике безопасности
Можно сказать, что DevSecOps – это систематический способ добавления application security в жизненный цикл разработки программного обеспечения, что намекает на утверждение, что DevOps + AppSec = DevSecOps. Итак, означает ли это, что когда команды DevOps просят “shift left” и вообще начать заниматься безопасностью в их цикле разработки, они на пути к тому, чтобы стать командами DevSecOps? Если смотреть только на процесс разработки, являются ли AppSec и DevSecOps в основном эквивалентными?
DevSecOps – это больше культура, чем конкретная методология, с акцентом на внедрение мышления о безопасности в процесс DevOps. Это о том, чтобы сделать безопасность рутинным и обязательным аспектом качества программного обеспечения наравне с функциональностью, производительностью, поддержкой и так далее. Однако, поскольку пайплайн DevOps является высокоавтоматизированным, переход к DevSecOps должен быть подкреплён такими же автоматизированными (но всё ещё точными) инструментами безопасности. Здесь и начинаются дискуссии об инструментах AppSec и DevSecOps.
Варианты интеграции “AppSec” в “DevSecOps”
Идея сделать безопасность частью качества программного обеспечения хороша в теории. В реальности команды разработки имели сложные отношения с безопасностью. Когда говорят об инструментах DevSecOps, обычно имеются в виду инструменты безопасности, которые могут работать в автоматизированных механизмах DevOps, не нарушая потока работы.
Есть три основных способа проведения автоматизированного и непрерывного тестирования безопасности приложений в процессе DevOps: два статических (SAST и SCA) и один динамический (DAST). Каждый из них имеет свои преимущества и ограничения, поэтому наилучшая практика безопасности приложений заключается в использовании всех трёх на разных этапах процесса, чтобы максимально использовать их сильные стороны.
Зачем нужен SCA?
SCA решает проблему широкого использования компонентов с открытым кодом. При быстром темпе разработки наличие подобных каркасов и готовых деталей является необходимостью, помогая разработчикам стандартизировать процессы и сосредотачиваться на специальной бизнес-логике, а не на создании общих рутин с нуля.
Внедрение проверок SCA в пайплайн (конвейеры) является распространенной практикой, что помогает идентифицировать и обновлять (или избегать) известные уязвимые компоненты. Некоторые инструменты SCA также могут проверять соответствие лицензий и сканировать базы кода на наличие фрагментов открытого кода. Недостатком является то, что SCA может генерировать много предупреждений, которые не применимы в конкретном контексте и которые разработчикам приходится фильтровать или просто игнорировать.
Является ли SAST безопасным?
Наиболее распространенным методом добавления проверок безопасности к разработке является сканирование кода на уязвимости сразу после его написания, так же как Linter (программа, которая используется разработчиком как “инструмент статического анализа кода, который используется для улучшения качества кода”) и другие инструменты для разработчиков запускаются для нахождения ошибок в коде. Инструменты SAST могут работать непосредственно в IDE или как отдельный процесс анализа. Они также имеют преимущество в том, что они легко интегрируются в SDLC и могут использоваться на любом этапе разработки, даже на коде, который еще не работает или не будет доступен запущенным приложением.
Как и в случае с SCA, наибольшим недостатком SAST является довольно низкая точность из-за наличия ложноположительных срабатываний, но неактуальных предупреждений. Инструменты SAST также специфичны для программных языков и ограничены кодом, который фактически находится в активной разработке. А поскольку это статический анализ, он не может подтвердить, возможно ли будет использовать эту уязвимость и не выявит уязвимостей в режиме выполнения.
Взгляд со стороны на DAST
Инструменты DAST необходимы для DevSecOps, поскольку они расширили свою традиционную роль внешних сканеров уязвимостей, чтобы обеспечивать динамическое тестирование во время QA и на ранних этапах сборки. DAST может сканировать любое рабочее веб-приложение и API (даже прототип) на уязвимости, независимо от используемых технологий и компонентов. Качественные инструменты имеют очень низкий уровень ложноположительных срабатываний и требуют значительно меньше настроек и регулировок по сравнению с SAST для получения полезных результатов. Они также непосредственно интегрируются с популярными инструментами отслеживания проблем и инструментами для сотрудничества, чтобы отправлять проблемы безопасности непосредственно разработчикам вместе с рекомендациями по их устранению.
Обратная сторона динамического тестирования всех рабочих приложений извне заключается в том, что любой не загруженный код не будет протестирован. DAST также не может тестировать чисто статический код, как изолированный фрагмент или модуль, и часто предоставляет немного менее точные места выявления проблем, чем конкретная строка кода, на которую может указать SAST. Качество и удобство использования результатов DAST могут сильно варьироваться в зависимости от конкретного инструмента и его технической зрелости — хороший DAST может стать основой процесса DevSecOps, тогда как некачественный DAST быстро выйдет из употребления из-за создания большего количества проблем, чем их решения.
Непрерывный процесс безопасности, независимо от названия
AppSec и DevSecOps являются тесно связанными терминами, которые пересекаются во многих моментах. Одно из ключевых различий заключается в том, что каждая организация, которая запускает приложения, должна иметь и внедрять программу AppSec, даже если она не разрабатывает собственное программное обеспечение. DevSecOps как процесс разработки программного обеспечения актуален только тогда, когда создаются и запускаются собственные приложения. Еще одним пересечением является то, что любая современная организация определенного размера создает по крайней мере часть своего программного обеспечения внутренне.
Самое важное заключается в том, что безопасность приложений должна быть внедренной и разделенной ответственностью в любой организации, которая разрабатывает программное обеспечение. Большинство популярных терминов из этой сферы сводятся к наличию рутинного и непрерывного процесса безопасности программного обеспечения. Это начинается с безопасного кодирования и дизайна, продолжается автоматизированным тестированием на наличие уязвимостей безопасности и заканчивается операционной стороной поддержания надлежащего уровня защиты на производстве. Название обеспечения не имеет значения до тех пор, пока используются эффективные инструменты и процессы для контроля риска безопасности.
