Новый фронт безопасности приложений

Разработчики всей планеты атакованы. Модель Mythos показала, что это только начало

Иногда индустрия получает новость, после которой уже нельзя делать вид, что всё идёт по старому сценарию. Весной-летом 2026 года таких новостей оказалось сразу две.

Первая — новая волна атак на цепочки поставок программного обеспечения (ПО). Хакеры перевели внимание с компьютеров пользователей и серверов намного глубже — на компьютеры и инструменты разработчиков ПО. Это не одна атака и не один скомпрометированный пакет, а целый клубок: Megalodon, Mini Shai-Hulud, Glassworm, компрометации npm, PyPI, GitHub Actions, расширений для VS Code и OpenVSX, а также CI/CD-сред и OIDC-токенов. 

Вторая — промежуточные результаты инициативы Anthropic Project Glasswing и модели Claude Mythos Preview. Она уже нашла тысячи серьёзных уязвимостей в критически важном ПО. Показательна результативность. За несколько недель Mythos и около 50 партнёров Anthropic выявили около 23 тысяч находок, из которых более 6 тысяч — уязвимости высокого и критического уровня. Для сравнения: за весь 2025 год во всём мире было зарегистрировано порядка 48 тысяч CVE. То есть один инструмент за недели дал поток находок, сопоставимый с несколькими месяцами регистрации уязвимостей по всей планете.

Оба сюжета — признаки новой линии фронта войны с хакерами и кардинальных изменений в безопасности приложений. Взглянем подробнее на эти новости, начиная с первой.

Атаки на производство ПО

Инцидент с SolarWinds в 2020 году стал одним из первых крупных ударов по цепочке поставок. Тогда злоумышленники внедрили бэкдор SUNBURST в платформу SolarWinds Orion. После этого были и другие громкие эпизоды.

Codecov (2021) стал болезненным уроком для непрерывной интеграции (CI). Изменённый Bash Uploader мог выводить из CI-сред переменные окружения, ключи, токены и другие секреты.

Log4Shell (2021) показал, насколько опасной может быть одна уязвимость в широко используемой библиотеке. Это не была классическая компрометация цепочки поставок, но удар пришёл через зависимость, встроенную в огромное число систем. CISA, ФБР, АНБ и другие агентства выпускали совместные рекомендации по устранению риска.

3CX (2023) продемонстрировал ещё более неприятную вещь — одна атака на цепочку поставок может стать входом для другой. Mandiant описала редкий каскадный случай, когда компрометация одного поставщика (Trading Technologies) привела к компрометации другого — десктопного приложения 3CX.

XZ Utils (2024) был почти шпионским романом. В upstream-тарболлы xz/liblzma попал бэкдор, а проблему заметили из-за странной нагрузки при SSH-входах. NVD описывает CVE-2024-3094 как злонамеренный код, внедрённый в исходники xz начиная с версии 5.6.0, со сложной обфускацией и вмешательством в процесс сборки liblzma.

Текущая волна отличается от всех этих историй. Раньше атакующий чаще бил по готовому продукту, обновлению или конкретному поставщику. Сейчас злоумышленник всё чаще бьёт “по площадям” — по самой фабрике ПО: по разработчикам, IDE, расширениям, CI/CD, GitHub Actions, npm и PyPI, OIDC, секретам и процессам публикации. Образно выражаясь, сейчас это ближе к подмене “конвейера”, чем к подмене “коробки на складе” как раньше.

Хроника новой волны атак

Megalodon: шесть часов и 5 561 репозиторий. По данным SafeDep, 18 мая 2026 года автоматизированная кампания за шестичасовое окно внедрила вредоносные изменения в 5 561 публичный репозиторий GitHub (более 5 700 коммитов). Атакующий добавлял файлы workflow, замаскированные под обычную оптимизацию CI. Код приложения мог вообще не затрагиваться, зато пайплайн начинал воровать облачные учётные данные, ключи SSH и токены OIDC.

Здесь важный нюанс. Многие команды всё ещё проверяют только код приложения. Но если вредоносная логика живёт в workflow, в раннере, в action или в job публикации, обычный анализ кода её легко проморгает. В репозитории вроде бы «ничего страшного», а секреты уже ушли.

Mini Shai-Hulud: когда доверенная сборка выпускает недоверенный пакет. 11 мая 2026 года, с 19:20 до 19:26 UTC, было опубликовано 84 вредоносные версии в 42 пакетах семейства @tanstack/*. Пакеты вышли не через украденный пароль npm. Их опубликовал легитимный release-pipeline TanStack с доверенной OIDC-идентичностью после того, как атакующий перехватил раннер прямо посреди workflow.

И вот тут ломается привычная картина. Если подпись есть, если источники (provenance) проверены, если сборка прошла «правильно», можно ли доверять пакету? Не всегда. Snyk прямо подчёркивает: SLSA-provenance подтверждает, каким доверенным процессом собран пакет, но не гарантирует, что попавший в этот процесс код безопасен. Это, по доступным данным, первый задокументированный случай вредоносных npm-пакетов с валидной аттестацией SLSA Build Level 3. Aikido оценила масштаб всей волны в 373 вредоносные версии в 169 именах пакетов.

Атака на @antv. Snyk отдельно описала эпизод с @antv — компрометацию npm-аккаунта сопровождающего и публикацию 637 вредоносных версий в 323 пакетах, с суммарной оценкой около 16 млн загрузок в неделю. Microsoft Threat Intelligence разобрала пейлоад, доставленный через скомпрометированный пакет Mistral AI в той же волне.

Miasma и @redhat-cloud-services. Уже 1 июня 2026 года Unit 42 описала новый supply-chain инцидент. Были скомпрометированы как минимум 32 npm-пакета в namespace @redhat-cloud-services. По данным исследователей, атакующий использовал скомпрометированный GitHub-аккаунт сотрудника Red Hat, обходил code review через orphan commits, запускал GitHub Actions, получал OIDC-токены и публиковал троянизированные пакеты с валидным SLSA provenance. И снова вывод тот же: корректная аттестация процесса сборки не спасает, если сам пайплайн уже стал частью атаки.

Glassworm: разработчик как «богатая добыча». 26 мая 2026 года CrowdStrike совместно с Google и The Shadowserver Foundation провела скоординированное отключение ботнета Glassworm, одновременно ударив по четырём каналам управления (C2): серверам на коммерческих VPS, блокчейну Solana, сети BitTorrent DHT и заголовкам событий в Google Calendar. 

Glassworm использовал троянизированные расширения для VS Code и OpenVSX, npm- и Python-пакеты, postinstall- и setup-скрипты, и был рассчитан не только на VS Code, но и на Cursor, Positron, Windsurf, VSCodium и другие редакторы. CrowdStrike формулирует вывод прямо: теперь противники атакуют не только продукты, но и разработчиков, которые эти продукты создают.

Почему именно разработчиков? Потому что это “жирная добыча”. У них есть доступ к исходному коду, GitHub, npm, PyPI, облакам, Kubernetes, CI/CD и production-секретам. Иногда — ко всему сразу. Один заражённый ноутбук может стать мостиком к сотням клиентов вниз по цепочке. 

Причины волны атак на цепочку поставок

По государственному резонансу SolarWinds всё ещё стоит особняком. Там была масштабная кибершпионская операция. Однако по охвату экосистемы разработки текущая волна выглядит, осторожно выражаясь, одной из самых широких с 2020 года. В ней одновременно сошлись несколько факторов:

• разработчики массово используют расширения IDE;
• CI/CD получил слишком много прав;
• секреты живут слишком близко к процессу сборки;
• реестры пакетов стали каналом доставки кода прямо в продакшн;
• ИИ-ассистенты резко ускорили генерацию и изменение кода;
• многие команды не успевают проверять то, что сами же теперь генерируют.

Эта “взрывоопасная смесь” как раз и воспламенилась прошедшей весной.

ИИ уже давно используется атакующими как ускоритель. Однако в мае 2026 года Google Threat Intelligence Group описала переход от ранних единичных злоупотреблений к промышленному применению генеративных моделей в наступательных рабочих процессах: поиск уязвимостей, генерация эксплойтов, разработка вредоносного ПО с помощью ИИ, автономные операции вредоносов и атаки на сами ИИ-среды и зависимости.

Ещё один важный сигнал дала Anthropic в июне 2026 года. Компания проанализировала 832 вредоносных аккаунта и сопоставила их действия с MITRE ATT&CK. Вывод неприятный: ИИ уже используется не только для подготовки атаки, фишинга или написания простого вредоносного кода, но и для действий после первоначальной компрометации. По данным Anthropic, 560 из 832 изученных аккаунтов использовали ИИ для написания вредоносного ПО, а 54 — для бокового движения (lateral movement). Доля акторов среднего и более высокого риска выросла с 33% в первой половине периода до 56% во второй.

Это меняет саму оценку угрозы. Раньше количество техник, набор инструментов и вид интерфейса могли косвенно говорить об уровне атакующего. Теперь слабый оператор с хорошей агентной “обвязкой” вокруг модели может выполнять действия, которые раньше требовали более высокой квалификации. Anthropic прямо пишет, что MITRE ATT&CK пока не полностью отражает опасные свойства ИИ-атак: последовательную оркестрацию этапов, принятие решений в реальном времени и выполнение цепочки действий с минимальным участием человека.

CrowdStrike в Global Threat Report 2026 приводит цифры, которые меняют экономику атак: активность противников, использующих ИИ, выросла на 89% год к году; среднее время «прорыва» (от первоначального доступа до бокового перемещения) сократилось до 29 минут, а самый быстрый наблюдаемый прорыв занял 27 секунд.

Это не значит, что каждый вредоносный коммит сделан моделью ИИ. Главный вопрос в другом: ИИ резко снижает стоимость скучных, грязных, трудоёмких частей атаки — подобрать правдоподобный pull request, переписать вредоносный код под стиль проекта, сгенерировать варианты обфускации, подготовить фишинг для сопровождающего, быстро разобрать конфигурацию CI/CD, собрать цепочку эксплойтов. Раньше для этого нужно было больше рук. Теперь достаточно меньше людей, но с лучшими инструментами.

Кто на светлой стороне?

По другую сторону фронта борьбу возглавил проект Glasswing. В начале апреля 2026 года компания Anthropic дала примерно полусотне партнёров ранний доступ к своей модели ИИ Claude Mythos Preview. Миссия высокая — укрепить ПО, критически важное для планеты, прежде, чем подобные возможности окажутся в руках атакующих. Среди партнёров оказались AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks и другие компании.

Цифры впечатляют. Anthropic сообщает, что модель Mythos Preview нашла 6 202 уязвимости высокого и критического уровня в более чем тысяче open-source-проектов — из 23 019 находок суммарно. Из проверенной независимыми исследователями выборки в 1 752 находки 90,6% оказались настоящими уязвимостями. Отдельные партнёры отчитались о собственных результатах. Cloudflare нашла около 2 000 ошибок, из них примерно 400 — высокого или критического уровня.

Но самое важное в отчёте — не количество найденного, а то, где теперь узкое место. Anthropic честно признаёт: раскрытие — лишь часть найденного, потому что ограничивающим шагом стали человеческая сортировка, проверка и исправление. По данным компании, к 22 мая 2026 года через скоординированное раскрытие прошло около сотни уязвимостей в сотнях проектов, но исправлена пока лишь малая доля (менее 1%). Некоторые сопровождающие даже просили Anthropic снизить темп раскрытий, поскольку на патч уязвимости высокого и критического уровня в среднем уходит около двух недель.

Вот это, пожалуй, главная проблема. Узкое место смещается. Не «найти», а проверить, приоритизировать, раскрыть, исправить и безопасно доставить патч.

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

К счастью, Anthropic не одна

К началу июня Anthropic расширила Glasswing. К программе должны подключиться около 150 новых организаций из более чем 15 стран, в том числе поставщики критической инфраструктуры и вендоры, от кода которых зависят многие другие организации. В то же время, конкуренты Anthropic пытаются догнать лидера.

Google DeepMind представила CodeMender как ИИ-агента для безопасности кода. По словам Google, направления Big Sleep и OSS-Fuzz уже показали способность ИИ находить zero-day в хорошо протестированном ПО, а CodeMender за полгода помог внести в open-source около 72 исправлений безопасности.

GitHub развивает Code Security и Copilot Autofix. Компания заявляет о среднем ускорении устранения уязвимостей в три раза и предложениях для 90% типов алертов. Агентный Autofix должен автономно создавать pull request’ы с исправлениями.

OpenAI развивает Codex Security с упором на полный цикл — модель угроз, реалистичные пути атаки, изолированную валидацию и патчи для проверки человеком.

Microsoft расширяет агентов Security Copilot на разбор фишинга, устранение уязвимостей и триаж алертов — уже не только для AppSec, но и для облака, идентичности и реагирования на инциденты.

Semgrep двигает AI-assisted AppSec: SAST, SCA, поиск секретов, приоритизацию и защиту ИИ-сгенерированного кода «у источника».

IBM и Red Hat 28 мая 2026 года объявили о Project Lightwell — инвестиции в 5 млрд долларов и команде из более чем 20 тысяч инженеров, которые вместе с ИИ-инструментами будут защищать open-source через «доверенный клиринговый центр».

Гонка началась. Чем активнее будет здоровая конкуренция между производителями, тем сильнее выиграет вся индустрия безопасности.

Старые и новые проблемы безопасной разработки

Старые проблемы безопасности приложений никуда не исчезли: SQL-инъекции, XSS, нарушенный контроль доступа и так далее. Секреты по-прежнему всплывают в репозиториях. Устаревшие зависимости тянутся годами. CI/CD часто строится по принципу «лишь бы собиралось».

В то же время, к классическим проблемам добавились новые:

1. Ускоренное накопление технического долга. Вайб-кодинг даёт быстрый работающий прототип, но «работает» — не значит «безопасно», особенно без моделирования угроз и тестирования негативных сценариев.
2. Ложное чувство уверенности. LLM убедительно объясняет код, даже когда решение небезопасно. Известное когнитивное искажение ощущения безопасности, заменяющего состояние безопасности, выходит на новый уровень.
3. Зависимость от внешнего контекста. Промпт, README, issue, документация зависимости, тестовая фикстура или комментарий в коде могут влиять на поведение агента. Это путь к косвенным инъекциям в рабочие процессы разработчика.
4. Доступ к секретам. ИИ-агент, расширение IDE или локальный инструмент нередко видят больше, чем нужно: терминал, репозиторий, .env, конфиг SSH, облачные профили, токены пакетов.
5. Ускоренное «загрязнение» цепочки поставок. Если ассистент предлагает добавить пакет, который выглядит популярным, но недавно был скомпрометирован, команда может принять риск быстрее, чем успеет его осознать.

NIST SSDF говорит простую вещь: практики безопасной разработки нужно встраивать в SDLC. Теперь к этому добавляется новое требование. Проверять нужно не только код, который пишет человек, но и код, который предлагает ИИ. Проверять промпт-потоки, ИИ-агентов, расширения IDE, идентичности CI/CD. Относиться к источникам (provenance) не как к красивой печати, а как к части более широкой модели доверия.

Поэтому безопасное использование ИИ в разработке — это не запрет, а управляемый процесс: политики, изоляция, контроль расширений, allowlist’ы зависимостей, короткоживущие секреты и проверка ИИ-кода так же строго, как человеческого.

Прогнозы

Главная проблема 2026 года уже не в том, что ИИ “пишет небезопасный код”. Это слишком узкая формулировка. Настоящий риск в том, что ИИ начинает участвовать во всём контуре разработки и атаки: помогает писать код, выбирать зависимости, управлять workflow, искать уязвимости, строить эксплойты, двигаться внутри сети и адаптироваться к среде. Поэтому защищать нужно не только приложение, а всю фабрику ПО и весь контур ИИ-ассистированной разработки. Наши предсказания на 2026-2027 годы:

Первое. Атак на рабочие станции разработчиков, расширения IDE, GitHub Actions, OIDC, реестры пакетов и ИИ-процессы разработки станет намного больше.

Второе. Новый вид вредоносного ПО уже показан лабораторно. Адаптивные ИИ-черви не просто используют заранее написанный эксплойт, а подбирают тактику под конкретную цель. Следующий риск — перенос похожей агентной логики в цепочки поставок: IDE-расширения, CI/CD, GitHub Actions, npm/PyPI, publish-pipeline и рабочие станции разработчиков.

Третье. Возможности уровня Mythos станут доступнее. Даже если Anthropic будет осторожна, конкуренты, модели open-source, государственные лаборатории и серый рынок будут двигаться в ту же сторону.

Четвёртое. Рынок AppSec сместится от «нашли список багов» к «снизили реальный риск». Найти станет легче. Ценностью станет доказать эксплуатируемость, убрать ложные срабатывания, устранить первопричину, не сломать релиз и не похоронить команду в усталости от алертов.

Пятое. Компании начнут требовать анализ безопасности ИИ почти так же естественно, как раньше требовали пентест перед запуском. Особенно если используются Copilot, Cursor, Claude Code, GitHub Actions, npm/PyPI, LLM-агенты или собственные ИИ-функции в продукте.

Что делать?

Не паниковать, но и не спать.

Всем командам разработки стоит пересмотреть права CI/CD: убрать долгоживущие секреты, ограничить политики доверия OIDC, проверить GitHub Actions (особенно pull_request_target, небезопасную работу с форками, отравление кэша, широкие permissions и автоматические job’ы публикации), включить сканирование секретов, контролировать зависимости и их «возраст», разделить права на сборку, тестирование, выпуск и деплой, проверять расширения IDE, логировать исходящие соединения раннеров и относиться к рабочей станции разработчика как к привилегированному активу, а не как к «просто ноутбуку».

Командам, использующим ИИ в разработке, дополнительно нужны отдельные правила. Код, сгенерированный ИИ, следует считать недоверенным до проверки. Нельзя отдавать моделям секреты, клиентские данные, production-конфиги и закрытый код без понятного правового и технического режима. Для ИИ-агентов это критично вдвойне: там автономия превращается в проблему намного быстрее, чем при обычной генерации кода силами LLM.

Для нас эта волна подтверждает то, что мы и так давно видим в проектах по безопасности приложений, DevSecOps, AI security и архитектурным аудитам. Риск больше не живёт только в коде приложения. Он живёт в связях, зависимостях, pipeline, доступах, секретах, инструментах разработчика и автоматизации, а также всё чаще в самом ИИ, который помогает писать, читать, исправлять и запускать код.

Поэтому защита должна быть комплексной. H-X Technologies помогает проверять безопасность приложений, исходного кода, облачных конфигураций, DevOps и ИИ-ассистированной разработки. Мы выполняем не только пентесты, аудит безопасности приложений, SAST/SCA, анализ CI/CD, но и оценку безопасности цепочки поставок, архитектуры, ИИ-решений и стратегического управления ИИ. 

Мы можем провести точечный разбор после инцидентов вроде Mini Shai-Hulud или Megalodon, помочь построить безопасный SDLC и оценить риски Copilot, Claude Code, Codex, Cursor, Windsurf и других инструментов в вашей среде. Не «поставим галочку», а проверим, где у вас реально может сломаться цепочка доверия, как это доказать, и что исправить в первую очередь.

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

Сейчас выигрывает не тот, кто громче говорит «мы используем ИИ», а тот, кто умеет безопасно жить в мире, где ИИ уже используют все: разработчики, защитники и атакующие.

Напишите нам сегодня и получите бесплатную консультацию по безопасности приложений и ИИ.