Почему Open Source самое слабое звено в цепочке поставок и как снизить риски?

Дата: 17.11.2022. Автор: Swordfish Security. Категории: Статьи по информационной безопасности
Почему Open Source самое слабое звено в цепочке поставок и как снизить риски?

Сегодня компании стремятся разрабатывать ПО быстро, и курс на импортозамещение в России усилил эту тенденцию. Чтобы сократить срок создания продуктов, разработчики активно используют готовые «ингредиенты» — компоненты Open Source, поэтому современные ПО зачастую скорее собираются, чем пишутся. Нередко компании объединяют в одном продукте сразу несколько пакетов с открытым исходным кодом (например, ядро операционной системы Linux, программную платформу Kubernetes или веб-серверы Apache и Nginx), добавляют ко всему этому «щепотку» (или несколько) проприетарного кода — и готово! 

Обратимся к числам, чтобы оценить масштаб популярности Open Source. По данным Forrester, за последние пять лет сегмент открытого исходного кода в разработке вырос с 35% до 75%. Если говорить конкретно о российских компаниях, ожидается, что к 2026 году 92% из них будут использовать Open Source. Действительно, ценность ПО с открытым кодом неоспорима, но вместе с этим Open Source можно назвать самым слабым звеном в цепи поставок ПО. Вместе с Андреем Красовским, директором по маркетингу Swordfish Security, разберемся, почему это так и как снизить риски. 

Почему хакеры атакуют с «черного хода»?

Как правило, Open Source создают сообщества энтузиастов — разработчики, которые таким образом вносят полезный вклад в общее дело. Обычно ПО с открытым кодом распространяется бесплатно и не имеет жесткой привязки к конкретной платформе, компаниям разрешается свободно использовать Open Source и менять его под свои продукты. 

Из-за добровольного характера сообществ злоумышленники могут с легкостью использовать Open Source для совершения атак. Репозитории открытых проектов часто приглашают разработчиков добавлять обновления и новые функции, поэтому у любых пользователей, включая хакеров, есть возможность опубликовать на платформе собственный код. Многие сообщества ослабляют контроль за новыми участниками, после того как они заслужат доверие. Это значит, что злоумышленник тоже может сначала сделать что-то полезное, а потом «под шумок» добавить в базу вредоносный код. 

Хакеры зачастую строят вектор нападения через Open Source, поэтому что это проще, чем «штурмовать» конкретную цель, например серверы банка, и обходить системы безопасности. Чтобы пробраться в инфраструктуру финансовой компании, злоумышленник может выбрать библиотеку с открытым кодом, которую использует банк, и внедрить в нее уязвимость, пробивающую «окно» в периметре. Таким образом хакер зайдет через «черный ход» без лишних усилий. Хорошо, если банк сразу зафиксирует атаку и начнет с ней бороться, но проблемы всё равно затронут другие компании, использующие библиотеку, то есть развернется масштабная атака на цепочку поставок.

Атаки на цепочки поставок 

Недавно группа исследователей проанализировала 47 313 репозиториев на GitHub (сервис для совместной разработки и хостинга проектов), предлагающие PoC-эксплойты для известных уязвимостей, 4 893 из них (10,3%) оказались поддельными, злоумышленники использовали их для распространения вредоносного ПО. В частности, российские компании в 2022 году ощутили на себе угрозу атак с использованием Open Source довольно остро. С февраля количество «сюрпризов» в ПО с открытым кодом увеличилось в 20 раз. Закладки имели разное содержание: от провокационного контента до вирусов-шифровальщиков. 

Кроме этого, появились случаи, когда вредоносный код внедряли не злоумышленники, а сами авторы ПО. Например, разработчик популярной библиотеки node-ipc (ее загружают более 1 млн раз в неделю) выпустил на npm и GitHub обновленные версии своего продукта, зараженные вирусом-шифровальщиком. Вредоносные версии вычисляли разработчиков из России и Беларуси по IP-адресам и удаляли все данные путем их перезаписи, а также создавали текстовые сообщения с различными призывами призывами агитационного характера, не имеющими отношения к разработке ПО.

Как снизить риски Open Source?

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

SCA-инструменты

Инструменты SCA (Software Composition Analysis), используя файл сборки приложений, в автоматическом режиме анализируют кодовую базу, включая связанные артефакты, формируют список сторонних библиотек и компонентов, использованных в ПО, и проводят поиск уязвимостей. Также такие сканеры могут проверять элементы Open Source на их соответствие лицензионным требованиям. 

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

Программа SBOM

SBOM (Software Bill of Materials) — это список компонентов Open Source и других сторонних элементов, использующихся в кодовой базе ПО. Программа содержит техническую информацию обо всех фрагментах и их связи между собой. Также SBOM может включать краткую информацию о названии, версии и лицензии элементов, данные по уязвимостям, дочерним зависимостям (это «симбиоз» элементов с открытым кодом, компонентов сторонних производителей и собственного кода) и так далее. 

Программы SBOM позволяют выявлять уязвимости и смягчать их последствия за счет инвентаризации компонентов кода, управлять лицензиями на ПО и улучшать жизненный цикл разработки программных продуктов (SDLC). Первый этап создания программы подразумевает внедрение инструментов SCA и других анализаторов, которые можно бесшовно встроить в конвейер CI/CD. Подробно о SBOM мы рассказали в этой статье

Фреймворк SLSA

Продукт запустила компания Google в сотрудничестве с Open Source Security Foundation (OpenSSF). Фреймворк содержит перечень стандартов и руководств для защиты от несанкционированного доступа и обеспечения целостности программных артефактов в цепочках поставок. SLSA учитывает 8 видов атак, реализующих угрозы внесения вредоносных элементов в код на этапах разработки, тестирования и распространения ПО:

  • Включение в исходный код вредоносных изменений.
  • Компрометация платформы управления исходным кодом.
  • Внесение изменений в код на этапе его передачи в систему сборки или непрерывной интеграции.
  • Компрометация платформы сборки.
  • Распространение вредоносного кода через некачественные зависимости.
  • Загрузка артефактов, созданных в обход системы CI/CD.
  • Компрометация репозитория пакетов.
  • Установка зараженного пакета. 

Фреймворк предполагает 4 уровня обеспечения безопасности и предлагает перечень рекомендаций и инструментов для достижения каждого из них. 

Вывод

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

Но существующие угрозы совсем не означают, что нужно отказаться от Open Source. Они выполняют роль драйвера, стимулирующего компании подходить к выбору компонентов с открытым кодом более ответственно, а также налаживать качественные процессы безопасности внутри своей инфраструктуры. Поскольку хакеры постоянно совершенствуют тактику нападения, организациям нужно обеспечивать комплексную защиту ПО, то есть не ограничиваться только SCA-инструментами, укреплять «оборону» программой SBOM, фреймворком SLSA и другими инструментами, регулярно проводить анализ защищенности. Также стоит разработать карту угроз и план действий на случай, если «троянский конь» окажется внутри периметра.

Об авторе Swordfish Security

Лидер рынка стратегического консалтинга в области цифровой трансформации процессов разработки защищенного ПО и внедрения технологических практик DevSecOps
Читать все записи автора Swordfish Security

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *