Мы в T1 Cloud продолжаем рассказывать о процессах безопасной разработки приложений Secure SDLC. Сегодня подробнее поговорим о потенциальных уязвимостях в компонентах open source и как от них защититься.
Подавляющее большинство приложений полагается на open source. По оценке аналитиков из Synopsys, 99% проприетарных кодовых баз содержит как минимум один компонент с открытым исходным кодом. Такая практика работы даже над бизнес-критическими сервисами обусловлена не только экономией, но и повышенной надежностью. Ошибки и недочеты, будучи обнаруженными, оперативно исправляются совместными усилиями сообщества, поэтому открытые компоненты лучше защищены. Но на практике встречаются подводные камни.
Подводные камни open source
Многие продукты с открытым исходным кодом представляют собой масштабные проекты вроде Kubernetes или TensorFlow. Их разрабатывают и финансируют крупные ИТ-компании, которые нанимают специалистов для поиска и исправления уязвимостей. Однако существует целый пласт open source решений, над которыми работают энтузиасты в свободное время. Часто эти люди являются единственными контрибьюторами, несмотря на то что их проекты — «душа и сердце» инфраструктуры банков, сотовых операторов и других организаций.
У таких проектов зачастую нет ни надежной финансовой основы, ни гарантий нормальной работы. Вероятнее всего, там не проводят углубленный мониторинг уязвимостей. В то же время каждый открытый проект зависит от других — более мелких. В этой цепочке зависимостей легко может возникнуть брешь в безопасности, способная просуществовать больше четырех лет.
Так, возникают ситуации, подобные той, что произошла с библиотекой журналирования Log4j. Команда занимается проектом на волонтерских началах и практически не получает денег за его поддержку. В конце прошлого года в коде библиотеки нашли уязвимость, которая существовала далеко не первый год. Она позволяла выполнить вредоносный код на сервере при помощи механизма JNDI.
Повезло, что в случае с Log4j разработчики занялись устранением недостатков. Но существуют тысячи других проектов, которые или заброшены, или не получают должного внимания со стороны open source сообщества. Эксперты Synopsys отмечают, что до 75% кодовых баз содержат открытые компоненты с «непропатченными» уязвимостями.
В подавляющем большинстве случаев уязвимости в open source решениях — это результат ошибки мейнтейнера или сбой в сторонних компонентах. Но бывают ситуации, когда в исходники проекта намеренно встраивают вредоносный код. Так, в мае автор node-ipc добавил в него зловреда, удаляющего все файлы с устройств с определёнными IP-адресами. Похожую акцию в начале года провел мейнтейнер пакетов faker.js и colors.js. Он внедрил в код бесконечный цикл, который выводил в консоль бессмысленную последовательность символов. В итоге была нарушена работа тысяч компаний по всему миру, включая ведущих облачных провайдеров.
Аналогичная история произошла еще в 2018 году с библиотекой Node.js — event-stream. Мейнтейнер решил переключиться на другие проекты, поэтому передал права на репозиторий добровольцу из сообщества. Через какое-то время тот внедрил в утилиту скрипт, ворующий данные криптовалютных кошельков у пользователей.
Что с этим сделать
Независимо от того, является код свободным или проприетарным, он нуждается в аудите и обслуживании, иначе возникает угроза безопасности для любого программного обеспечения, которое его использует. Первым делом имеет смысл сформировать каталог всех задействованных open source решений и библиотек. Там стоит отразить версии используемых продуктов и готовящиеся обновления. Такой подход позволит сформировать полную картину — какой открытый код использован на проекте (и где именно).
В то же время необходимо настроить инструменты для сканирования уязвимостей класса software composition analysis (SCA). Это — решения для поиска и устранения недостатков в коде и контроля внешних библиотек. Они анализируют версии, зависимости и другие отличительные характеристики, а затем сопоставляют их с базами данных уязвимостей — например, NVD. Системы SCA позволяют оценить серьезность уязвимости и её потенциальное влияние на бизнес-процессы, а также предлагают шаги для устранения проблем.
Сканирование в рамках SCA достаточно легко встраивается в пайплайн CI/CD. Так, разработчики могут получать автоматические уведомления о проблемах с компонентами, которые они хотят подключить. Работа с уязвимостями на ранних этапах позволяет сэкономить — по некоторым оценкам, затраты на устранение ошибок после релиза возрастают в тридцать раз. Конечно, можно проводить сканирование, когда проект уже вышел в продакшн. Новые баги находят каждый день, а уведомление об инъекциях и уязвимостях 0-day минимизирует потенциальный ущерб.
Каждая компания может настроить такие инструменты самостоятельно, если обладает экспертизой App Sec. Но можно переложить эти вопросы на плечи облачного провайдера — например, необходимый инструментарий предлагаем мы в T1 Cloud. Платформа Cloud Secure Development Platform умеет проводить анализ защищенности внешних компонентов (OST). Она сообщит об известных уязвимостях и других ограничениях в библиотеках и фреймворках.
Решение защищает от угроз, когда информация об уязвимости опубликована, но разработчики не успели устранить недостаток, либо патч уже выпущен, но в бизнес-процессах пока используется уязвимая версия компонента. Это особенно важно в контексте того, что у ИБ-специалистов все меньше времени на идентификацию уязвимостей — первый эксплойт вполне может появиться в течение недели. OST-система в облаке T1 Cloud построена на базе инструмента DependencyCheck в партнерстве со специалистами из компании SolidLab. Чтобы подключить услугу, нужно:
Обратиться в техподдержку и заполнить анкету с указанием подключаемых к сервису продуктов.
Обсудить с инженерами SolidLab требования к процессу анализа внешних компонентов и определить стоимость внедрения. Она будет индивидуальной, так как зависит от масштабов и объемов приложений, числа сотрудников и других инфраструктурных особенностей.
Выполнить «карту готовности»: выделить необходимые ресурсы, предоставить доступы и так далее.
Подключить сервис и интегрировать OST-анализаторы с инструментами CI/CD.
Наконец, остается обучить разработчиков работе со средствами анализа и разбора обнаруженных недостатков. С этими вопросами также помогут наши специалисты техподдержки и представители SolidLab.
Серия публикаций о надежной разработке приложений:
Дополнительное чтение в нашем блоге: