В 2025 году порог входа в сложные кибератаки обрушился: подростки без технических навыков с помощью систем на основе больших языковых моделей провели взломы на миллионы записей и многомиллионные вымогательства, а среднее время от публикации уязвимости до появления боевого эксплойта сократилось с более чем 700 дней в 2020 году до 44 дней в 2025‑м; на этом фоне традиционная стратегия «успеть запатчить раньше атакующих» перестала работать, и организациям, использующим открытый код и публичные репозитории пакетов, необходимо переходить к структурному устранению целых классов уязвимостей и жёсткому контролю цепочки поставок ПО.
Технические детали и ключевые метрики 2025–2026 годов
Примеры атак с использованием ИИ
Нетехнические злоумышленники в 2025 году начали проводить операции, которые ранее требовали слаженной работы опытной команды:
- В декабре 2025 года семнадцатилетний подросток в Осаке был арестован по японскому закону о несанкционированном доступе за запуск вредоносного кода, позволившего эксфильтровать персональные данные более 7 млн пользователей сети интернет‑кафе Kaikatsu Club; мотив — покупка карточек Pokémon.
- В феврале 2025 года трое подростков (14, 15 и 16 лет) без опыта программирования с помощью ChatGPT создали инструмент, который около 220 000 раз атаковал системы Rakuten Mobile; полученные средства были потрачены на игровые приставки и онлайн‑азартные игры.
- В июле 2025 года один злоумышленник, используя платформу агентного программирования Claude Code, провёл вымогательскую кампанию против 17 организаций за месяц: ИИ разрабатывал вредоносный код, систематизировал украденные файлы, анализировал финансовую отчётность для калибровки требований и формировал тексты писем‑шантажей.
- В декабре 2025 года другой одиночный актор с помощью Claude Code и ChatGPT взломал более 10 ведомств правительства Мексики и похитил свыше 195 млн записей налогоплательщиков.
Все эти кейсы демонстрируют: роль ИИ уже не вспомогательная, а сквозная — от разработки эксплойтов до автоматизации финансового анализа и коммуникаций.
Эволюция атак на открытый код и репозитории пакетов
Одним из наиболее показательных индикаторов стал рост вредоносных пакетов в публичных репозиториях:
- в 2022 году фиксировалось около 55 000 вредоносных пакетов;
- к 2025 году число выросло до 454 600, с заметными скачками в 2023 (выход GPT‑4) и 2025 годах (массовое распространение агентных ИИ‑инструментов программирования).
В сентябре 2025 года атака Shai-Hulud на экосистему npm скомпрометировала более 500 пакетов. Были утечены секреты 487 организаций, а из криптокошелька Trust Wallet украдено 8,5 млн долларов после того, как злоумышленники, воспользовавшись скомпрометированными учётными данными, подменили его расширение для Chrome.
Характерно, что вредоносные пакеты маскировались под популярные библиотеки (например, chalk, debug), содержали документацию, модульные тесты и код, похожий на телеметрические модули. Классические статические анализаторы и сигнатурные сканеры пропускали их, поскольку структура выглядела как «нормальное» ПО. Это совпадает с общей тенденцией, когда поведенческие шаблоны атак описываются на уровне тактик и техник, например, в матрице MITRE ATT&CK, а не через статические сигнатуры.
Сокращение времени до эксплуатации уязвимостей
Другой ключевой показатель — time to exploit, время от раскрытия уязвимости до появления эксплойта «в поле»:
- в 2020 году оно превышало 700 дней;
- в 2025 году сократилось до 44 дней.
Отчёт M-Trends 2026 компании Mandiant показывает ещё более тревожную картину: окно фактически стало отрицательным, так как эксплойты всё чаще появляются раньше патчей, а 28,3% записей CVE эксплуатируются в течение 24 часов с момента раскрытия. На этом фоне каталоги уязвимостей, такие как NVD, превращаются для преступников в список задач, которые можно быстро автоматизировать с помощью ИИ.
Дисбаланс между скоростью атаки и скоростью защиты
Данные Edgescan за 2025 год демонстрируют, что среднее время исправления известных уязвимостей высокой и критической важности составляет 74 дня, а 45% уязвимостей в инфраструктуре крупных компаний (от 1000 сотрудников) так и не устраняются. На этом фоне среднее время разработки эксплойта (44 дня) и доля атак в первые сутки после раскрытия создают устойчивый перевес на стороне атакующих.
Рост возможностей ИИ для разработки кода
По мере того как фронтирные модели (ChatGPT, Claude, Gemini) улучшали результаты на бенчмарках разработки ПО (например, SWE-bench), их вклад в наступательные операции стал заметно выше:
- в августе 2024 года топовые модели автоматически решали около 33% реальных задач из GitHub на SWE-bench;
- к декабрю 2025 года показатель достиг почти 81%.
Это означает, что большая часть рутинной и средней сложности разработки эксплойтов и утилит теперь доступна злоумышленникам как сервис, а не как компетенция.
Попытка структурного ответа: Chainguard Libraries
На фоне взрывного роста атак на цепочку поставок появляется подход, нацеленный не на ускорение реагирования, а на удаление целых классов рисков. Пример — Chainguard Libraries, где каждая открытая библиотека пересобирается из проверенного, атрибутированного исходного кода. Архитектурная цель — сделать невозможными:
- захват процессов CI/CD через подмену зависимостей;
- атаки типа dependency confusion;
- кражу и злоупотребление долгоживущими токенами при сборке;
- атаки на инфраструктуру распространения пакетов.
При тестировании на 8 783 вредоносных пакетов для npm Chainguard Libraries заблокировали 99,7% из них; для примерно 3 000 вредоносных Python‑пакетов — около 98%. Это иллюстрирует, насколько эффективнее оказываются меры, встроенные в саму архитектуру цепочки поставок, по сравнению с добавлением новых слоёв детектирования.
Контекст угроз: кто и как страдает сильнее всего
По приведённым примерам видно, что атаки затрагивают:
- государственный сектор — от японской правоохранительной системы до правительственных ведомств Мексики, где утечка 195 млн налоговых записей создаёт долгосрочные риски мошенничества и политических манипуляций;
- операторов связи и критическую инфраструктуру — инцидент с Rakuten Mobile показывает, что даже подростки могут инициировать масштабные нагрузки или мошеннические операции против телеком‑платформ;
- финансовые сервисы и криптоплатформы, как в случае с Trust Wallet и хищением 8,5 млн долларов через отравление расширения браузера;
- любой бизнес, зависящий от npm, PyPI и других репозиториев открытого кода, где сотни тысяч вредоносных пакетов повышают базовый уровень риска даже для тривиальных зависимостей.
Общий знаменатель — массовая зависимость от внешнего кода и сервисов, поверх которой традиционная модель «обновить антивирус и регулярно устанавливать патчи» больше не даёт приемлемого остаточного риска. Это подтверждается и аналитикой таких организаций, как CISA, которые последовательно смещают фокус к архитектурным принципам «secure by design».
Оценка воздействия на бизнес и операции
- Операционные риски: вынужденные заморозки кода после атак на репозитории (как после Shai-Hulud) приводят к задержкам релизов, срыву дорожных карт и росту технического долга.
- Финансовые потери: прямые хищения (миллионы долларов в кейсе Trust Wallet), выкуп, простои сервисов и последующие инвестиции в форсированное улучшение безопасности.
- Риски конфиденциальности и регуляторные санкции: утечка 7 млн записей клиентов Kaikatsu Club и 195 млн записей налогоплательщиков в Мексике поднимают вопросы не только о штрафах, но и о невозможности «отозвать» уже утекшие данные.
- Репутация и доверие: осведомлённость пользователей о том, что киберпреступления теперь может совершать «любой с ИИ‑ассистентом», повышает чувствительность к новостям об инцидентах и снижает толерантность к сбоям.
Качественно новая проблема — расширение пересечения между теми, кто готов совершать атаки, и теми, кто способен их проводить. Раньше это была узкая прослойка; теперь, благодаря ИИ, она быстро растёт, а масштаб атак всё меньше зависит от размера и зрелости преступной группировки.
Практические рекомендации по снижению риска
1. Принять как базу: эксплойт появится раньше, чем вы успеете пропатчить
- Планировать процессы управления уязвимостями, исходя из сценария, что эксплуатация возможна в первые 24 часа после раскрытия (или раньше), даже если патч ещё не вышел.
- Выделить отдельный поток для обработки критических уязвимостей с более агрессивными SLO (часы–несколько дней), включая временные компенсирующие меры (отключение функций, ограничение экспонированных сервисов, фильтрация трафика).
2. Жёстко контролировать цепочку поставок ПО
- Создать внутренний репозиторий зависимостей (зеркало npm, PyPI и т. п.) с одобрением и публикацией только проверенных версий библиотек.
- Включить обязательное прохождение пакетов через процесс проверки (статический анализ, ручной обзор, сопоставление с известными легитимными источниками) перед попаданием в продуктивный репозиторий.
- Рассмотреть решения, которые пересобирают открытые библиотеки из атрибутированного исходного кода и предоставляют гарантии неизменности сборок по аналогии с Chainguard Libraries, чтобы целые классы атак (dependency confusion, компрометация CI/CD, подмена бинарей) становились технически невозможны.
3. Усилить детектирование атак на уровне поведения, а не только кода
- Не полагаться на сигнатурные сканеры для выявления вредоносных пакетов: ИИ‑генерированный код легко маскируется под «нормальный» с документацией и тестами.
- Внедрить мониторинг поведения зависимостей: сетевые запросы при установке, попытки доступа к конфиденциальным файлам, запуск внешних процессов из install‑скриптов.
- Использовать изолированные окружения (sandbox) для тестирования новых пакетов перед их использованием в CI/CD и в продакшене.
4. Управление доступом к ИИ‑инструментам разработки
- Формализовать политику использования систем вроде ChatGPT и Claude Code: запрет на загрузку чувствительных фрагментов кода и секретов, требования по логированию сессий.
- Проводить обучение разработчиков и аналитиков рискам не только утечки, но и злоупотребления ИИ — от неосознанной генерации уязвимого кода до помощи в обходе внутренних контролей.
5. Подготовка к инцидентам в цепочке поставок
- Заранее определить процедуру быстрого «замораживания» зависимостей и отката к предыдущим версиям при обнаружении компрометации пакета.
- Вести перечень используемых библиотек и их происхождения (по сути, внутреннюю инвентаризацию, аналогичную программной «ведомости материалов»), чтобы при новой атаке на npm или другой реестр быстро определить, кто затронут.
Ключевой вывод: в условиях, когда эксплуатация уязвимостей ускоряется быстрее, чем сокращаются циклы выпуска патчей, ставка только на скорость реагирования обречена; первым приоритетом должно стать создание контролируемого внутреннего репозитория зависимостей и перенос на него всех процессов сборки и развертывания, чтобы по максимуму отсечь классы атак на цепочку поставок ещё до того, как они попадут в ваш контур.
