Что такое DevSecOps?

DevSecOps — методология разработки ПО, где на каждом этапе работы учитываются требования безопасности. В результате уязвимости устраняются в самом начале и не замедляют CI/CD-пайплайн.

Методология DevSecOps подчеркивает, что важно внедрять тестирование безопасности и методы ее обеспечения на каждом этапе разработки ПО. Раннее внедрение безопасности (сдвиг влево) позволяет гарантировать, что быстрая доставка не ведет к появлению уязвимостей в коде.

Преимущества сервера непрерывной интеграции

DevSecOps — подход к разработке ПО на основе методологии DevOps. DevOps объединяет разработку (development) и эксплуатацию (operations), а DevSecOps добавляет к этому безопасность (security). Тем самым подчеркивается, что важно учитывать требования безопасности на каждом этапе разработки ПО.

Триада DevSecOps

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

DevSecOps и DevOps

Методология DevOps нацелена на ускорение доставки ПО при одновременном повышении качества и сокращении числа багов. В основе DevOps лежат принципы Agile-разработки. Методология была создана для решения проблем, возникающих при традиционном каскадном подходе к разработке и доставке ПО.

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

В чем разница между DevSecOps и DevOps? Методология DevOps вовсе не исключает вопросы безопасности. Однако на деле получалось, что DevOps объединяет именно команды разработчиков и операционистов, а команды информационной безопасности в основном оставались в стороне. Чтобы решить эту проблему, придумали DevSecOps, а также несколько его вариаций, таких как SecDevOps, DevOpsSec и Rugged DevOps.

Термин «DevSecOps» напоминает всем участникам, что вопросы безопасности должны постоянно учитываться в процесс разработки и развертывания ПО. Сюда входят:

  • распространение культуры взаимопонимания и ответственности за решение вопросов, касающихся безопасности;
  • разработка проверок безопасности, которые выполняются автоматически при тестировании в рамках CI/CD-пайплайна;
  • обеспечение безопасности цепочки поставок ПО, включая все зависимости и сам CI/CD-пайплайн.
Практики DevSecOps

Точно так же, как «сдвиг влево» позволяет быстрее и проще находить устранять ошибки, методы обеспечения безопасности проще внедрить и эффективнее использовать на ранних этапах процесса разработки.

Преимущества DevSecOps

Уязвимости представляют серьезную угрозу для ПО.

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

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

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

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

Как же включить аспекты безопасности в цикл разработки ПО? DevSecOps-подход использует те же принципы, что и для организации более быстрых и стабильных релизов: сдвиг безопасности влево, то есть решение этих вопросов на более ранних этапах и более регулярно.

Сдвиг тестирования влево

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

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

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

Внедрение тестирования безопасности на ранних этапах

Как работает метод сдвига безопасности влево на практике? Универсального решения нет, однако есть набор инструментов и техник, которые помогают включить вопросы безопасности в цикл разработки ПО.

Назначьте экспертов по безопасности

Культура общей ответственности очень важна. Однако недостаточно просто сказать разработчикам, что теперь они все отвечают за безопасность ПО. Отслеживание новых векторов атак и разработок вредоносного ПО — это работа, на которую нужен отдельный сотрудник. Вы не можете ожидать от всех того же уровня экспертизы.

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

Учитывайте безопасность на стадии проектирования

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

Стратегия моделирования угроз STRIDE и инструменты вроде шпаргалки OWASP помогут вам придерживаться правильного курса. Продумывая безопасность на стадии проектирования, вы не сможете учесть всего, но это уже заложит хорошее начало и будет продвигать культуру DevSecOps.

Моделирование угроз STRIDE

Включите проверки безопасности в автоматизированные тесты

Автоматизация — центральный принцип DevOps. Она ускоряет выполнение задач и обеспечивает консистентность, а также разгружает людей, освобождая время для более творческой работы. Если вы хотите доставлять продукт пользователям регулярно и часто, важно, чтобы в вашем пайплайне были автоматизированные тесты на безопасность.

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

Добавьте инструменты тестирования в CI/CD-пайплайн

Помимо написанных лично вами тестов есть различные инструменты тестирования, которые помогут вам быть увереннее в качестве вашего кода. Традиционные инструменты сканирования безопасности не очень хорошо подходят для автоматизированного CI/CD-пайплайна, но сейчас появились инструменты, разработанные специально для него. Они встраиваются в пайплайн и передают результаты на панель мониторинга или напрямую в баг-трекеры. Как и с любыми автоматизированными тестами, имеет смысл ввести структуру, чтобы оперативно получать результаты по разным категориям.

Инструменты статического тестирования безопасности приложений (Static Application Security Testing, SAST) выполняют статический анализ кода, проверяя его на известные уязвимости (переполнение буфера, внедрение SQL-кода и т. д.). Поскольку статический анализ кода выполняется для исходного кода, его можно запускать на ранних стадиях CI/CD-пайплайна — сразу после коммита изменений.

