Репозитории кода обычно контролируют то, что там размещается, поэтому люди привыкли доверять коду, который оттуда загружают. Но инциденты, связанные с распространением зловредов через репозитории, все же случаются. Какие меры надо принять, чтобы избежать угроз и сделать Open Source более безопасным?
- Введение
- GitHub, GitLab, PyPI и другие: как устроены репозитории и зачем они нужны
- Что будет, если отключат GitHub: риски, примеры и российские альтернативы
- Две критические угрозы в open source: что хуже — баги или бэкдоры?
- От Log4j до вредоносных npm-пакетов: самые громкие кейсы
- Как обеспечить безопасность при работе с Open Source
- Выводы
Введение
По данным опроса, проведенного компанией Tidelift, в 92% приложений используются компоненты с открытым исходным кодом. Использование таких компонентов позволило существенно ускорить процесс разработки за счет переиспользования существующих модулей и библиотек, которые иначе разработчикам пришлось бы создавать с нуля, причем часто бесплатно.
Репозитории кода — это инструмент, с помощью которого распространяется открытый код. Причем неважно, создан этот код силами сообщества независимых разработчиков или под эгидой какой-то компании.
Но, с другой стороны, как раз репозитории кода часто становятся вектором кибератак. Это же касается и распространения ошибок, многие из которых годами остаются неизвестными. По статистике Solar appScreener, 79% сторонних библиотек не обновляются. Также для них отсутствует контроль зависимостей. Как результат, регулярно выявляются критические уязвимости, среди которых наиболее опасными оказались обнаруженные в Log4j и OpenSSL. Также существует вероятность компрометации самого репозитория.
«Репозитории исходного кода — это лакомая цель, их постоянно сканируют и мониторят. Кто-то ищет уязвимости, кто-то случайно слитые секреты, кто-то удобный момент для внедрения вредоноса. Особенно уязвимы проекты, где нет культуры безопасной разработки: где нет код-ревью, где разрешено коммитить всё подряд. Чем популярнее проект с открытым кодом, тем выше шанс, что кто-то его уже изучает с нехорошими намерениями», — предупреждает директор по продукту Staffcop направления информационной безопасности «Контур.Эгида» Даниил Бориславский.
Директор по информационной безопасности «Группы Астра» Дмитрий Сатанин подчеркнул, что одна успешная атака на репозиторий может привести к компрометации сотен и даже тысяч объектов, как отдельных компьютеров, так и информационных систем. А только значимых инцидентов такого рода за 2024 год, по оценкам «Лаборатории Касперского», на которые сослался представитель «Группы Астра», было двенадцать.
GitHub, GitLab, PyPI и другие: как устроены репозитории и зачем они нужны
Репозиторий (часто используют англоязычный синоним Git, по названию протокола, используемого для работы с кодом) представляет собой хранилище кода со всеми его версиями. Они делятся на три класса:
- Локальные, расположенные на отдельном компьютере, рассчитанные на работу одного человека.
- Централизованные, развернутые на файловом сервере в локальной сети. Рассчитаны на группу разработчиков.
- Распределенный, рассчитанный на обслуживание сообществ независимых разработчиков. Основная часть репозитория находится в облаке, а локальные копии у участников сообщества. Локальные копии синхронизируются по мере внесения правок.
Наиболее известными и популярными распределенными репозиториями кода по модели Git являются GitHub (рис. 1), GitLab и Bitbucket. Впрочем, два последних существенно менее популярны.
Рисунок 1. Интерфейс GitHub
Отправка данных в репозиторий называется коммитом. Есть и однокоренной глагол — «коммитить» (изменения) или «закоммитить».
Дополнительной функцией крупных репозиториев кода являются функции контроля. Например, на GitHub система сканирования на уязвимости с использованием искусственного интеллекта работает с февраля 2022 года. Отечественные проекты от VK и «Яндекса» также оснащены схожими инструментами.
Важной особенностью Git-репозиториев являются ветки. Это ответвления, содержащие измененный код. Основная ветка при этом называется «master», все остальные могут именоваться произвольно.
Основной функцией репозиториев является распространение кода. Также они часто заменяют портфолио разработчика. Для этого достаточно открыть потенциальному работодателю доступ.
Что будет, если отключат GitHub: риски, примеры и российские альтернативы
Долгое время основной угрозой для российских пользователей называли возможное отлучение от зарубежных площадок. Российский премьер Михаил Мишустин еще в сентябре 2021 года предложил создать российских репозиторий для разработчиков ПО, который мог бы стать альтернативной зарубежным ресурсам.
После массовой блокировки аккаунтов российских разработчиков на GitHub создание альтернативы ускорилось. Напомним, что в апреле 2022 года были заблокированы учетные записи десятков разработчиков, в основном работавших в банках, попавших под американские санкции. Однако, что называется, под горячую руку попали и многие репозитории, принадлежащие разработчикам, не имеющим ни малейшего отношения к подсанкционным компаниям (рис. 2). До этого блокировали, например, тех, кто «засветился» связями с Крымом или республиками Донбасса.
Рисунок 2. Сообщение о блокировке аккаунта на GitHub
С октября 2022 года по апрель 2024 года под эгидой Российского фонда развития информационных технологий (РФРИТ) продолжался эксперимент по созданию российского репозитория. Однако еще до его окончания работы были прекращены из-за недостатка финансирования. В данном качестве будет использован один из уже созданных репозиториев. К тому времени их представили «Сбер», холдинг Т1, «Ростелеком», а в 2025 году свои репозитории, пусть и в дорелизной версии, представили VK и «Яндекс».
С другой стороны, как напомнил Дмитрий Сатанин, отключение от зарубежной площадки легко обходится.
Как отметил директор по технологическому консалтингу Axiom JDK Алексей Захаров, необходимо строить доверенные репозитории на территории РФ, и гарантировать соответствие исходного кода исполняемым файлам:
«Именно доверенные репозитории и экспертиза разработчиков в используемых компонентах ПО поможет снять проблему атак на цепочки поставок. В этом может помочь цифровой паспорт ПО, так называемая в мировой практике концепция композиционного анализа SBOM — Software Bill of Materials. Он позволяет оценить его уязвимости и управлять рисками. Поэтому очень важно создать единые правила наполнения и использования доверенных репозиториев ПО и ввести требование цифрового паспорта для разработчиков критических информационных систем».
Две критические угрозы в open source: что хуже — баги или бэкдоры?
Более серьезными угрозами являются тиражирование уязвимостей, особенно если они неизвестны, а также включение в код разного рода недекларируемых возможностей. По мнению опрошенных нами экспертов, обе эти проблемы в целом равнозначны и из разряда «обе хуже».
Руководитель отдела операционной поддержки центра разработки решений по контролю безопасности ПО группы компаний «Солар» Антон Прокофьев считает, что атаки через открытые репозитории и известные уязвимости (legacy) могут быть одинаково опасны для заказчика. Оба этих риска связаны с угрозами атак на цепочку поставок (supply chain) и могут затронуть конфиденциальность, целостность и доступность данных.
Технический директор ИТ-экосистемы «Лукоморье» Алексей Щербаков считает обе угрозы крайне серьезными. Обе они могут привести к критическим последствиям в зависимости от контекста разработки. Но если уязвимости застарелые, но при этом известные и все еще присутствуют в продукте — это, по сути, нарушение со стороны разработчика. В таких случаях риск эксплуатации уязвимости становится практически гарантированным.
«Что более опасно: принять яд или не лечить гангрену? И то, и другое ведет к плачевному исходу. Так и здесь: атаки через репозитории и неустраненные уязвимости — это две стороны одной медали, а именно разгильдяйство и отсутствие внятных процессов управления зависимостями, — считает генеральный директор и основатель сервиса автоматизации коммуникации с клиентами «Лия» Демьян Грин. — Но если выбирать «более опасное», то атаки через репозитории коварнее. Застарелая уязвимость как правило известна и задокументирована. Есть патчи и есть сканеры, которые ее найдут. А вот свежий зловред, замаскированный под легитимный пакет — это удар в спину, абсолютно неизвестная угроза, которую стандартные сканеры могут и пропустить».
Даниил Бориславский считает НДВ более значимой угрозой, чем уязвимости:
«Обе истории опасны, но атаки через репозитории страшнее. Вредонос в библиотеке может сидеть годами и не проявляться, пока не включится нужный триггер, особенно если он специально замаскирован. Поэтому такие атаки не про «починить баг», это про то, чтобы вообще не пустить его в систему».
По мнению проект-менеджера MD Audit (ГК «Софтлайн») Кирилла Лёвкина, обе категории считаются очень опасными. Однако атаки через репозитории более коварны за счет скрытности и динамичности. Уязвимости известны и могут быть закрыты на уровне инфраструктуры (например, с помощью брандмауэра веб-приложений, патчей или сегментации), но внедрение вредоносного кода в цепочку поставок может остаться незамеченным и оставаться активным до момента компрометации. К тому же атаки на цепочки поставок легко масштабировать.
Начальник отдела разработки сервисов кибербезопасности IBS Владимир Мукасеев также считает, что целевые атаки через репозитории, как правило, опаснее уязвимостей, поскольку они могут привести к моментальной компрометации системы. Уязвимости же, если они известны, легко находятся, и их эксплуатация затруднена. По оценке представителя IBS, вероятность подвергнуться атаке через репозиторий намного опаснее, чем столкнуться с полным отключением от зарубежной площадки. Такие атаки происходят регулярно и могут в той или иной степени затронуть практически любую организацию.
По мнению владельца продукта SASTAV Антона Михайлова, более опасны все же уязвимости:
«Оба вектора представляют опасность, однако старые неустранённые уязвимости создают более системную и массовую угрозу. Регулярные обновления обычно закрывают десятки известных уязвимостей одновременно, тогда как атаки через репозитории носят точечный характер: они опасны для конкретных организаций или проектов. При своевременном обновлении ПО и мониторинге CVE стандартные эксплойты не представляют серьёзной угрозы. Однако использование непроверенных версий библиотек увеличивает риск внедрения целенаправленного бэкдора».
По оценке руководителя центра экспертизы по безопасной разработке и сертификации средств защиты информации «Инферит» (ГК «Софтлайн») Максима Фокина, следует дифференцировать цели атак через репозитории. Обычно речь идет о целенаправленных атаках на конечных пользователей. Уязвимости же — лишь «недостатки» в ПО, способные при определенных условиях привести к угрозе безопасности информации. В связи с этим вероятность того, что кто-то будет пытаться их эксплуатировать, намного ниже для конечного пользователя.
Чаще всего, по оценке Кирилла Лёвкина, злоумышленники используют для атак на цепочки поставок поддельные зависимости в экосистемах Npm, PyPI и NuGet, которые маскируются под популярные библиотеки. Такая техника называется «typosquatting» или «dependency confusion». Такие атаки, как предупреждает эксперт, происходят незаметно и могут дать злоумышленнику доступ к системам доставки новых версий, ключам и внутренним программным интерфейсам (API).
По оценке Демьяна Грина, надеяться на средства репозитория нельзя. В случае крупных зарубежных вредоносный код может быть пропущен просто в силу масштаба, а у российских меньше ресурсов и хуже средства автоматизации.
По мнению Антона Прокофьева, у зарубежных репозиториев уже есть формализованные уровни доверия, чек-листы и практики. В России такая практика только формируется. Этому способствует обновлённый ГОСТ по композиционному анализу и безопасной разработке (ГОСТ Р 56939-2024), но это лишь первые шаги.
Между тем Алексей Щербаков считает, что риск подобных инцидентов минимизирован:
«Все используемые внешние библиотеки уже давно проходят через внутреннее специализированное хранилище, которое выполняет функции резервного репозитория, а также "карантина" для проверки безопасности кода».
Однако представитель «Лукоморья» не видит большой разницы между российскими и зарубежными практиками контроля кода. Они базируются на общих принципах и механизмах.
По мнению Владимира Мукасеева, многие отечественные платформы делают упор на ручной контроль и верификацию пакетов, что может снижать риски, но замедляет процессы разработки. Зарубежные площадки больше полагаются на автоматизированные проверки, что делает их более быстрыми и удобными, но при этом более уязвимыми для возможных атак.
Как отметил Алексей Захаров, зарубежные репозитории — это открытые публичные проекты, которые как правило контролируются западными компаниями через сообщества разработчиков исходного кода, и контроль не всегда гарантирует безопасность. В России же у репозиториев всегда есть производитель или ответственная организация, которая отвечает не только за обслуживание и наполнение репозитория, но и контроль безопасности.
От Log4j до вредоносных npm-пакетов: самые громкие кейсы
Количество инцидентов, связанных с проникновением злоумышленников в репозитории кода довольно велико. Мы подобрали наиболее резонансные или показательные эпизоды.
В ноябре 2017 года злоумышленники подменили установочный файл в репозитории Bitcoin Gold вредоносным. Зловред был направлен на хищение криптовалюты и кражу данных об аккаунтах ее владельцев. Инцидент был обнаружен спустя 5 дней.
В ноябре 2020 года в репозитории Npm был обнаружен стилер, который «сливал» локальные данные пользователей браузеров на кодовой базе Chromium и мессенджера Discord. Он оставался незамеченным в течение 5 месяцев. Зловред обнаружили специалисты компании Sonatype во время планового мониторинга.
В январе 2021 года исследователь безопасности Алекс Бирсан проник во внутренние репозитории 35 компаний. Он использовал сложную технику и не ставил перед собой деструктивных целей. Однако у багхантера обнаружились последователи, которые ставили перед собой уже не столь благородные цели. Уже спустя несколько недель в нескольких репозиториях были обнаружены вредоносные Node.JS-пакеты, предназначенные для кражи паролей. Для взлома репозиториев злоумышленники использовали ту же технику, которую применял Алекс Бирсан.
Более серьезным был инцидент марта 2021 года. Тогда два злоумышленника разместили злонамеренный коммит в репозиторий кода ядра PHP (рис. 3). Так они внедрили туда бэкдор, который позволяет управлять 80% интернет-ресурсов, использующих движок PHP.
Рисунок 3. Функция вызова бэкдора, добавленная в ходе атаки на репозиторий PHP
Есть риски, связанные с использованием ИИ-ассистентов. При определенных условиях они могут тиражировать опасные уязвимости, которые уже умеют эксплуатировать злоумышленники, или просто вредоносный код. Несмотря на уже зафиксированные инциденты, масштабная угроза распространения зловредов через ИИ пока остаётся скорее теоретической.
В январе 2022 года разработчик ряда популярных библиотек для работы с JavaScript Марак Сквайрс внес в них такие изменения, что они прекратили работу (рис. 4). Причем текст обновлений он разместил сразу в нескольких репозиториях, включая Npm и GitHub. В итоге испорченный код попал и в производные продукты. Мотивом Сквайрса была месть за бесплатное использование его разработок, в том числе в корпоративных продуктах.
Рисунок 4. Результат работы ПО после обновления библиотек от Марака Сквайрса
В марте 2022 года Брэндон Нозаки Миллер (RIAEvangelist) выложил на Npm и GitHub пакеты «Peacenotwar» и «oneday-test», сделав их зависимостями одного из популярных модулей Node.JS. Если этот код запускался на территории России или Белоруссии, то он удалял все данные, заменяя их эмодзи и выводил текстовое сообщение с антивоенным содержанием (рис. 5). Однако эти действия вызвали резкое отторжение в сообществе, и пакеты со злонамеренными функциями были удалены в течение суток.
Рисунок 5. Сообщение из пакета «Peacenotwar»
Однако у RIAEvangelist нашлись последователи. Участники интернет-сообщества «Техдирский клуб» с марта 2022 года по сентябрь 2023 года обнаружили около 40 программных модулей с открытым кодом, которые содержали НДВ, направленные против российских и белорусских пользователей. Большая их часть ограничивалась загрузкой политических лозунгов или демонстрацией медиа, но были и деструктивные, в частности, уничтожающие данные.
Ведущий аналитик «АВ Софт» Дмитрий Матвеев поделился личным опытом:
«Это была атака через вредоносный пакет Npm, от которого зависел популярный опенсорс-проект. Это произошло в 2022 году, когда злоумышленники внедрили вредоносный скрипт в обновление пакета, который при установке собирал данные с машины разработчика и отправлял их на внешний сервер».
Максим Фокин привел такой пример из личных наблюдений:
«На практике был случай, когда сотрудник компании скачал на ПК поддельный опенсорс-пакет и после его инсталляции заполучил в свою систему обыкновенный кейлоггер, бэкдор и программу для поиска и экспорта SSH-ключей. С помощью кейлоггера злоумышленник узнал логины и пароли от ключевых корпоративных сервисов, а за счет украденных SSH-ключей получил доступ к информации, располагающейся на серверном оборудовании».
Даниил Бориславский назвал такое проявление своего рода хактивизма очень неприятным и коварным:
«Санкции — риск, но он понятный и управляемый. Известна их дата, примерные последствия, контрмеры тоже можно заранее продумать. А вот атака через репозиторий — это штука коварная. Ты даже не всегда поймёшь, что она произошла».
В октябре 2022 года исследователи из Лейденского университета обнаружили на GitHub тысячи репозиториев, которые под видом демонстрационных эксплойтов распространяли трояны. Всего таких репозиториев оказалось около 4900.
В начале 2024 года были обнаружены две кампании, связанные с распространением троянцев через Npm. В одном случае при загрузке устанавливалась программа удаленного управления AnyDesk, в другом — стилер, который воровал SSH-ключи для удаленного доступа разработчиков.
В июле 2025 года «Лаборатория Касперского» обнародовала результаты расследования кражи криптовалюты у одного из российских разработчиков. Злоумышленники использовали поддельный пакет, который маскировался под расширение для среды Cursor AI. Для его распространения использовался популярный репозиторий.
Также в июле 2025 года была обнаружена кампания по распространению через GitHub зловредов. Они маскировались под приложения VPN и моды для игры Minecraft.
Антон Михайлов сослался на исследование Sonatype, согласно которому до 40% проектов в экосистемах Npm хотя бы раз сталкивались с попытками загрузки вредоносных пакетов. Причем проблема имеет тенденцию к усилению, поскольку компании всё чаще используют автоматическое подключение внешних зависимостей без должной проверки, а инструменты статического и динамического тестирования (SAST / DAST) зачастую не анализируют этот уровень уязвимостей. Даже не все решения класса «композиционный анализ ПО» (SCA) охватывают подобные риски.
Дмитрий Матвеев назвал такие атаки одной из наиболее распространенных угроз. Злоумышленники все чаще используют репозитории кода или менеджеры пакетов (Npm, PyPI, RubyGems) в атаках на цепочки поставок.
Как обеспечить безопасность при работе с Open Source
Возможные риски, связанные с использованием репозиториев для распространения НДВ, как предупреждает Антон Прокофьев, сложно контролировать вручную. Тут нужна комплексная система с выстроенными процессами, которая включает несколько аспектов: инструменты для анализа состава ПО (с использованием моделей SCA, SCS или OSA) и контроль артефактов кода от разработки до продуктива, в том числе, проверка SBOM (Software Bill of Materials), контроль доверия к внешним компонентам.
Застаревшие уязвимости, как подчеркнул Антон Прокофьев, зачастую недооценивают. Если они не устраняются своевременно, это открывает дверь для эксплуатации злоумышленниками. Примером может служить уязвимость в библиотеке Log4j, которая была обнаружена еще в 2021 году, но многие системы, использующие устаревшие версии этой библиотеки, продолжали быть под угрозой.
Для защиты от таких рисков используется инструмент класса «анализ открытого кода» (OSA), который анализирует состав ПО, цепочку поставок и лицензионные риски. Он позволяет точно оценивать риски в отношении репозиториев, не позволяя злоумышленникам вводить в заблуждение разработчиков.
Владимир Мукасеев дал следующие рекомендации:
- Использовать локальные зеркала репозиториев с жёстким контролем загружаемых пакетов.
- Внедрять инструменты анализа зависимостей и проверять цифровые подписи пакетов.
- Минимизировать использование непроверенных сторонних библиотек и регулярно проводить аудиты.
Алексей Щербаков считает интеграцию этапа проверки стороннего кода и библиотек в сам процесс разработки с помощью специализированного ПО ключевым условием обеспечения безопасности кода. В результате в итоговый продукт попадают только проверенные и безопасные компоненты.
Демьян Грин рекомендует принять следующие меры:
- Любую внешнюю зависимость по умолчанию считать враждебной.
- В конвейер разработки (CI / CD) должны быть встроены инструменты типа OWASP Dependency Check, Snyk или их аналоги, которые сверяют все ваши пакеты с базами уязвимостей.
- Нужен свой частный репозиторий. Нужно исключить прямую закачку с Npm или PyPI на машины, где происходит конечная сборка. Все пакеты сначала должны попадать на проверенное зеркало.
- Жесткая фиксация версий всех зависимостей. Обновление — только после тщательной проверки новой версии.
- Использование SBOM. Вы должны в любой момент времени иметь полный перечень всего стороннего ПО и его версий, который используется в продукте.
По мнению Даниила Бориславского, все начинается с дисциплины и базовой гигиены применительно к разработке. Например, не хранить учетные данные (креды) в коде, использовать секрет-хранилища, документировать и сканировать каждый коммит, особенно если он от внешнего контрибьютора.
Для тех, у кого локальный Git-сервер — обязательно необходима сегментация ресурсов. Тогда проникновение в одну часть инфраструктуры не должно дать доступ к хранилищу кода. Ключи доступа к репозиториям должны распределяться только по правилам, доступ к репозиторию — только по ключам, лучше с двухфакторной аутентификацией.
И, конечно, ключевой гарантией, как подчеркнул Даниил Бориславский, является разграничение прав. Смотреть код — одно, включать туда свои фрагменты — совсем другое. Новичков и джунов без контроля в сборку продуктивных версий лучше вообще не пускать. И, разумеется, гигиена: статический, динамический анализ, регулярное сканирование зависимостей, динамический анализ (DAST) — всё это должно быть стандартом. Если нет ресурсов, то необходимо подключать внешнего подрядчика.
Дмитрий Матвеев порекомендовал следующие меры:
- Использование lock-файлов. В них фиксируются точные версии всех библиотек, хэши и URL, с которого была произведена загрузка.
- Проверка цифровых подписей пакетов.
- Слежение за изменениями в зависимостях.
Кирилл Левкин обратил внимание на то, что защита требует комплексного подхода. Во-первых, использование инструментов анализа состава ПО (SCA), такие как GitHub Dependabot, OWASP Dependency Track. Во-вторых, минимизация автоматического обновления зависимостей — каждое обновление должно проходить ревизию. В-третьих, настройка изоляции среды сборки, необходимо внимательно следить за сетевой активностью зависимостей. Также стоит использовать внутренние зеркала доверенных пакетов и подписывать артефакты. Это не исключает риск полностью, но сильно снижает вероятность массового заражения.
Дмитрий Сатанин считает основной мерой защиты внедрение российских стандартов безопасной разработки (РБПО). Если им следовать, то можно выявить атаку на цепочку поставок до этапа эскалации, будь то активации внедрённого зловреда или использование уязвимостей. Если скомпрометированное в ходе такой атаки ПО всё же попадает в целевую систему, в этом случае могут помочь все известные механизмы и средства защиты. Наилучшая ситуация — наличие полнофункционального центра мониторинга (SOC).
Для конечных пользователей Максим Фокин рекомендует проверять любое ПО с открытым кодом надежным и правильно настроенным антивирусом. Также хороший результат дает использование сетевых песочниц. Или хотя бы выполнить код в виртуальной машине и проанализировать сетевую активность.
Руководитель направления мониторинга и сопровождения систем ИБ «МойОфис» Михаил Черняк порекомендовал использовать проверенные репозитории и обходить стороной непопулярные или слишком молодые, за безопасность которых сообщество ручаться не может. Также он обратил внимание на то, чтобы выстраивать процессы безопасной разработки и их соблюдать. Что касается технических средств, то проблемы и угрозы в ПО позволят обнаружить статический и динамический анализ кода (SAST и DAST), ручное тестирование, анализ компонентного состава приложения (SCA), аудит открытого исходного кода (OSA). Такие средства предлагают и российские вендоры.
Выводы
Внедрение вредоносного кода через репозитории стало важным элементом в ходе атак на цепочки поставок. Появление механизмов контроля несколько осложнило задачу таких злоумышленников, но полностью не исключило такую возможность. Особую осторожность следует проявлять тем, кто пользуется российскими площадками, где такие процедуры пока только тестируются.
Защита кода из репозиториев требует комплексных усилий. Необходимо сочетание технических мер (анализаторы кода — статические и динамические, — а также состава ПО, изоляция среды сборки) и организационных решений (минимизация автоматического обновления зависимостей, разграничение прав пользователей).
