DevSecOps в текущих реалиях: что изменилось и как быть?

Тема безопасной разработки сегодня актуальна как никогда. На рынке есть большой спрос на создание безопасных программных решений, а потому без DevSecOps никак не обойтись. Что изменилось в текущих реалиях, когда крупные игроки ушли с нашего рынка, а использовать оставшийся зарубежный софт может быть рискованно и даже, в некоторых случаях, опасно? Постарается разобраться в этом и подумать над вариантами решения существующих проблем. Статья будет полезна всем, кто работает в области ИБ и делает продукт в своей компании более безопасным.

Автор: Юрий Шабалин, ведущий архитектор Swordfish Security

Процесс безопасной разработки

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

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

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

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

Для примера обратимся к одному из возможных процессов в популярной практике, основанной на анализе компонентов с открытым исходным кодом (см. рис. 2).

Порядок работы с уязвимой компонентой, обнаруженной в процессе анализа используемых библиотек с открытым исходным кодом, можно описать следующим образом:

1. Идентифицируется репозиторий исходного кода, в котором была обнаружена библиотека с уязвимостями.
2. Инженер ИБ проводит анализ уязвимости, ее критичности и возможностей эксплуатации.
3. Если существует безопасная версия и ее можно использовать, то инженер ИБ создает дефект с рекомендацией перейти на данную версию компоненты. В ином случае процесс переходит на шаг 6.
4. Если команда разработки готова сразу отказаться от использования уязвимой компоненты (то есть готова устранить дефект в ближайшее время), то процесс заканчивается с ошибкой – компонента недоступна. В ином случае процесс переходит на шаг 5.
5. Команда разработки не может в ближайшее время отказаться от использования уязвимой компоненты. В этом случае определяется дата или релиз устранения дефекта, связанного с данной компонентой. Процесс переходит на шаг 8.
6. Уязвимая компонента не имеет безопасной версии. Необходимо провести анализ уязвимого кода компоненты и оценить вероятность его использования. Если ни при каких условиях нельзя применять компоненту, инженер ИБ создает дефект с рекомендацией отказаться от ее использования. Процесс переходит на шаг 4. В ином случае – принятие компенсационных мер, процесс переходит на шаг 7.
7. Если эксплуатация уязвимости зависит от способа применения компоненты в исходном коде приложения, то необходимо создать правило в инструменте статического анализа, осуществляющее проверку на наличие условий, при которых исключается эксплуатация уязвимости. В ином случае – принять компенсирующие меры на стороне WAF, конфигурации, ручного ревью кода и т.д.
8. Разрешить использование компоненты с уязвимостью с применением компенсирующих мер.
9. Процесс заканчивается успешно.

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

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

Что изменилось и как действовать

Что изменилось в DevSecOps в связи с текущей ситуацией на рынке? На самом деле поменялась только одна часть – инструменты. Их стало существенно меньше, так как ведущие западные игроки вышли из игры, а использовать оставшиеся зарубежные решения достаточно опасно: неизвестно, что будет с ними через некоторое время и как они себя поведут.

Таким образом, сейчас нужно ориентироваться только на российские разработки и рассматривать возможность импортозамещения различных инструментов DevSecOps либо использовать Open Source. Инструменты с открытым исходным кодом стоит применять с большой осторожностью, поскольку в последнее время участились случаи добавления в новые версии различных бэкдоров, недекларируемых возможностей и прочих неприятных сюрпризов.

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

Первый сценарий. Начало построения DevSecOps

Если компания только начинает строить процесс и подходить к выбору инструментов, здесь все гораздо проще. Достаточно пойти по правильному пути, понять, описать процессы и при выборе инструмента учитывать все текущие реалии и ограничения.

Второй сценарий. Правильный путь

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

Третий сценарий. Процесс на основе инструментов

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

Показатели оптимального инструмента

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

1. Время анализа. Если от момента попадания кода в репозиторий до выхода на продуктивную среду уходит 30 минут (включая все тесты и сборку), проверки на информационную безопасность не сильно повлияют на итоговый результат. Можно это решить, предусмотрев ответвление в процессе, и проводить проверки параллельно, но не стоит забывать о последовательном запуске. В этом случае пригодится возможность проведения "быстрого анализа", или, как его называют, инкрементального.
2. Уровень False Negative или False Positive. Все разрабатываемые продукты уникальны, они используют различные фреймворки и свой стиль написания кода. На разных кодовых базах и технологиях инструменты могут показывать разный уровень False Negative и False Positive. Поэтому нужно определить, что именно в вашей компании и для ваших приложений будет показывать хороший и достоверный результат.
3. Интеграции с существующими инструментами. Смотрите на инструменты с точки зрения интеграций с тем, что вы уже используете. Например, если у вас Jenkins или TeamCity, оцените, как будут взаимодействовать инструменты именно с этим ПО. После детализации работы процессов можно понять, в каких точках и с какими инструментами необходима интеграция.
4. Возможности кастомизации. Если у инструмента нет API, то зачем он нужен? Все, что можно сделать в интерфейсе, должно быть доступно для автоматизации. Дополнительно у инструмента должна быть возможность написания собственных проверок или изменения встроенных правил для более точной работы и для интеграции с другими практиками (как в примере выше в связке анализа используемых библиотек и анализа кода).
5. Roadmap развития продукта. Разработка не стоит на месте, мы всегда используем новые фреймворки и функции, переписываем старый код на новые языки. Мы хотим быть уверенными, что инструмент, который мы приобретаем, будет поддерживать новые технологии. Поэтому важно знать, есть ли у продукта реальный и правильный план развития. Дополнительно к этому стоит отметить возможность повлиять на совершенствование продукта. Важно понимать, как вендор работает с запросами пользователей на добавление нового, необходимого для вас, функционала.

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

Что будет дальше?

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

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

Сегодня у отечественных производителей есть все шансы предложить решения намного удобнее, лучше и производительнее тех, что есть у западных вендоров. Главное – слушать своих заказчиков и принимать верные решения!