Инструменты SAST привязаны к языку. Некоторые из них интегрируются с IDE, обеспечивая таким образом непрерывный цикл обратной связи (прямо в ходе написания кода) и возможность в любой момент запустить тесты. Инструменты SAST указывают разработчикам на строки кода, содержащие уязвимости, — это позволяет им быстро вносить исправления. Однако бывают и ложноположительные уведомления. Чтобы результаты SAST не стали бесполезным фоновым шумом, важно уметь отключать некоторые уведомления.

Использование инструментов SAST в CI/CD

Динамическое тестирование безопасности приложений (Dynamic Application Security Testing, DAST) появилось вслед за SAST. Они рассматривают приложение как черный ящик и проверяют его на предмет известных уязвимостей, таких как межсайтовый скриптинг, внедрение команд и SQL-кода небезопасная конфигурация сервера. Инструменты DAST работают с уже собранным и развернутым приложением, поэтому обычно они используются на более поздних стадиях CI/CD-пайплайна.

Обеспечьте безопасность цепочки поставок ПО

У киберпреступников много возможностей для атаки. Злоумышленники часто находят уязвимости в широко распространенном ПО. Такие атаки служат постоянным напоминанием о том, насколько важно обеспечить безопасность вашей цепочки поставок ПО.

Под «цепочкой поставок ПО» мы, попросту говоря, понимаем все, что связано с разработкой и доставкой вашего продукта. Для разработки ПО необходимо другое ПО — от повторно используемых компонентов и библиотек до IDE, фреймворков и инструментов сборки. Чтобы обеспечить безопасность цепочки поставок ПО, необходимо оценить безопасность того ПО, которое вы используете в процессе разработки.

Для такой оценки можно использовать инструменты анализа состава/компонентов ПО (Software Composition/Component Analysis, SCA). Инструменты SCA исследуют не только присутствующие зависимости, но и зависимости каждой зависимости (рекурсивно). Это прекрасный пример задачи, которую эффективнее выполнять при помощи компьютера, особенно если учесть, насколько часто в проект добавляются зависимости.

Цепочка поставок ПО

Инструменты SCA можно автоматически запускать в рамках CI/CD-пайплайнов. Некоторые из них также доступны в виде плагинов для IDE, обеспечивающих обратную связь буквально на лету. SCA-тестирование (так же, как статическое и динамическое) анализирует ПО лишь на предмет известных уязвимостей. Поэтому нужно следить, чтобы используемые вами инструменты регулярно пополнялись новыми уязвимостями и покрывали те области, которые имеют отношение к вашему продукту и организации.

Зовите красную команду

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

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

Красная команда может работать в тестовом окружении (максимально близком к продакшну) или непосредственно с системой в продакшне. Последнее предполагает, что вы можете с уверенностью положиться на поведение вашей системы в случае ошибки либо у вас очень толерантные пользователи (и руководители).

Уязвимости — это те же ошибки

Подход DevSecOps предполагает, что ответственность за безопасность продукта несет вся команда. Поэтому не стоит разделять уязвимости и «обычные» ошибки. Любые уязвимости, которые вы обнаружили, должны попадать в тот же бэклог, что и другие проблемы, и приоритизироваться наравне с ними.

За устранение уязвимостей отвечает вся команда, не только специалист по безопасности. Это поможет всем сотрудникам лучше разбираться в вопросах безопасности и применять полученные знания и навыки при работе как с текущей кодовой базой, так и на будущих проектах.

Следите за продакшном

Несмотря на все меры, которые вы ввели на предыдущих этапах цикла разработки, риск того, что хакер все же найдет слабое место в вашей системе, все равно остается. Чтобы защитить вашу организацию и пользователей, имеет смысл подключить брандмауэры и инструменты мониторинга. Инструменты самозащиты приложения во время выполнения (Runtime Application Self Protection, RASP) также обеспечат дополнительную защиту и позволят автоматически выявлять и блокировать подозрительное поведение.

Заключение

  • Важная часть методологии DevOps — регулярные циклы обратной связи, позволяющие повысить качество разрабатываемого ПО и выпускать его чаще.
  • Сдвиг безопасности влево предполагает, что вопросы безопасности рассматриваются всей командой на каждой стадии цикла разработки.
  • Внедрение аспектов безопасности в ваш CI/CD-пайплайн подразумевает, что вы регулярно получаете обратную связь по безопасности вашего приложения и можете вводить необходимые улучшения точно так же, как вводите другую функциональность.
  • Безопасность цепочки поставок не менее важна, чем безопасность кода вашего собственного приложения. Выявляя известные уязвимости и обеспечивая защиту от них, вы по крайней мере не будете отставать от злоумышленников.
  • Относясь к каждой найденной уязвимости как к обычной ошибке, которую нужно отследить, исправить и протестировать, вы со временем сделаете ваше ПО более устойчивым.
  • DevOps и DevSecOps — это не только инструменты и процессы, но и особая производственная культура. Встраивание безопасности в процесс разработки ПО требует внедрения культуры совместной ответственности.