Будущее Open Source под угрозой?

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

Сторонний код жизненно важен для разработки приложений

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

Это стороннее программное обеспечение, при ответственном использовании, избавляет разработчиков от необходимости постоянно изобретать велосипед. Это значительно повышает эффективность процесса разработки, помогая в производстве высококачественного конечного продукта. В конечном счете, свободное и либеральное использование открытого исходного кода создает положительный цикл обратной связи, позволяя разработчикам быстрее выпускать свой минимально жизнеспособный продукт, что открывает путь к быстрому сбору и внедрению отзывов и оценок пользователей. Хотя разработчики хорошо осведомлены о критическом положении открытого исходного кода в процессе DevOps, руководители часто удивляются, узнав, что 80% кода, поддерживающего современные приложения, происходит из ранее существовавшего кода.

Скрытая опасность транзитивных зависимостей

Не новость, что открытый исходный код сопряжен с риском. Недавние широко распространенные недостатки, такие как Log4j и HeartBleed, безвозвратно поставили на карту риск открытого исходного кода. Что остается растущей областью понимания, так это частота использования открытого исходного кода и скрытность, с которой уязвимости могут проникнуть в активный проект. Несмотря на постоянный риск, связанный с проектами с открытым исходным кодом, было проведено очень мало исследований конкретного типа риска, который представляет открытый исходный код. Исследователи из Endor Labs решили изменить это, выяснив происхождение основных угроз OSS.

В программном обеспечении транзитивные зависимости описывают однозначно непрямые отношения между двумя компонентами. Например, предположим, что ваша команда разработчиков добавляет пакет B в текущий проект. Пакет B, в свою очередь, автоматически загружает пакет C. В этом сценарии, в то время как разрабатываемое программное обеспечение имеет прямую связь с пакетом B, пакет C остается скрытым на заднем плане — неотъемлемым, но в значительной степени невидимым. Разочаровывает любую попытку более безопасных методов разработки тот факт, что только 5% зависимостей программного обеспечения с открытым исходным кодом выбираются вручную для реализации в рамках процесса DevOps. Таким образом, большинство зависимостей просто автоматически встраиваются в кодовую базу. Это описывает источник транзитивной уязвимости. Недавний отчет Endor Labs показал, что поразительные 95% уязвимостей с открытым исходным кодом возникают из-за транзитивных зависимостей .

Данные были собраны из отчета Census II компании Core Infrastructure, в котором перечислены самые популярные бесплатные программы с открытым исходным кодом. Затем эти данные были дополнены другими источниками, что позволило исследователям Endor сканировать популярные менеджеры пакетов и библиотеки OSS. Исследователи обнаружили, что из 254 пакетов, упомянутых в данных Census II, большинство страдают в среднем от 14 транзитивных зависимостей. В вакууме число 14 может показаться не слишком большим, но большинство приложений полагаются на десятки, если не сотни, прямых зависимостей; их транзитивные аналоги масштабируются экспоненциально.

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

Как защититься от скрытых уязвимостей

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

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

В то время как WAF контролирует любые внешние попытки выполнить код, самозащита приложений во время выполнения (RASP) защищает от внутренних уязвимостей и внедрения кода. Этот уровень защиты оценивает все полезные нагрузки (например, SQL-запросы и команды операционной системы) в режиме реального времени. Этот процесс не требует подписи или фазы обучения и происходит полностью в контексте приложения. Поскольку это работает внутри приложения, оно охватывает почти все контексты. Это означает, что даже если эксплойт позволяет нарушить периметр, злоумышленник не может перемещаться в боковом направлении, поскольку любое подозрительное поведение приложения вызывает отключение RASP. Это прекращает подозрительную активность и предупреждает службы безопасности. Таким образом, RASP дополняет WAF следующего поколения; в то время как WAF помогает предотвратить нежелательный трафик, риск, связанный со скрытыми транзитивными эксплойтами, снижается с помощью RASP. С этими компонентами, защищающими технический стек, нагрузка, которую OSS в настоящее время возлагает на безопасность, значительно снижается.