Изменение ландшафта киберугроз в первом полугодии 2026 года по данным Yandex Cloud

Что изменилось

В первом полугодии 2026 года видна существенная трансформация характера киберугроз в облачных средах. По данным телеметрии и систем защиты, общее число отражённых атак увеличилось на 60% по сравнению с аналогичным периодом 2025 года. Растёт не только активность злоумышленников, но и эффективность механизмов обнаружения и реагирования в облаке. В частности, теперь используются поведенческие детекты, объединения разной телеметрии в единый контекст, а также автоматизация сбора, триажа и поиска событий в окрестности инцидента с помощью пайплайнов и ИИ-агентов.

Кроме общего увеличения количества детектируемых атак, можно отметить три ключевых аспекта, в которых наблюдаются наиболее явные изменения.

Во-первых, это векторы атак, их типы и используемые техники.

Произошло смещение акцента с атак на Identity в сторону эксплуатации уязвимостей: с начала 2026 года эксплуатация уязвимостей выходит на первый план как ведущий вектор первоначального доступа и всё чаще используется для повышения привилегий, хотя компрометация Identity остаётся одним из основных векторов.

Во-вторых, значительная динамика наблюдается как в скорости реализации атак, так и в защите — всё становится намного быстрее.

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

В-третьих, это рост количества кейсов с использованием ИИ.

Все три аспекта не существуют по отдельности: ИИ ускоряет реализацию атак, ускорение и оркестрация делают старые векторы проще и опаснее. Формируется такой ландшафт угроз, в котором ручная человеческая защита просто физически не успевает за количеством атак и их скоростью.

С 2025 года распределение атак по отраслям изменилось. Сменился лидер: если в первой половине 2025 года атакующих больше всего интересовал сектор разработки ПО и SaaS (35%) как точка входа в цепочку поставок, то к первому полугодию 2026-го на первое место вышел ритейл и электронная коммерция (рост с 22 до 39,2%).

Второй заметный сдвиг — выход промышленности в приоритетные цели (с 22 до 29,4%). Доля IT/SaaS снизилась (с 35 до 21%) — это перераспределение фокуса в сторону отраслей с более прямой монетизацией, а не потеря интереса, а также эффект того, что технологические компании в среднем более зрелые в вопросах защиты информации. Финансовый сектор стабилен — примерно 10% от общего числа инцидентов.

Такая структура отражает как экономическую мотивацию атакующих (доступ к транзакциям и пользовательским данным), так и уровень цифровизации отраслей.

Обычно цель массовых автоматизированных атак — это скрытая установка майнеров в инфраструктуре c различными базовыми закреплениями через cron или systemd юниты и сбор секретов для дальнейшей перепродажи доступа к инфраструктуре.

Распределение техник атакующих в статистике инцидентов и алертов YCDR

Наш сервис мониторинга и реагирования на инциденты в облаке Yandex Cloud Detection and Response с конца 2025 года наблюдает некую смену парадигмы: эксплуатация уязвимостей становится ведущим вектором первоначального доступа, также заметно увеличивается доля использования уязвимостей для повышения привилегий.

Техника T1190: Exploit Public‑Facing Application выросла до 25% от общего числа детектируемых техник. В эту статистику попадают не только использование известных эксплойтов, но и попытки эксплуатации уязвимостей в различных эндпоинтах и сервисах.

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

С одной стороны — критичные удалённые RCE для первоначального доступа (Langflow CVE-2026-33017, n8n CVE-2026-21858, NGINX Rift CVE-2026-42945), эксплуатируемые без аутентификации и дающие атакующему плацдарм для дальнейшего развития атаки.

С другой — взрывной рост уязвимостей для локального повышения привилегий (LPE) в ядре Linux (Copy Fail CVE-2026-31431, ssh-keysign-pwn CVE-2026-46333 и семейство Dirty Frag CVE-2026-43284, CVE-2026-43500, Fragnesia CVE-2026-46300, DirtyClone CVE-2026-43503). В облачной и контейнерной инфраструктурах опасность этой связке добавляет возможность побега из контейнера. То есть вместе они образуют полную цепочку компрометации от периметра до корневых прав на управляющих нодах.

