Что такое DevSecOps и какова его роль в CD?
DevSecOps говорит о том, что в циклы разработки ПО важно также включать меры по обеспечению безопасности. Сделав вопросы безопасности частью культуры команды, используемых ей процессов и инструментов, вы избежите разобщенности и проконтролируете, что быстрая доставка не дается вам ценой уязвимостей в коде.
Понимание DevOps
Перед тем, как мы углубимся в вопросы безопасности, давайте вкратце обсудим DevOps.
Тесно связанный с гибкими методологиями разработки, DevOps подразумевает создание культуры, в которой разработка ПО и операционная деятельность выполняются сообща и общая задача всех — обеспечить оперативную доставку пользователям работающего ПО. Чтобы реализовать это, DevOps предлагает использовать устойчивые автоматизированные процессы, которые ускоряют доставку и обеспечивают быструю обратную связь, создавая цикл непрерывных улучшений.
Пока неплохо. Однако вдруг, ускоряя процесс доставки ПО, вы пропустите что-нибудь важное? К сожалению, с вопросами безопасности это случается довольно часто. Именно эту проблему адресует DevSecOps.
Безопасность DevOps
Уязвимости представляют серьезную угрозу для ПО.
И мы имеем в виду не только финансовые и репутационные последствия. По причине уязвимостей происходят утечки огромного количества конфиденциальной информации — от внутренних документов до невыпущенных продуктов и персональных данных клиентов (включая пароли). В зависимости от юрисдикции за утечку пользовательских данных могут накладываться серьезные денежные штрафы и юридическая ответственность.
Несмотря на все это, команды разработчиков зачастую видят в безопасности не возможный актив, а некое обременение. Аудиты безопасности, составление отчетов — все это замедляет процесс и препятствует доставке новых возможностей прямиком в руки пользователей. Это мышление и играет на руку злоумышленникам. Не отводя вопросам безопасности должного места в цикле разработки ПО, мы рискуем увидеть новый Wannacry и Heartbleed.
В свое время эти уязвимости попали в новостные заголовки. А ведь их причины оказались довольно прозаичными. Код пишут люди, а люди делают ошибки — так и появляются уязвимости. Бывают всем известные ошибки — их проще обнаружить (правда надо знать, где искать). Но порой ошибки бывают и новыми, возникающими в результате новой комбинации факторов.
Ситуация также усложняется тем, что практически любое ПО (и с открытым исходным кодом, и проприетарное) включает зависимости, и вы не можете быть уверенными, что сторонний код не содержит уязвимостей.
Как же включить аспекты безопасности в цикл разработки ПО? Подход DevSecOps предлагает применять к практикам безопасности те же принципы, которые позволяют нам наладить быстрые стабильные релизы — принципы сотрудничества, общей ответственности и максимальной автоматизации.
Сдвиг безопасности влево
Разработка по каскадному принципу предполагает линейный подход: вначале сбор требований, затем проектирование, разработка, интеграция, тестирование, и в конце концов (спустя месяцы, а то и годы) — релиз.
Фаза тестирования, как правило, включала долгие ручные процессы контроля качества, аудита безопасности и приемочного тестирования. Процесс с иронией называют «перекидыванием ПО через стену»: продукт просто передавался от одной команде к другой, и каждая составляла свой длинный отчет.
За одну из этих стадий отвечала команда информационной безопасности. Она составляла отчет по безопасности с детальным списком обнаруженных проблем и рекомендаций. Зачастую требовались изменения в коде, после которых нужно было повторять все стадии, чтобы убедиться, что все было реализовано верно (или неверно). Неудивительно, что при таком затяжном процессе релизы становились настоящим праздником.
Ситуацию изменили гибкие методологии разработки, движение DevOps и развитие облачных вычислений. В условиях жесткой конкуренции скорость имеет решающее значение. Если вы не работаете с потребностями пользователей и не устраняете возникающие проблемы оперативно, пользователи вскоре предпочтут вместо вас другого провайдера, который это делает. Поэтому регулярные релизы и возможность быстро выпускать исправления ошибок стали новым стандартом для многих организаций, и ключевой частью их процессов является CI/CD-пайплайн.
Появление термина DevSecOps не означает, что DevOps исключает вопросы безопасности.
Однако, к сожалению, на деле оказывалось, что с объединением команд разработчиков и операционистов команды информационной безопасности в основном оставались в стороне. Чтобы решить эту проблему, придумали DevSecOps, а также несколько его вариаций, таких как SecDevOps, DevOpsSec и Rugged DevOps.
DevSecOps подчеркивает, что важно обеспечивать безопасность с самого начала, включая вопросы безопасности в культуру общего понимания и ответственности, а также встраивать проверки безопасности в автоматизированные тесты CI/CD-пайплайна. Как и в случае с операционной деятельностью, вместо того, чтобы внедрять требования и практики, связанные с безопасностью, уже после создания продукта, лучше выполнить сдвиг безопасности влево.
Добавляем Sec в DevSecOps: Security as Code
Те, кто не в курсе дела, могут подумать, что сдвиг безопасности влево означает, что вам просто нужно предоставлять ваше ПО для тестирования командой безопасности в рамках CI/CD-пайплайна.
Ручному тестированию безопасности, безусловно, есть место в процессе, и мы обсудим это подробнее ниже. Однако отводя требованиям по безопасности лишь некий шаг в конце пайплайна, вы, по сути, делаете то же самое «перекидывание ПО через стену» и ожидаете прихода отчета.
В результате, вероятнее всего, рекомендации будут проигнорированы, потому что реализация потребует много времени, либо весь процесс с грохотом остановится и релиз будет отложен на неопределенный срок — для решения найденных проблем и оценки рисков. Так или иначе, это порождает разобщенность между командой безопасности и всеми остальными, из-за чего добиться нужного результата — выпуска ценного и при том безопасного ПО — становится сложно.
Как работает метод сдвига влево на практике? Универсального решения нет, однако есть набор инструментов и техник, которые помогают включить вопросы безопасности в цикл разработки ПО.
Назначьте экспертов по безопасности
Культура общей ответственности очень важна. Однако недостаточно просто сказать разработчикам, что теперь они все отвечают за безопасность ПО. Отслеживание новых векторов атак и разработок вредоносного ПО — это работа, на которую нужен отдельный сотрудник. Вы не можете ожидать от всех того же уровня экспертизы. Введя в многопрофильную команду эксперта по безопасности, который поделится своими знаниями лучшими практиками, вы поможете вашим сотрудникам осознать и поддержать культуру сотрудничества с профессионалами в области безопасности.
Учитывайте безопасность на стадии проектирования
Чтобы разработчики разделяли ответственность за безопасность разрабатываемого ПО, эти вопросы нужно рассматривать еще до написания кода. Безопасность должна быть отражена в пользовательских историях. Она должна обсуждаться при рассмотрении бэклога и планировании спринтов. Продумывая новую функциональность, уделите время рассмотрению тех рисков, которые она может нести, и того, как их можно снизить.
Стратегия моделирования угроз STRIDE и инструменты вроде шпаргалки OWASP помогут вам придерживаться правильного курса. Продумывая безопасность на стадии проектирования, вы не сможете учесть всего, но это уже заложит хорошее начало и будет продвигать культуру DevSecOps.
Добавляйте в пайплайн авто-тесты на безопасность
Автоматизация — центральный принцип DevOps. Она не только ускоряет выполнение задач и обеспечивает консистентность, но и разгружает людей, освобождая время для более креативной работы. Если вы хотите доставлять продукт пользователям регулярно и часто, важно, чтобы в вашем пайплайне были автоматизированные тесты на безопасность.
При написании юнит-тестов, а также автоматизированных интеграционных и сквозных тестов, обеспечение безопасности должно рассматриваться наравне с любой другой функциональностью. Если на этапе проектирования ваша команда включала требования по безопасности в пользовательские истории и модели угроз, добавить тесты, покрывающие эти функции, — вполне естественно.
Заручитесь помощью экспертов
Помимо написанных лично вами тестов есть различные инструменты тестирования, которые помогут вам быть увереннее в качестве вашего кода. Традиционные инструменты сканирования безопасности не очень хорошо подходят для автоматизированного CI/CD-конвейера, но теперь доступны инструменты, которые специально разработаны для автоматизации и интегрируются в конвейер, а результаты отображаются на панели мониторинга или напрямую передаются в баг-трекер. Как и с любыми автоматизированными тестами, имеет смысл ввести структуру, чтобы оперативно получать результаты по разным категориям.
Инструменты статического тестирования безопасности приложений (Static Application Security Testing, SAST) выполняют статический анализ кода, проверяя его на известные уязвимости (переполнение буфера, внедрение SQL-кода и т. д.). Поскольку статический анализ кода выполняется для исходного кода, его можно запускать на ранних стадиях CI/CD-пайплайна — сразу после коммита изменений.
Инструменты SAST привязаны к языку. Некоторые из них интегрируются с IDE, обеспечивая таким образом непрерывный цикл обратной связи (прямо в ходе написания кода) и возможность в любой момент запустить тесты. Инструменты SAST указывают разработчикам на строки кода, содержащие уязвимости — это позволяет им быстро вносить исправления. Однако бывают и ложноположительные уведомления. Чтобы результаты SAST не стали бесполезным фоновым шумом, важно уметь отключать некоторые уведомления.
Вслед за SAST появилось и динамическое тестирование безопасности приложений (Dynamic Application Security Testing, DAST). Они рассматривают приложение как черный ящик и проверяют его на предмет известных уязвимостей, таких как межсайтовый скриптинг, внедрение команд и SQL-кода небезопасная конфигурация сервера. Инструменты DAST работают с уже собранным и развернутым приложением, поэтому обычно они используются на более поздних стадиях CI/CD-пайплайна.
Проверяйте зависимости
Анализ состава/компонентов ПО (Software Composition/Component Analysis, SCA) — это еще один вид автоматизированного тестирования безопасности, который можно выполнять а ранних этапах процесса. Как было сказано выше, практически любая кодовая база включает библиотеки и другие компоненты с открытым исходными кодом, которые могут вносить уязвимости.
Инструменты SCA исследуют не только присутствующие зависимости, но и зависимости каждой зависимости (рекурсивно). Это прекрасный пример задачи, которую эффективнее выполнять при помощи компьютера, особенно если учесть, насколько часто в проект добавляются зависимости.
Инструменты SCA можно автоматически запускать в рамках CI/CD-пайплайнов. Некоторые из них также доступны в виде плагинов для IDE, обеспечивающих обратную связь буквально на лету. SCA-тестирование (так же, как статическое и динамическое) анализирует ПО лишь на предмет известных уязвимостей. Поэтому нужно следить, чтобы используемые вами инструменты регулярно пополнялись новыми уязвимостями и покрывали те области, которые имеют отношение к вашему продукту и организации. Что касается поиска новых уязвимостей (которых вы не ожидаете), здесь вам не обойтись без участия человека.
Зовите красную команду
Понятие красной команды пришло из игр про войну, где вы просили ваших соратников симулировать атаку врага, чтобы определить слабые места вашей защиты и стратегии. Тот же подход широко используется при разработке ПО, например, в виде тестирования на проникновение или этичного хакинга.
Чтобы красная команда срабатывала эффективно, она не должна участвовать в разработке тестируемой системы. Как и те, кто занимается исследовательским тестированием, тестировщики красной команды должны уметь мыслить нестандартно и использовать программное обеспечение не по назначению.
Красная команда может работать либо в тестовом окружении (максимально близком к продакшну), либо непосредственно с системой в продакшне. Последнее предполагает, что вы можете с уверенностью положиться на поведение вашей системы в случае ошибки либо у вас очень толерантные пользователи (и высокопрофессиональные менеджеры!).
Уязвимости — это те же ошибки
Подход DevSecOps предполагает, что ответственность за безопасность продукта несет вся команда. Поэтому не стоит разделять уязвимости и «обычные» ошибки. Любые уязвимости, которые вы обнаружили, должны попадать в тот же бэклог, что и другие проблемы, и приоритизироваться наравне с ними.
Ответственность за устранение уязвимостей лежит на всей команде, не только на эксперте по безопасности. Такой подход помогает расширять знания и экспертизу команды, а приобретенные навыки можно будет впоследствии применить и на других проектах.
Следите за продакшном
Несмотря на все меры, которые вы ввели на предыдущих этапах цикла разработки, риск того, что хакер все же найдет слабое место в вашей системе, все равно остается. Чтобы защитить вашу организацию и пользователей, имеет смысл подключить брандмауэры и инструменты мониторинга. Инструменты самозащиты приложения во время выполнения (Runtime Application Self Protection, RASP) также обеспечат дополнительную защиту и позволят автоматически выявлять и блокировать подозрительное поведение.
Подводя итог
Сдвиг безопасности влево предполагает, что вопросы безопасности рассматриваются всей командой на каждой стадии цикла разработки. При использовании практик DevOps итерации жизненного цикла происходят часто, а значит вам и вашей команде будет регулярно поступать информация о поведении вашего ПО и о том, как его используют в реальном мире. Внедрение аспектов безопасности в ваш CI/CD-пайплайн подразумевает, что вы регулярно получаете обратную связь по безопасности вашего приложения и можете вводить необходимые улучшения точно так же, как вводите другую функциональность.
Выявляя известные уязвимости и обеспечивая защиту от них, вы по крайней мере не будете отставать от злоумышленников. Относясь к каждой найденной уязвимости как к обычной ошибке, которую нужно отследить, исправить и протестировать, вы со временем сделаете ваше ПО более устойчивым.
В конце концов, DevOps (а значит и DevSecOps) — это не только инструменты и процессы, позволяющие осуществлять быструю и частую доставку ПО, но и особая культура. Все это возможно только благодаря людям. Если вы хотите включить вопросы безопасности в цикл разработки ПО, важно создать культуру разделения ответственности и никогда не обвинять конкретных людей. У каждого должна быть возможность поднять вопрос безопасности и быть услышанным — будь то во время планирования спринта, код-ревью, ручного тестирования или уже после запуска системы в продакшне. И каждый может сыграть свою роль в оценке важности безопасности и в ее реализации.