Раньше следить за дырами в цепочке поставок и открытом исходном коде приходилось лишь узкоспециализированным софтверным фирмам и гигантам бизнеса. Однако сегодня даже небольшие компании пишут свой код — и вопрос становится для них насущным. Даже там, где IT не является профилем бизнеса, каждая вторая фирма силами внутренних айтишников создаёт скрипты, настраивает интеграции и автоматизирует процессы. Это диктуется необходимостью быть эффективными. Но в итоге организация получает новые типы уязвимостей, которые гораздо труднее обнаружить и закрыть
Современная разработка повсеместно и неизбежно опирается на open source-компоненты. Однако связанные с этим угрозы за последние годы стали сложнее, разнообразнее и массовее. Среди них: вредоносный код в популярных хранилищах, неполные и неточные сведения о программных уязвимостях, хроническое применение старых и дырявых компонентов, а также всё усложняющаяся оценка цепочек зависимостей.
Нехватка данных об уязвимостях в open source
Даже если в компании отлично настроено управление уязвимостями для готового ПО, для open source процесс придётся серьёзно переделывать и дорабатывать. Общедоступные самые известные базы данных по уязвимостям зачастую страдают неполнотой, неточностями и запаздыванием с добавлением информации об открытых компонентах. В итоге расстановка приоритетов превращается в угадайку, и никакая автоматизация не поможет, пока не исправлены пробелы в исходных данных.
Например, по оценкам Sonatype, около 65% open source-уязвимостей с присвоенным идентификатором CVE не имеют оценки серьёзности (CVSS) в главной базе NVD. Из них 46% заслужили бы высокий балл критичности. Из тех CVE, у которых оценка критичности всё же существует, лишь в 55% случаев данные из разных источников совпадают. То есть одна база считает уязвимость критической, а другая — средней. Даже в расширенных метаданных полно ошибок и расхождений, например в указании диапазона версий пакета, подверженных дефекту. В результате сканеры, работающие на основе сравнения версий, выдают и ложные срабатывания, и пропуски реальных угроз.
Дефицит информации продолжает расти, а её поступление — замедляться. За пять лет общее количество CVE удвоилось, а число CVE без оценки критичности выросло в 37 раз. По данным Tenable, в 2025 году для тех уязвимостей, для которых появился публичный код эксплуатации (PoC), это происходило в течение недели, а добавление в реестр NVD растягивалось на 15 дней. При этом присвоение CVSS и другие этапы обогащения данными идут ещё медленнее: Sonatype оценивает медианное время назначения CVSS в 41 день, а для некоторых дефектов — до года.
Устаревший код в open source
Библиотеки, приложения и сервисы, которые больше не поддерживаются (брошенные проекты или давно устаревшие ветки), встречаются в 5–15% корпоративных проектов — таковы данные HeroDevs. В пяти популярных реестрах open source насчитывается не менее 81 000 пакетов, содержащих известные уязвимости и при этом относящихся к старым неподдерживаемым версиям. Исправления для этих дыр уже никогда не появятся. В Maven Central и PyPI доля таких «сюрпризов» составляет около 10%, а в npm — целых 25%.
Использование подобного кода ломает стандартный процесс управления обновлениями, потому что устаревшую зависимость нельзя просто обновить — ни вручную, ни автоматически. А когда 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% случаев.
А может ИИ сам исправить все уязвимости?
Увы, простая и заманчивая идея натравить ИИ-агента на код, чтобы он нашёл и залатал все дыры, целиком проблему не решает. Описанные выше фундаментальные трудности одинаково мешают и живому разработчику, и искусственному интеллекту. Если данные об уязвимостях неполны, неточны и устарели, приходится не искать известные дефекты, а заново их открывать. Это исключительно дорогой и трудоёмкий процесс, требующий специальных экспертных знаний и практически недоступный для большинства компаний. Если уязвимость найдена в устаревшем и неподдерживаемом компоненте, ИИ-агент не сможет автоматически устранить проблему — потребуется разрабатывать патчи или проводить миграцию. Если же дефект скрыт глубоко в цепочке зависимостей, ИИ, скорее всего, просто его пропустит.
Что предпринять?
Чтобы минимизировать описанные риски, придётся расширить процесс управления уязвимостями, включив в него политики скачивания open source-пакетов, правила работы ИИ-ассистентов и процесс сборки ПО. В частности, рекомендуется:
- применять специализированные решения для сканирования открытого кода или комплексные средства для безопасности облачных сред;
- проверять пакеты, используемые в разработке, через потоки threat intelligence, касающиеся open source-компонентов;
- продумать меры защиты для ИИ-кода и ИИ-агентов;
- систематически избавляться от устаревших open source-компонентов.