В облачной инфраструктуре Yandex Cloud с конца 2025 года зафиксированы массовые кампании по эксплуатации критичной уязвимости React2Shell и попытки повышения привилегий через уязвимости ядра Linux (Copy Fail и Dirty Frag).

На примере React4Shell мы фиксировали первые следы эксплуатации уязвимости и следы закрепления на хосте на второй день после публичного раскрытия уязвимости.

Такой рост уязвимостей можно связать и просто с «удачным периодом» исследователей безопасности, но статья Anthropic с обзором работы модели Mythos как будто показывает, что такой рост числа уязвимостей может быть только началом. Mythos может писать эксплойты, объединяя несколько уязвимостей в цепочку. Скорость написания эксплойтов теперь насчитывает часы вместо дней или недель ранее, а показатели числа найденных эксплойтов в сравнении с предыдущей моделью выросли в сотни раз.

Рост числа уязвимостей виден и в базах данных уязвимостей. NIST официально отказался от полного обогащения всех CVE и перешёл к приоритизации по эксплуатируемости и значимости для госсектора. Это изменение обусловлено всплеском числа представлений CVE, которое увеличилось на 263% в период с 2020 по 2025 год. Количество заявок в течение первых трёх месяцев 2026 года почти на треть больше, чем за тот же период прошлого года.

Всё это говорит о структурном сдвиге, а не о временном всплеске: окно между раскрытием и появлением рабочего эксплойта продолжит сжиматься, а ставка на ручную приоритизацию и «средний» SLA по патчингу становится всё менее оправданной.

Компрометация Identity всё ещё остаётся одним из основных векторов компрометации в облаке

Хоть и ушла на второе место, уступив лидерство эксплуатации уязвимостей. В Yandex Cloud мы фиксировали несколько попыток атак, первоначальный доступ в которых начался с восстановления доступа к учётной записи через контрольный вопрос, последующего создания вредоносных ресурсов и развития атаки с закреплением через сервисные учётные записи и специально созданные для них ключи доступа.

Суммарно техника T1078: Valid Accounts встречалась в 15% инцидентов от общего числа атак.

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

Техника использования избыточных разрешений для получения доступа и повышения привилегий (YC9019: Exploiting Redundant Permissions for Access and Escalation) составила 6%.

Анализ, проведённый Unit 42 на основе более чем 680 тыс. учётных записей в облачных сервисах, показал, что у 99% облачных пользователей, ролей и сервисов были избыточные разрешения, некоторые из которых не использовались в течение 60 дней и более. Это создаёт среду, в которой горизонтальное перемещение проще, чем должно быть, поскольку у многих учётных записей были привилегии, которые им не нужны в повседневной работе.

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

При этом мы видим, что атаки массового характера, например для скрытой установки майнеров, обычно полагаются только на эксплуатацию уязвимостей и чаще всего не развивают атаку в части Identity.

Резкий рост атак через цепочки поставок

Это один из векторов, который мы наблюдали в Yandex Cloud напрямую. В первой половине 2026 года были множественные компрометации npm-библиотек, причём почти у всех этих кейсов механика была одинаковой: компрометация аккаунта мейнтейнера, публикация патч-версии с добавленной «фантомной» зависимостью и полезная нагрузка, отрабатывающая через postinstall.

Показательнее всего — мартовский инцидент с Axios, популярным пакетом более чем с 100 млн загрузок в неделю. Версии 1.14.1 и 0.30.4 тянули пакет plain-crypto-js@4.2.1, чей postinstall-скрипт с помощью XOR+base64-обфусцированного дроппера разворачивал RAT под macOS, Windows и Linux. После этого выполнялись закрепление и очистка следов установки скомпрометированной версии. Пакет прожил всего 2–3 часа, но за это время успел разойтись по десяткам тысяч хостов и раннеров для кражи секретов — от переменных окружения до CI/CD-токенов и облачных ключей.

В ходе Threat Hunting по признакам компрометации Axios мы зафиксировали десятки резолвов вредоносного домена sfrclak[.]com из различных облаков и оперативно оповестили клиентов.

Отдельного внимания заслуживает и мартовский инцидент со сканером уязвимостей Trivy. Он показывает, что точкой входа в атаку на цепочку поставок может стать даже инструмент безопасности, и снова возвращает нас к теме Identity: для компрометации Trivy атакующие воспользовались доступами, украденными ранее, а результатом стала кража SSH-ключей, облачных секретов доступа и других аутентификационных данных.

