Каковы риски использования Open Source?

Общий объем мирового рынка open source в 2022 году составил $30 млрд, а к 2026 году эксперты прогнозируют его удвоение до $66,84 млрд. В 97% приложений так или иначе используются компоненты открытого исходного кода — open source применяет 90% компаний. Для российских организаций использование открытого исходного кода стало еще более актуальным после начала импортозамещения, ведь адаптировать open source под собственные нужды часто значительно проще и быстрее, чем разрабатывать код с нуля. Однако важно помнить о том, что внедрение открытого исходного кода в собственные продукты, помимо очевидных плюсов, несет в себе ряд рисков — подробнее о них мы и расскажем в нашем посте.

Разработка программного продукта с открытым исходным кодом в большинстве случаев создает цепочку поставок (supply chain), которая состоит из таких же open source проектов. Эти проекты, в свою очередь, могут ссылаются на другие open source библиотеки и так далее. Таким образом, выстраивается достаточно длинная последовательность зависимостей.

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

Проблема в том, что обнаружение уязвимости в одной open source библиотеке ставит под угрозу массу других проектов, которые ее используют. Например, в ноябре 2021 года в популярной открытой библиотеке логирования Log4J была обнаружена уязвимость, которая получила название Log4Shell. По оценкам Министерства внутренней безопасности США, чтобы найти и обновить уязвимые версии библиотеки везде, где они используются, потребуется не менее десяти лет.

Другой способ компрометации через цепочку поставок в open source — это атака с использованием так называемой «путаницы зависимостей». Дело в том, что открытый код часто дорабатывается внутри компаний. Нередко в него добавляются проприетарные (closed source) зависимости, например, соответствующие npm-библиотеки. В 2021 году исследователи обнаружили, что если библиотека с одним и тем же именем существует и в открытом, и в закрытом репозитории, то приоритет будет иметь тот вариант, у которой выше номер версии.

Соответственно, злоумышленники могут создать на популярной открытой площадке вредоносную библиотеку с тем же названием (если оно не занято), что и у закрытой библиотеки и очень высоким номером версии — скажем, 9000.0.0. В таком случае зависимые от этой библиотеки решения в первую очередь будут обращаться к вредоносному варианту. Подобная атака успешно сработала с такими гигантами, как Apple, Microsoft и PayPal.

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

В то же время угрозу представляют и неизвестные уязвимости, то есть уязвимости нулевого дня (zero-day), за которыми постоянно охотятся киберпреступники. Открытость open source решений помогает злоумышленникам исследовать их в попытке обнаружить пути компрометации инфраструктуры компании. Найденные уязвимости могут быть впоследствии проданы за десятки тысяч долларов в дарквебе.

Еще одна серьезная угроза open source — это распространение вредоносного кода через популярные площадки. Подобные случаи происходят достаточно часто: так, в апреле этого года стало известно о злоумышленниках, распространяющих зловреда Keyzetsu через GitHub.

Схема работает следующим образом: злоумышленники загружают open source проект на популярную площадку и эксплуатируют ее алгоритмы, чтобы искусственно повысить рейтинг и видимость проекта на платформе. Вредоносная нагрузка зловреда в данном случае была скрыта внутри файлов Visual Studio. При попадании на устройство жертвы зловред Keyzetsu занимается перехватом криптоплатежей — он подменивает адреса кошельков в буфере обмена, так что исходящие переводы уходят злоумышленникам.

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

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

Полезно помнить о том, что при разработке собственного ПО на основе открытого исходного кода компания никогда не может быть уверена в надежности своих «подрядчиков». Разработчики проекта в любой момент могут прекратить его поддержку. Это часто происходит с решениями, за которыми стоят небольшие команды. В этом случае open source проект не только постепенно перестанет быть совместим с новыми технологиями, но и может оказаться уязвим для новых атак.

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

Обычно к программному обеспечению с открытым исходным кодом привязано какое-либо лицензионное соглашение, ведь публикация кода не означает отсутствие правообладателя. В этих соглашениях описывается, как именно может использоваться и распространяться open source код. Как правило, лицензии позволяют компаниям свободно внедрять код в свои проприетарные приложения для коммерческих целей. Единственное, что делать при этом обязательно, — признавать оригинального создателя кода.

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

Здесь стоит уточнить, что существует более 100 различных вариантов open source лицензий. Это разнообразие может стать проблемой, поскольку лицензии есть не только у самого open source кода, который компания применяет, но и у его зависимостей. Соответственно, организациям, работающим с открытым кодом, полезно регулярно проводить мониторинг соответствия лицензионным соглашениям.

Следует также учитывать, что на ряде предприятий в России запрещено использовать иностранное ПО. Означает ли это запрет open source компонентов от зарубежных авторов — понятно не до конца. В индустрии считается, что скорее их использование не запрещено, однако правоприменительная практика по этому вопросу еще не сформировалась окончательно. Тут полезно вспомнить о том, что Минцифры и Минпромторг последовательно ужесточают регулирование использования решений с открытым исходным кодом.

Открытое программное обеспечение играет ключевую роль в современной разработке, но его распространение и использование связанной с ним инфраструктуры добавляет специфические риски. Например, еще в 2022 году на главной мировой open source площадке, GitHub, были заблокированы аккаунты крупных российских компаний — Сбера и Альфа-банка.

Невозможность использовать GitHub создает значительные трудности, особенно при необходимости изменения и доработки уже используемого организацией программного обеспечения с открытым исходным кодом. Чтобы решить эту проблему российские компании работают над локализацией open source репозиториев из Китая, но для проверки жизнеспособности этой замены потребуется время.