Что такое DevSecOps и какова его роль в CD?

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

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

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

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

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

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

Разработка по каскадному принципу предполагает линейный подход: вначале сбор требований, затем проектирование, разработка, интеграция, тестирование, и в конце концов (спустя месяцы, а то и годы) — релиз.

Фаза тестирования, как правило, включала долгие ручные процессы контроля качества, аудита безопасности и приемочного тестирования. Процесс с иронией называют «перекидыванием ПО через стену»: продукт просто передавался от одной команде к другой, и каждая составляла свой длинный отчет.

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

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

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

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

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

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

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

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

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