Схожую механику показывает разобранный Google кейс группы UNC6426 (2025): через вредоносный npm-пакет QUIETVAULT во фреймворке Nx злоумышленники украли GitHub-токен и получили административные привилегии менее чем за 72 часа. А в цифрах масштаб подтверждают Verizon DBIR (доля supply-chain вектора выросла ещё на 60% — после удвоения годом ранее).

В первом полугодии 2026 года мы также фиксируем значимый прирост техник использования прокси-инфраструктуры и туннелирования трафика (T1090: Proxy, T1572: Protocol Tunneling) — их доля достигла уровня 25% от общего числа детектируемых техник по сравнению с 16% в прошлом году.

Злоумышленники маскируют свои IP‑адреса через цепочку прокси и используют TOR для анонимизации и усложнения трассировки атак. Нужно мониторить критичные события Audit Trails и отслеживать в них аномальные входы пользователей и сервисных учётных записей в облако с подозрительных хостинговых адресов или узлов TOR.

Для скрытых каналов C2 чаще всего используются gsocket и revsocks, а также применяются обратные SSH-туннели с переадресацией портов (ssh -R) на внешний узел и утилиты GOST, rsocx, cloudflared и Localtonet. В облаке особенно часто такие инструменты используются как резервный канал доступа с различными закреплениями.

Часто вместо специальных утилит злоумышленники используют легитимные средства удалённого доступа (AnyDesk или MeshCentral Agent), а также активно используют легитимные сервисы, например Telegram, вместо классических командных серверов.

Заметно растут техники обхода средств защиты, скрытности и техники класса Impair Defense, связанные с удалением логов и очисткой истории действий злоумышленников.

В Windows-инфраструктурах для отключения СЗИ злоумышленники часто используют технику BYOVD (Bring Your Own Vulnerable Driver). По данным ESET, из около 90 отслеживаемых в 2026 году EDR-киллеров уже 54 используют подписанные уязвимые драйверы — суммарно эксплуатируются 35 разных драйверов.

Работает эта техника так: на атакуемую систему загружается подписанный легитимный, но уязвимый драйвер. Операционная система доверяет цифровой подписи, загружает драйвер в ядро, после чего атакующие через IOCTL-интерфейс (Input/Output Control) получают возможность выполнять произвольный код с наивысшими привилегиями в режиме ядра. С помощью такой техники можно завершать процессы защитных средств через ZwTerminateProcess, повреждать PEB или полностью размонтировать исполняемый файл из виртуальной памяти.

По данным Huntress (Pham, Agha, февраль 2026 года), в реальной атаке на инфраструктуру SonicWall SSLVPN злоумышленники использовали форензик-драйвер EnCase (EnPortv.sys) с сертификатом 2006 года выпуска, истёкшим в 2010-м и отозванным. Windows по-прежнему принимает такие драйверы из-за отсутствия проверки CRL при загрузке и правил обратной совместимости для сертификатов, выпущенных до 29 июля 2015 года. Драйвер завершал 59 процессов средств защиты из режима ядра.

Самыми «горячими» драйверами 2026 года стали:

• NSecKrnl.sys;
• связка rwdrv.sys + hlpdrv.sys;
• целый арсенал драйверов GentleKiller группы Gentlemen RaaS (включая googleApiUtil64.sys и ThrottleBlood.sys), поразивший 478 жертв более чем в 70 странах;
• GameDriverx64.sys.

Параллельно продолжает работать «классика»: RTCore64.sys, gdrv.sys, mhyprot2.sys, procexp.sys, dbutil_2_3.sys, PoisonX.sys.

Это говорит не о смене инструментария, а о его накоплении: старые драйверы никуда не деваются, к ним лишь добавляются новые.

В Linux для сокрытия вредоносной активности в 2025–2026 гг. всё чаще встречаются eBPF-руткиты вместо классических LKM-руткитов. Злоумышленник, загружающий вредоносную программу eBPF, получает код, работающий в пространстве ядра, с доступом к данным ядра и без традиционных артефактов загрузки модулей, за которыми следит каждый EDR. При этом часто новые образцы содержат несколько модулей и объединяют как LKM, так и eBPF-программу, где каждая закрывает свой участок или начинает работать в случае неудачи другой.

