Тема безопасной разработки сегодня актуальна как никогда. На рынке есть большой спрос на создание безопасных программных решений, а потому без DevSecOps никак не обойтись. Что изменилось в текущих реалиях, когда крупные игроки ушли с нашего рынка, а использовать оставшийся зарубежный софт может быть рискованно и даже, в некоторых случаях, опасно? Постарается разобраться в этом и подумать над вариантами решения существующих проблем. Статья будет полезна всем, кто работает в области ИБ и делает продукт в своей компании более безопасным.
Автор: Юрий Шабалин, ведущий архитектор Swordfish Security
Для начала хотелось бы напомнить еще раз, что такое процесс безопасной разработки, а также посмотреть на основные принципы его построения, так как это существенно поможет нам в дальнейшем.
Рис. 1. Процесс безопасной разработки
Процесс безопасной разработки – это интеграция практик безопасности в разработку таким образом, чтобы вместе они создавали единый, непрерывный и законченный процесс, каждый участник которого знает свою зону ответственности, задачи и требования. Ключевое слово в этой фразе – процесс.
Самая распространенная ошибка при начале формирования этой активности в компании связана с выбором инструментов. Нередко организация сначала их закупает, а уже потом пытается как-то интегрировать в имеющиеся процессы. Порой это приводит к печальным последствиям, когда дорогие и хорошие, но не подходящие конкретной компании инструменты начинают создавать больше проблем, чем пользы, а вместо тесной интеграции они стоят отдельно и на них просто проводят периодические проверки с переменным успехом.
А нужно действовать по-другому: сначала понять, какие процессы есть в разработке, какие решения используются, какие нюансы присутствуют и как их учитывать. И только после того, как сформируется полное понимание технологий внутри компании, нужно... Нет, не покупать инструменты, а понять, как все будет устроено, как все участники станут взаимодействовать друг с другом, у кого какие зоны ответственности и как это лучше автоматизировать.
Для примера обратимся к одному из возможных процессов в популярной практике, основанной на анализе компонентов с открытым исходным кодом (см. рис. 2).
Рис. 2. Работа с уязвимостями в библиотеках с открытым исходным кодом
Порядок работы с уязвимой компонентой, обнаруженной в процессе анализа используемых библиотек с открытым исходным кодом, можно описать следующим образом:
В приведенном примере работа с уязвимостями и участие в ней каждой стороны описываются прозрачно. Понятно, где находится зона ответственности разработки, где безопасности, а также что происходит при любом варианте развития событий. И все это вне зависимости от конечного решения, которое будет использоваться. Вместе с тем мы сразу понимаем, какими особенностями должен обладать не только инструмент, реализующий конкретно эту практику, но и связанные с ним инструменты. В данном процессе участвуют и решения для статического анализа, и системы защиты вроде WAF.
Только проработав подобные процессы, согласовав их со всеми участниками и определив основные требования, которым должны соответствовать инструменты, можно переходить к следующему шагу в формировании безопасной разработки – подбору решений, которые будут гармонично встраиваться в процесс. И вот тут как раз произошли основные интересные изменения, о которых хочется поговорить немного подробнее.
Что изменилось в DevSecOps в связи с текущей ситуацией на рынке? На самом деле поменялась только одна часть – инструменты. Их стало существенно меньше, так как ведущие западные игроки вышли из игры, а использовать оставшиеся зарубежные решения достаточно опасно: неизвестно, что будет с ними через некоторое время и как они себя поведут.
Таким образом, сейчас нужно ориентироваться только на российские разработки и рассматривать возможность импортозамещения различных инструментов DevSecOps либо использовать Open Source. Инструменты с открытым исходным кодом стоит применять с большой осторожностью, поскольку в последнее время участились случаи добавления в новые версии различных бэкдоров, недекларируемых возможностей и прочих неприятных сюрпризов.
Так что же в таком случае делать компаниям, как выбрать нужный инструмент или заменить потерянный? На наш взгляд, есть три возможных сценария, в зависимости от того, как изначально развивался процесс безопасной разработки.
Если компания только начинает строить процесс и подходить к выбору инструментов, здесь все гораздо проще. Достаточно пойти по правильному пути, понять, описать процессы и при выборе инструмента учитывать все текущие реалии и ограничения.
Если компания все изначально делала грамотно, а именно определила все точки взаимодействия участников процесса, описала, как и что должно работать, то для нее не будет большой проблемой заменить тот или иной инструмент (а у некоторых – просто отказаться от одного из работающих в связке). Да, конечно, будут нюансы и сложности, часть процессов придется на какое-то время сократить или пересмотреть. Но база для того, чтобы безболезненно выбрать новое решение и переключиться на него, уже будет готова, это не займет много времени.
Если компания строила свои процессы вокруг конкретного инструмента и изменяла их под него, то это самый худший сценарий из всех представленных. Просто потому, что в таком случае вместе с исчезнувшим решением рухнет и все созданное на этом фундаменте. И тогда придется отстраивать инфраструктуру заново, при этом стараясь не допускать прежних ошибок. Если компания столкнулась с этим, мы рекомендовали бы ей не спешить, а сделать небольшой шаг назад и посмотреть со стороны, что устраивало в прошлом варианте, а что хотелось бы изменить и улучшить. Можно использовать это время для обновления и оптимизации процессов, раз они больше не связаны с конкретным инструментом.
Однако любой из трех сценариев предполагает в итоге выбор определенного решения. Ниже мы даем основные показатели, на которые стоит обращать внимание, чтобы остановиться на оптимальном инструменте.
Это лишь минимально необходимый перечень того, на что смотреть при выборе инструмента, пополнять его можно еще очень и очень многими вещами. Каждая компания может дополнить чек-лист своими пунктами.
Уже сейчас можно предположить, что в ближайшем будущем все больше внимания будет уделяться вопросам безопасности в целом и безопасной разработке в частности. Да, будем честны, не все продукты на рынке на данный момент могут похвастаться отличными результатами: кто-то отстает в плане обнаружения уязвимостей, кому-то не хватает возможностей интеграции, у кого-то хромает удобство использования. Но это вполне нормальная ситуация для начала. Сейчас у отечественных специалистов безопасной разработки есть потрясающий шанс показать, на что они способны.
Те производители, которые готовы меняться и становиться лучше от релизу к релизу, собирая требования и пожелания заказчиков, реализуя дополнительные проверки, интеграции, постоянно улучшая свой продукт (то есть активно меняясь под потребности рынка), будут все более востребованы. Они смогут еще быстрее развиваться за счет новых продаж и инвестиций, это позволит им расширить аудиторию и дальнейшую возможность масштабирования.
Сегодня у отечественных производителей есть все шансы предложить решения намного удобнее, лучше и производительнее тех, что есть у западных вендоров. Главное – слушать своих заказчиков и принимать верные решения!