Риски, возникающие при разработке и использовании ПО open source

Как популяризация ИИ и упрощение разработки оборачиваются новыми рисками для корпоративной безопасности.

В прошлом только специализированные компании по разработке ПО и очень крупные бизнесы должны были заботиться об уязвимостях в цепочке поставок и открытом исходном коде (open source). Но сегодня даже небольшие компании имеют собственную разработку, и проблема становится актуальной и для них. Даже когда основное направление бизнеса вообще не связано с «софтом», в каждой второй компании внутренние команды ИТ пишут код, настраивают интеграции и автоматизируют бизнес-процессы. Этого требует эффективность бизнеса. Но в результате организация сталкивается с новыми видами уязвимостей в ПО, найти и устранить которые гораздо сложнее, чем просто скачать обновление Windows.

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

Дефицит данных об уязвимостях open source

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

Например, по данным Sonatype, около 65% open-source-уязвимостей, получивших идентификатор CVE, не имеют оценки критичности (CVSS) в наиболее популярной базе уязвимостей NVD. Из этих уязвимостей 46% получили бы высокую оценку критичности.

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

Дефицит данных постоянно растет, а их поступление замедляется. За 5 лет общее число CVE выросло в 2 раза, а число CVE без оценки критичности — в 37 раз. По данным Tenable, в 2025 году для уязвимостей, у которых появился публично доступный код для эксплуатации (PoC), это происходило за неделю, а их включение в реестр NVD занимало аж 15 дней. При этом оценка CVSS и другие процедуры обогащения проходят еще медленнее — Sonatype оценивает медианное время назначения CVSS в 41 день, а для ряда дефектов — до года.

Устаревший код open source

Библиотеки, приложения и сервисы, которые больше не поддерживаются (abandonware, заброшенный целиком, или End of Life — глубоко устаревшая ветка проекта), используются в 5–15% корпоративных проектов по оценкам HeroDevs. В пяти популярных реестрах open source насчитывается минимум 81 000 пакетов, которые содержат известные уязвимости и при этом относятся к устаревшим и неподдерживаемым версиям. Исправления этих уязвимостей не появятся никогда. В Maven Central и PyPI таких «подарков» около 10%, в npm — целых 25%.

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

Ярким примером служит уязвимость Log4Shell — критический дефект (CVSS 10) в популярной библиотеке Log4j, обнаруженный в 2021 году. Из 300 миллионов загрузок Log4j, которые произошли в 2025 году, 40 миллионов пришлись на уязвимую версию. И это одна из самых известных и ярких уязвимостей, широко освещавшаяся, реально эксплуатируемая, исправленная разработчиком и закрытая во всех популярных продуктах на ее основе. С менее резонансными дефектами ситуация еще хуже.

Усугубляется ситуация и проблемами видимости. Далеко не все организации используют инструменты, способные построить полное дерево зависимостей и получить полную информацию о пакетах и версиях компонентов, входящих в ПО организации. В результате устаревшие компоненты могут оставаться «невидимками» и никогда не появляться в очереди на устранение.

Вредоносное ПО в реестрах open source

Атаки через зараженные или изначально вредоносные пакеты open source стали одной из самых быстрорастущих угроз цепочки поставок программного обеспечения. По оценкам исследователей «Лаборатории Касперского», к концу 2024 года в популярных реестрах было обнаружено около 14 тыс. вредоносных пакетов, на 48% больше, чем годом ранее. Sonatype отмечает взрывной рост угрозы за 2025 год, задетектировав более 450 тыс. вредоносных пакетов.

Мотивация злоумышленников в этих атаках бывает разной: кража криптовалюты, сбор учетных данных разработчиков, промышленный шпионаж, доступ к инфраструктуре компаний через конвейер CI/CD, компрометация публичных серверов для размещения спама и фишинга. Тактику используют как шпионские APT, так и финансово мотивированные киберпреступники. Все чаще компрометация пакета open source становится лишь первым шагом в многоэтапной атаке на компанию.

Типичные сценарии атаки разнятся: компрометация учетной записи одного из авторов open source, публикация «полезной» библиотеки со встроенным вредоносным кодом или публикация «однофамильца», то есть вредоносной библиотеки, имя которой похоже на имя популярной библиотеки. Тревожной новинкой 2025 года стали автоматизированные атаки, своеобразные черви. Наиболее известна кампания Shai-Hulud, в которой вредоносный код похищал токены GitHub и npm, заражал новые пакеты и проник таким образом более чем в 700 npm-пакетов и десятки тысяч репозиториев, попутно публикуя в общий доступ секреты CI/CD и облачные ключи.

Хотя эта проблема формально не относится к уязвимостям, решать ее помогают те же инструменты и меры безопасности, которые придется разворачивать для управления уязвимостями.

ИИ-агенты умножают проблемы open source

Повсеместное и поспешное внедрение ИИ-агентов в разработку ПО значительно повышает эффективность разработчиков, но одновременно увеличивает масштаб любых ошибок. Без строгого контроля и четко заданных начальных условий ИИ-код будет чрезвычайно уязвимым — 45% кода содержат ошибки из OWASP Top 10, а 20% развернутых приложений имеют опасные ошибки конфигурации. Это обусловлено особенностями тренировки ИИ-моделей, которая в большой мере проходила на устаревшем, демонстрационном или учебном коде. Те же проблемы проявляют себя, когда ИИ-модель решает использовать в проекте компоненты open source. Модель не знает, какие версии пакетов существуют, какие признаны уязвимыми, — и вставляет версию зависимости, известную из учебных данных и почти наверняка устаревшую. Иногда модели пытаются вызывать несуществующую версию или вообще несуществующую библиотеку, открывая дорогу к опасной атаке dependency confusion.

В 2025 году даже лидирующие LLM рекомендовали неверные версии зависимостей, просто придумывая ответ в 27% случаев.

А может, ИИ и устранит все уязвимости?

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

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

Что делать?

Для того чтобы минимизировать вышеописанные риски, придется расширить процесс управления уязвимостями, охватив им политики скачивания пакетов c открытым исходным кодом, правила работы ИИ-ассистентов и процесс сборки ПО. В том числе:

• использовать специализированные решения для сканирования open source или комплексное решение для безопасности облачных нагрузок;
• проверять используемые в ходе разработки пакеты при помощи потоков данных threat intelligence, касающихся компонентов open source;
• продумать меры безопасности для защиты ИИ-кода и ИИ-агентов;
• систематически избавляться от устаревших компонентов open source.

03.04.2026

Kaspersky для школ по специальной цене