Наряду со сложными руткитами злоумышленники активно удаляют журналы и историю команд, а также мимикрируют под системные процессы. Если в прошлом году обнаружение таких техник было единичным, то в первом полугодии 2026 года их доля превысила 7% в общем объёме всех детектируемых техник злоумышленников. Мы фиксируем и классическое удаление журналов, и запуски вредоносных процессов через exec -a для маскировки процесса под легитимный. Особой популярностью пользуются kworker, kswapd0 и имитации различных драйверов.

Техника массово встречается и у Linux-майнеров (Kinsing, TeamTNT), и у ботнетов, и в человекоуправляемых атаках, например для сокрытия процессов gsocket.

Согласно статье Anthropic, 54,8% исследованных злоумышленников (более 400 пользователей Claude) использовали ИИ для обхода, отключения или изменения средств защиты конечных точек — так как злоумышленники уделяют значительное внимание постэксплуатационной фазе, снижению вероятности обнаружения и увеличению времени присутствия в инфраструктуре. Для защитников это означает необходимость усиления контроля целостности логов, мониторинга действий в управляющих консолях, выявления аномалий в сетевом поведении и тщательного мониторинга, в том числе с учётом поведенческих аномалий.

Динамика DDoS‑угроз и автоматизация атак

Отдельного внимания заслуживает динамика DDoS‑угроз: за неполный 2026 год количество DDoS-атак на веб-приложения (L7) уже превысило показатели всего 2025 года более чем в два раза: за весь 2025 год было 6348 атак, за первое полугодие 2026-го — 15 140. Максимальное значение мощности атак по RPS (запросы в секунду) — 3 895 876.

При этом использование ИИ для непосредственного проведения DDoS‑атак — всё ещё экономически невыгодный и технически сложный сценарий: создание высокой нагрузки с помощью языковых моделей сопряжено с огромными накладными расходами и ограничениями со стороны сервис‑провайдеров.

Вместо этого злоумышленники делают ставку на коммерциализацию атак и снижение порога входа. Хакерские группировки активно развивают направление DDoS‑as‑a‑Service. Они создают платформы с удобным UI и API, предлагающие услуги по проведению DDoS‑атак или стресс‑тестов. Процесс полностью автоматизирован: клиент выбирает профиль трафика и объём нагрузки, оплачивает услугу анонимно — и запускает атаку в несколько кликов. Такая модель превращает кибератаки в доступный товар, делая их угрозой не только для крупных корпораций, но и для малого и среднего бизнеса.

В этих условиях критически важно, чтобы веб‑ресурсы были готовы к отражению атак в режиме 24/7. Статичный подход к защите здесь не работает: инфраструктура должна обладать встроенной эластичностью и способностью автоматически масштабироваться при резком росте трафика, а системы фильтрации — распознавать не только известные сигнатуры, но и аномальные паттерны поведения, характерные для автоматизированных атак нового типа.

Как ИИ влияет на игру: ускорение, оркестрация, самостоятельность

ИИ всё больше вовлечён в противостояние атакующих и защитников. На практике в расследованиях YCDR мы наблюдаем три основных признака использования ИИ.

Шаблон без привязки к среде

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

Пример механизмов закрепления:

• Systemd user service (T1543.002). Файл ~/.config/systemd/user/javs‑starter.service типа oneshot запускает скрипт /home/user/bin/start_javs.sh в контексте пользователя, без корневых прав.
• Systemd user timer (T1053.006). Файл ~/.config/systemd/user/javs‑starter.timer с OnBootSec=1min и OnUnitActiveSec=1h регулярно «дёргает» сервис — через минуту после загрузки и далее раз в час.
• XDG Autostart (T1547.013). Файл /home/user/.config/autostart/javs.desktop, замаскированный под службу Java.

Записи XDG Autostart используют .desktop‑файлы, чтобы запускать приложения при входе пользователя в графическую среду. Но на этой облачной виртуальной машине нет Display Manager, а при входе по SSH скрипты настройки графической сессии не запускаются — то есть закрепление на этом хосте физически не могло сработать. Развёртывание «полного набора закреплений из учебника» без привязки к реальной среде — это поведение шаблона, применяемого без рассуждения о контексте.

«Слишком чистый» и самоописывающий код

В автоматизированных атаках мы регулярно встречаем Bash‑ и Python‑скрипты с подробными пояснительными комментариями, аккуратной обработкой ошибок и понятными именами переменных — нетипичными для «человеческого» вредоносного ПО. Опечатка сейчас играет решающую роль в определении того, кто стоит за атакой: оператор в виде человека или оператор в виде ИИ‑агента. Все признаки — поведенческие и стилистические, а не сигнатурные: детект смещается в сторону поведения.

Три измерения «глубины ИИ»

Чтобы оценить, насколько глубоко ИИ встроен в конкретную атаку, удобно смотреть на три независимых измерения — каждое можно «прокачивать» отдельно, и именно их сочетание определяет опасность кейса:

• Ускорение. Написание эксплойтов, обфускация, генерация фишинга занимают минуты или часы, при этом разница от квалификации исполнителя практически исчезает.
• Оркестрация. ИИ не просто выполняет отдельные шаги, а связывает их в цепочку: разведка → эксплуатация → закрепление → горизонтальное перемещение → эксфильтрация. Ключевую роль играет обвязка вокруг модели: агентный цикл, доступ к инструментам, память и применение контекста на разных шагах.
• Самостоятельность. Доля решений, которые ИИ принимает без человека. Пройден путь от «подскажи команду» до «сам определи, что делать дальше, и сделай». Оператор подключается лишь в критических точках.

Наш кейс с закреплениями — это как раз проявление оркестрации и самостоятельности при нулевом понимании контекста: агент отработал по шаблону, не рассуждая о среде.

Масштаб ИИ‑атак

То, что мы видим в отдельных расследованиях, на больших числах подтверждает Anthropic. Их годовая аналитика по злоупотреблениям Claude показывает:

• 832 заблокированных аккаунта;
• 13 873 наблюдаемых действия;
• 482 уникальные техники;
• задействованы все 14 тактик MITRE ATT&CK^®;
• медианный злоумышленник использовал 16 различных техник;
• 80% использовали именно Claude Code — то есть агентный, а не «чатовый» интерфейс.

Важнее динамики — сдвиг в сторону более рискованных действий. Большинство пока применяет ИИ на подготовительных этапах (разработка вредоносного кода, обфускация, обход обнаружения), но акторы с самым высоким уровнем риска всё чаще задействуют модель и внутри скомпрометированной сети.

Сдвиг выражается в следующих процентах:

• Account Discovery: +8,9%;
• Automated Exfiltration: +6,2%;
• Develop Capabilities: −12%;
• Phishing: −8,6%.

При этом доля злоумышленников среднего и высокого риска за год выросла с 33,5 до 56,1% — без роста квалификации самих атакующих. Разделительная линия между «шумным скрипт‑кидди» и по‑настоящему опасным актором сместилась с технического навыка на оркестрацию и самостоятельность: опаснее становится не тот, кто больше умеет, а тот, кто лучше собрал обвязку вокруг модели.

ИИ как живой компонент «вредоноса»

Ускорение и оркестрация описывают, как ИИ помогает создать и провести атаку. Но появился и другой режим (в копилку самостоятельности): ИИ становится живым компонентом самого «вредоноса» — тот обращается к модели уже во время исполнения, на стороне жертвы.

Примеры:

• Семейства PROMPTFLUX и PROMPTSTEAL (разобранные Google) опрашивают модель прямо во время работы.
• На Android появился PromptSpy — первый известный мобильный «вредонос», вызывающий Gemini во время выполнения.
• Стилер QUIETVAULT на скомпрометированной машине ищет установленные ИИ‑CLI и прогоняет через них заранее заданные промпты (например, чтобы найти конфиги и секреты).

Для защитника это смещает точку детекта: признаком компрометации становятся не только подозрительные «бинарники», но и исходящие обращения к LLM‑API из неожиданных процессов и вызовы локальных ИИ‑CLI там, где их быть не должно.

Битва за ИИ‑слой

Раз ИИ теперь стоит по обе стороны — и внутри «вредоноса», и в конвейере анализа у защитника, — сама модель становится и целью, и оружием. Через промпт‑инъекции у обеих сторон появляется симметричная возможность.

Со стороны атаки задача — ослепить защитную модель. Образец Skynet (Check Point Research) содержал специально подготовленный промпт с требованием проигнорировать его анализ. Инъекции живут и в Office‑макросах, и в фишинге, а свежий macOS‑вредонос Gaslight (2026) прячет десятки поддельных «системных» сообщений, чтобы агент‑анализатор прервал разбор.

Со стороны защиты логика зеркальная: раз атакующий агент читает вывод инструментов, баннеры и файлы, защитник может заранее разместить в своей среде инструкции и ловушки, нацеленные не на человека, а на вражескую модель, — «строго запрещающие» промпты и honeypot для LLM.

Переходный период и асимметрия

И защитники, и злоумышленники сейчас в переходном периоде: нужно понять, какие старые методы можно улучшить, а какие инструменты имеет смысл создавать с нуля. Anthropic считает, что в долгосрочной перспективе такие инструменты выгоднее защитникам, но краткосрочно период играет на атакующих.

Причины две:

• Фундаментальная асимметрия в требованиях к ИИ у двух сторон.
• Защита по объективным причинам внедряет ИИ осторожнее.

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

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

Тем не менее «синие команды» активно и осмысленно используют ИИ там, где цена ошибки управляема:

• в SOC — обогащение и нормализация событий, первичный триаж и приоритизация алертов, суммаризация инцидентов, поиск индикаторов компрометации, написание и отладка детектов;
• в AppSec — помощь в код-ревью, поиск уязвимых паттернов и логических ошибок, первичный триаж отчётов.

ИИ берёт на себя объёмную рутину, ускоряет защитников и помогает оркестрировать задачи вплоть до расследования, но финальное решение и ответственность остаются за человеком. Пока в защите ИИ раскрывается не как автономный «охотник за уязвимостями» и не как «ты senior‑пентестер с многолетним опытом», а как усилитель рутины под контролем человека — и именно эта разница во многом определяет текущее преимущество атакующей стороны.

Масштабы рисков в современной разработке

При создании программных продуктов риски безопасности могут возникать в трёх областях:

• в сторонних компонентах, которые используются в проекте;
• в собственном программном коде;
• в конфиденциальных данных, случайно добавленных в репозиторий.

Дальше расскажем о каждой подробнее.

Уязвимости в сторонних компонентах

На платформе для командной разработки SourceCraft встроенный модуль композиционного анализа (SCA) выявил 92 048 уникальных уязвимостей в сторонних компонентах, которые разработчики используют в своих проектах. Из них 2702 имеют критический уровень серьёзности — это потенциальные «окна возможностей» для злоумышленников, если авторы проектов не обновят используемые версии уязвимых библиотек до безопасных версий.

Уязвимости в собственном исходе коде

С помощью статического анализа кода (SAST) SourceCraft выявила 56 313 потенциальных дефектов и уязвимостей в проектах. Из них 4099 получили критический уровень серьёзности и требуют первоочередного внимания.

Риск публикации конфиденциальных данных в коде

Не менее острой остаётся проблема случайной публикации конфиденциальных данных в исходном коде — например, паролей и ключей доступа. Такие данные могут оказаться в репозитории вместе с новыми фрагментами кода или файлами настроек — к примеру, если их временно используют для тестирования и не удаляют перед добавлением изменений в проект.

Подобные данные могут открыть злоумышленникам доступ к корпоративным системам и сервисам. Платформа SourceCraft обнаружила 6356 таких секретов в коде репозиториев. Кроме того, на этапе проверки новых фрагментов и правок в программном коде, до их включения в основную версию проекта, система безопасности SourceCraft выявила еще 514 секретов и своевременно предупредила разработчиков.

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

Если их не обнаружить вовремя, они могут попасть в готовый продукт и создать возможности для кибератак. Чтобы снижать эти риски до того, как новая версия продукта станет доступна внешним пользователям, важно использовать автоматические проверки на всех этапах разработки: SCA — для контроля сторонних компонентов, SAST — для проверки собственного кода.

Именно поэтому интеграция инструментов анализа (SCA/SAST) в CI/CD-пайплайны и политика запрета коммитов с секретами — это не опциональная мера, а обязательный элемент защиты от атак на цепочки поставок.