ТОП-5 — часть 2

Топ-3 новых техник внедрения кода в процессы Windows

Шаих Галиев
Руководитель отдела экспертизы PT Sandbox, Positive Technologies

Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Авторы не несут ответственности за использование опубликованной информации.

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

Разумеется, средства защиты стараются обнаруживать подобные приемы и предотвращать их вредоносное воздействие. Но хакеры постоянно придумывают новые трюки. И обнаружить их проблематично без глубокого поведенческого анализа, который будет осуществляться либо на конечном устройстве во время непосредственной работы ВПО, либо до попадания на конечные устройства в виртуализированной среде (в песочнице для защиты от вредоносов). 

Далее я опишу некоторые из техник, которые показались мне свежими и актуальными.

Инъекция LoadLibrary без записи в процесс

Типичный флоу внедрения кода в процессы строится по правилу 1-2-3:

1. Выделение памяти в целевом процессе (Remote allocation).
2. Запись в память целевого процесса (Remote write).
3. Исполнение того, что реализовано в ходе 1 и 2 (Remote execution).

Соответственно, детектирующая логика средств защиты также строится на детекте последовательности шагов 1-2-3 или по правилу 2 из 3. Для динамической подгрузки библиотеки обычно используется функция LoadLibraryA и ее производные. Первый и единственный аргумент этой функции — имя библиотеки. Причем не обязательно указывать расширение .dll, функция сама его добавит. Соответственно, в классическом исполнении техники LoadLibrary Injection малварь бы:

1. Выделила память.
2. Записала туда имя своей библиотеки, предварительно положив ее в путь, который резолвится виндой при поиске библиотек.
3. Подгрузила библиотеку с помощью функции CreateRemoteThread, передав ей адрес функции LoadLibraryA с указателем на записанное имя библиотеки. 

Но, воистину, девиз техники Pointer-only LoadLibrary Injection — «Все гениальное просто!» Вместо того, чтобы выделять и записывать память в целевом процессе, исследователи Friends & Security придумали найти в загруженной библиотеке ntdll.dll какую-нибудь строку, оканчивающуюся на «0», и пропустить шаги 1 и 2, перейдя сразу к подгрузке библиотеки. Поскольку ntdll.dll загружается во все процессы по одному и тому же адресу, можно просто найти нужную строку в своем процессе (за внутрипроцессные трюки средства защиты ничего не сделают) и затем переиспользовать ее адрес при удаленной подгрузке библиотеки!

Данная техника проста как две копейки, поэтому работает и на самой актуальной винде (см. рис. 1).

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

Инъекция через ShimEngine без удаленного вызова кода

Endpoint-решения часто внедряют в процессы свои библиотеки для перехвата API-вызовов на уровне пользовательского пространства. Такой метод хостового мониторинга особенно актуален после инцидента с CrowdStrike в 2024 г., когда ошибка в ядерном модуле СЗИ привела к масштабному сбою более 8 млн устройств по всему свету. Соответственно, если хакер захочет осуществить технику внедрения в уже созданный процесс защищенного устройства, то, скорее всего, малварь попадет под пристальное внимание EDR. 

Чтобы избежать этого, злоумышленники могут в том числе создать новый остановленный процесс и попытаться ослепить мониторинг EDR, внедряя код до того, как EDR внедрит свой. В общую копилку подобных техник исследователи Outflank предложили еще одну — Early Cascade Injection. Ее можно описать следующей последовательностью действий:

1. Создание нового процесса в остановленном состоянии (dwCreationFlags |= CREATE_SUSPENDED).
2. Выделение памяти и запись двухкомпонентного шелл-кода в процесс.
3. Поиск особых глобальных переменных g_ShimsEnabled и g_pfnSE_DllLoaded в памяти ntdll.dll целевого процесса.
4. Модификация переменных: g_ShimsEnabled=1 и g_pfnSE_DllLoaded=<адрес пейлоада>.
5. Возобновление процесса.

Но как выполняется записанный злоумышленником код? Переменная g_ShimsEnabled отвечает за активацию режима ShimEngine (это код, ответственный за слой совместимости для запуска старых приложений на новых версиях Windows). В ходе выполнения техники вредонос может включить этот слой и указать в качестве адреса его процедуры свой вредоносный код. Управление из этой процедуры должно быть возвращено обратно в функцию инициализации программы, поэтому шелл-код состоит из двух компонентов: заглушки и основного кода. Заглушка нужна лишь для того, чтобы корректно продолжить выполнение программы и добавить основной пейлоад в очередь на исполнение через APC. Ее код может выглядеть следующим образом (см. рис. 2).

Благодаря этому трюку малвари не нужно вызывать NtQueueApcThread и в целом инициировать выполнение какого-либо кода удаленно — система сама все сделает! И это позволяет нарушить цепочку детектирования 1-2-3, о которой я писал выше. Тут реализован PoC данной техники.

Инъекция в защищенные PPL-процессы через уязвимости COM-объектов

В предыдущих техниках инъекции, несмотря на разрыв правила 1-2-3, все равно осуществляется непосредственное взаимодействие с процессом, в который внедряется код. Но что делать, если целевой процесс защищен от подобных взаимодействий? Такое актуально, например, для процессов, защищенных с помощью технологии PPL (Protected Processes Light), — это могут быть критически важные с точки зрения безопасности процессы LSASS или процессы AV/EDR-решений. Как правило, для обхода жестко установленных границ безопасности в ОС злоумышленники используют различные уязвимости. 

Исследователи обнаружили способ внедрения кода через уязвимости в межпроцессном взаимодействии посредством COM. Для эксплуатации необходимо предварительно внести изменения в реестр Windows:

1. HKLM\\SOFTWARE\\Microsoft\\.NETFramework\\AllowDCOMReflection = 1 — включаем DCOM Reflection, позволяющую вызов .NET-объектов из COM.
2. HKLM\\SOFTWARE\\Microsoft\\.NETFramework\\OnlyUseLatestCLR = 1 — активируем новые мажорные версии .NET (v2 или v4 в зависимости от ОС).
3. HKCR\\<CLSID_StdFont>\\TreatAs = <CLSID_DotNetObject>, где <CLSID_StdFont>==0be35203-8f91-11ce-9de3-00aa004bb851 (ID старого COM-класса), а < CLSID_DotNetObject >==81c5fe01-027c-3e1c-98d5-da9c9862aa21 (ID нового класса .NET System.Object), — активируем перенаправление старого COM-класса, чтобы к нему можно было обращаться как к .NET-сущности (для активации этой опции нужно изменить реестр с правами TrustedInstaller).

Благодаря этим изменениям можно соединить миры COM и .NET. В эксплойте в качестве целевого COM-объекта выбран WaaSRemediationAgent (72566e27-1abb-4eb3-b4f0eb431cb1cb32) — он используется в процессе Windows Update Medic Service, который запускается с помощью svchost.exe (см. рис. 3).

Схема работы эксплойта:

1. Создаем COM-объект WaaSRemediationAgent с помощью CoCreateInstance.
2. Получаем интерфейс ITypeInfo с помощью метода GetTypeInfo.
3. Получаем нулевой интерфейс IDispatch с помощью метода GetRefTypeOfImplType.
4. Получаем указатель ITypeLib с помощью метода GetContainingTypeLib.
5. Получаем тип ITypeInfo класса StdFont по GUID через метод GetTypeInfoOfGuid.

Посредством выполнения этой цепочки мы получили доступ к классу StdFont и можем создать его экземпляр с помощью метода CreateInstance, что приведет к созданию .NET-объекта. К нему уже можно подключать вредоносные сборки .NET с применением характерных динамических методов и инициировать их исполнение. Ввиду того, что модуль подгружается динамически, к нему не применяется проверка подписи. В исследовании описано, как это позволило сдампить память LSASS в рамках PoC. Там же приведена возможная логика детектирования такой техники.

***

Как видно из моего топа, несмотря на закручивание гаек, злоумышленники все еще находят и используют различные бреши в защите Windows. Подобные трюки, как правило, невозможно обнаружить статическими сигнатурными механизмами. Eсли хотите найти их до запуска в вашей ОС, необходим глубокий поведенческий анализ в виртуализированном окружении. Автоматически провести такой анализ и заблокировать хитрое ВПО помогут специализированные песочницы. 

Топ-5 трендов в защите электронной почты

Шаих Галиев
Руководитель отдела экспертизы PT Sandbox, Positive Technologies

Федор Гришаев
Ведущий специалист группы исследования фишинговых угроз, Positive Technologies

Александр Матвиенко
Эксперт отдела развития и продвижения инженерно-технической экспертизы, Positive Technologies

Импортозамес

Причины тренда на импортозамещение почтовых сервисов в России понятны, но его последствия для ИБ не всегда очевидны. С одной стороны, полезна независимость от эпидемий, охватывающих всю почтовую инфраструктуру в мире при очередном вскрытии новой уязвимости в популярном зарубежном продукте. В одной из исследованных нами кибератак злоумышленники воспользовались уязвимостями MS Exchange, которые позволили им с помощью одной команды отправить ссылку на ВПО в ответ на десять последних писем в папке Входящие. С другой стороны, зарубежные почтовые сервисы представляют собой целые «комбайны» с огромным количеством возможностей, в том числе по защите. 

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

Требования к экспертизе защитных инструментов возрастают — точечные «навесные» решения уступают место экосистемному подходу.

Экосистемность

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

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

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

Новые способы маскировки

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

Классические защитные системы могут пропускать новые угрозы. Несколько примеров:

• QR-коды с вредоносными URL-ссылками. Для жертвы переход осуществляется в один клик, а для средств защиты угроза невидима. 
• HTML-вложения с различными техниками открытия вредоносного веб-контента, взаимодействия с ним и отправки сведений на сторонние серверы. 
• Нетипичные файлы во вложениях. В одном из прошлых выпусков мы описывали эволюцию таких атак.
• Многоэтапные нагрузки. В письме безвредный документ, в документе — ссылка на зашифрованный архив, в архиве — загрузчик ВПО. Получается своеобразная «матрешка». 

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

Мобильная почта — низко висящий фрукт

Корпоративный мир перешел на мобильную электронную почту, но безопасность этого канала до сих пор остается «тенью» десктопных решений. Этому способствует и практика BYOD (Bring Your Own Device), когда сотрудники используют собственные устройства для работы. Фишинговые веб-страницы также адаптируются под мобильную платформу — например, используют большие кликабельные элементы, упрощая обман пользователя. Это ставит перед ИБ дополнительные цели:

• Защитить почтовые учетные записи от перехвата по незащищенным каналам вроде публичных Wi-Fi-сетей.
• Научить коллег распознавать мошенническую активность за рамками электронной почты.
• Использовать дополнительные средства защиты, минимизирующие ущерб от компрометации устройств, — например, удаленно очищать утерянные устройства. С этим помогут решения класса Mobile Device Management (MDM). Не помешает и убедиться в том, что уже используемые средства защиты учитывают мобильный вектор.

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

Использование искусственного интеллекта

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

• Стилистические аномалии — неестественные для деловой переписки фразы (например, «Дорогой коллега, немедленно подтвердите доступ!»).
• Эмоциональный окрас — попытки создать искусственную срочность (например, «Откройте вложение в ближайшие 24 часа!»).
• Контекстные несоответствия — если «директор» просит перевести деньги, но его обычные письма всегда начинаются с «Доброго времени суток!».

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

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

Топ-5 трендов в фишинговых атаках 

Валерия Беседина
Аналитик направления аналитических исследований, Positive Technologies

Обход средств защиты

С развитием средств защиты атакующим приходится тратить все больше времени и сил на преодоление «киберщитов». Например, для обхода автоматизированных проверок вредоносных сайтов киберпреступники добавляют в тесты CAPTCHA, а для избегания исследования ссылок в письмах используют технику URL Rewriting. Также атакующие применяют типы вложений (офисные документы, pdf-файлы и веб-страницы), которые чаще доходят до конечного пользователя и реже детектируются различными средствами защиты.

ИИ в фишинге

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

Многоканальные атаки

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

Легитимные сервисы как оружие злоумышленников

Хакеры стали все чаще использовать доверенные сервисы, такие как OneDrive и Google Drive, для распространения фишингового контента. Это позволяет убить двух зайцев: обойти фильтрацию и не вызвать подозрений у пользователя.

PhaaS

Развитие рынка даркнета повлияло и на фишинг: доступ к инфраструктуре компаний стал товаром, который могут получить даже неквалифицированные злоумышленники. Если раньше фишинговые атаки требовали времени и сил, то сейчас эту проблему решили платформы PhaaS (Phishing-as-a-Service). И цена не кусается: стоимость готовых фишинговых проектов начинается от $10.

Топ-5 ставок в AppSec на 2026 год

Светлана Газизова
Директор по построению процессов DevSecOps, Positive Technologies

В этом выпуске много топ-5... А я решила, что под Новый год классно подумать о том, что нас ждет дальше. Вообще вторая половина года — это время, когда ты не только осмысляешь уже прожитый период, но и пытаешься предугадать, с чем тебе предстоит столкнуться в новом году. Когда-то (кажется, в 2023-м) я такое упражнение уже делала и пыталась составить свой чек-лист будущих трендов. Сегодня же подумалось, что слово «тренды» немного пошлое для такой важной области, как безопасная разработка, поэтому моя статья будет про... пять ставок на 2026 г. ALL IN, как говорится! Поехали :) 

1. Повсеместная интеграция ИИ в процессы безопасной разработки

В 2025 г. мы наблюдали резкий рост внедрения ИИ-инструментов в процессы разработки, в том числе в области безопасности. В следующем году это станет де-факто стандартом: от код-ревью до эксплуатации. Если ранее модели использовались точечно (например, для генерации кода или подсказок), то теперь они занимают критически важное место в системной автоматизации безопасной разработки. Что же мы увидим? Давайте представим, что можем заглянуть в будущее (хотя бы на время прочтения этой статьи).

1. Предиктивная оценка рисков в pull-request'ах. Модели будут анализировать кодовые изменения в момент риск-оценки PR (Risk Score) и:
   • сопоставлять их с ранее известными уязвимыми паттернами (например, небезопасное использование eval, SQL без параметризации и др.);
   • учитывать контекст: где используется код, кто автор, какова история изменений в файле;
   • вычислять риск-оценку PR с подсказками и ссылками на безопасные альтернативы.

Например, если в PR появляется подключение к стороннему API без валидации ответа, ассистент может оценить это как потенциальную угрозу SSRF или DoS. Соответственно, время на разбор таких файндингов будет снижаться.

2. Генерация патчей и ремедиаций. ИИ-инструменты уже сейчас способны:
   • находить уязвимость (например, небезопасный YAML-парсинг);
   • предлагать безопасный фикс, опираясь на лучшие практики и CVE-базы;
   • учитывать стиль проекта, версию библиотеки и зависимости.

Системы вроде GitHub Copilot активно развивают этот вектор. Многие компании уже запускают собственные LLM-модели, зафайнтюненные на безопасных паттернах, как часть внутреннего DevSecOps-контура.

3. Выявление zero-day-уязвимостей по поведенческим паттернам. ИИ-движки теперь работают не только по сигнатурам, но и по динамике поведения:
   • отслеживают, как изменяется взаимодействие компонентов;
   • ищут аномалии и зависимости в структуре кода;
   • сравнивают код с похожими проектами open source, в которых ранее находили zero-day.

4. Создание адаптивной политики контроля доступа. ИИ позволяет автоматизировать управление доступом на основе:

   • поведения пользователей (behavior-based access);
   • контекста (время, география, тип запроса);
   • истории использования ресурсов.

   В рамках безопасной разработки это означает:

   • временные (ephemeral) доступы к CI/CD-секретам;
   • автоматическое ограничение прав на деплой при подозрительной активности;
   • динамическую верификацию инфраструктурных скриптов и Terraform-модулей.
5. ИИ-ассистенты на всех фазах цикла разработки. ИИ проникает на каждый этап:
   • архитектура и планирование: автоматическая генерация threat model и abuse case'ов;
   • написание кода: реалтайм-подсказки по безопасной реализации;
   • тестирование: fuzzing, SAST, DAST и иже с ними с ML-анализом false positive/negative;
   • деплой: анализ manifest'ов, Helm-чартов, Dockerfile на безопасность;
   • мониторинг: корреляция событий, предиктивное выявление атак.

Звучит прекрасно, ведь теперь три когорты, на которых базируется безопасность приложений, будут получать кучу плюшек! 

Разработчики получат ИИ-наставника, который снижает барьер входа в secure coding, — кажется, это и есть тот самый security champion, но теперь он чуть более бездушный, чем раньше.

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

Менеджмент получит метрики безопасности в реальном времени и прозрачность процессов — можно даже настроить, чтобы все это «проливалось» куда-то в BI-управления.

Однако мы не можем не учитывать, что управление ассистентами и принятием решений с помощью моделей — все еще наша с вами задача. Точность такой обработки зависит от того, что вы подаете на вход для обучения и как его контролируете. В общем, AI в безопасной разработке — это хорошо, но натуральный интеллект тоже не забываем использовать :)

2. Переход от AppSec к Product Security: что это и почему так произойдет?

До недавнего времени AppSec рассматривалась как вспомогательная функция: инженеры безопасности подключались к разработке на этапе код-ревью или перед релизом, проводили сканирование и выдавали рекомендации. Однако к 2025 г. все больше организаций осознают, что такой подход не только устарел, но и недостаточно зрел для современных цифровых продуктов.

На смену AppSec приходит Product Security (ProdSec) — интегрированная модель, в которой безопасность является не «блоком контроля», а неотъемлемой частью продукта, архитектуры, фич и пользовательского опыта. Ключевое отличие ProdSec от классического AppSec можно описать одним словом — бизнес. ProdSec — это не про приложение. Это про бизнес, продукт целиком, пользовательский опыт и приоритизацию.

Чтобы трансформировать AppSec в ProdSec, вам придется:

1. Выйти за пределы кода и понятия «приложение». Нужно понимать: бизнес-логику и бизнес-ценность, цели продукта и пользовательские потоки, а также знать нюансы атак на функционал, а не фокусироваться только на эксплуатации уязвимостей в коде.
2. Вовлекаться в discovery-фазу: новые фичи — это не только «как это сделать», но и «как это может быть проэксплуатировано».
3. Разговаривать с продуктовой и UX-командами: давать оценку, как безопасность влияет на пользовательский опыт, и помогать балансировать между удобством и удовлетворенностью защитой.
4. Стать невидимой частью цикла разработки. То есть вместо централизованных сканирований на реперных точках работать в стиле embedded security: присутствовать в команде как security partner (помните, выше мы говорили, что могут быть полноценные AI-ассистенты).
5. Обеспечивать Security-as-a-Feature: предлагать фичи, которые добавляют конкурентное преимущество за счет доверия пользователей (например, self-destruct-данные и кастомные функции ИБ).

ProdSec — это не подход к обеспечению безопасности в приложении и не шильдик над продуктом, а часть его ДНК. Переход требует изменений в процессах, ответственности, коммуникации и мышлении. Но, как и с DevOps, результат — это ускорение разработки, снижение инцидентов и рост доверия к продукту. Все про деньги и бизнес — то есть про все те благие цели, что нам нужны и важны :) 

3. Автоматическое исправление уязвимостей без остановки сервисов — как в Chaos Engineering

Один из самых прорывных трендов 2026 г. — это автоматизированная ремедиация уязвимостей без даунтайма, по аналогии с подходами Chaos Engineering. Если раньше устранение уязвимостей требовало остановки или перезапуска сервисов, то теперь возможно динамическое (hotfix) обновление кода и конфигурации без нарушения доступности.

DevOps + Chaos Engineering

Chaos Engineering научил индустрию проверять надежность систем в условиях отказов и изменений на боевом окружении. Теперь этот принцип применим и в безопасности: системы смогут динамически заменять уязвимые компоненты, библиотечные зависимости или конфигурации, и это будет происходить в рантайм (без ручного вмешательства и остановки сервиса). Современные CI/CD и сервисные mesh-платформы + контейнерная инфра дают возможности для обнаружения уязвимости, разработки безопасной и плавной замены в рантайм и анализа поведения после замены.

Роль искусственного интеллекта в таком подходе будет заметной и важной (ну вот, опять мы про него заговорили):

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

Безопасность ≠ стабильность ценой доступности.

В таком подходе мы делаем безопасность неблокирующей основой качественного продукта. Основная философия подхода такая же, как когда-то было с DevSecOps, — fix fast, stay up. Дословно: чинись и не падай (видимо, духом). Бизнес отказывается от практики «исправим потом когда-нибудь... когда взломают». Вместо этого он выбирает фиксить уязвимость за пару минут/часов, и это, кстати, превращается в Continious Security Remediation, то есть в непрерывную безопасность.

4. Достигаторство. Шутка! Достижимость

Если в 2020–2023 гг. безопасность цепочек поставок ограничивалась генерацией SBOM (Software Bill of Materials) и базовой проверкой зависимостей, то к концу 2025 г. и в 2026 г. подход кардинально меняется. Теперь важно не просто знать, что уязвимо, а понимать, что реально эксплуатируемо в контексте приложения.

AS IS

• Проверка зависимостей на наличие CVE (обычный родной SCA).
• Генерация SBOM-файлов (по требованию заказчиков/регуляторов или просто чтобы было).
• Полуавтоматическая верификация лицензий и политик.

TO BE

• Reachability Analysis: анализирует, используется ли уязвимая часть кода в реальности.
• Runtime-корреляция: сопоставляет SCA и телеметрию (трассировка, логи).
• Верификация путей эксплуатации: анализ цепочки вызовов к потенциально уязвимой функции.
• Полная интеграция с CI/CD и никаких ручных запусков.

Д — достижимость

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

• Меньше false positive — не нужно тратить время на мертвые CVE.
• Быстрая приоритизация патчей — внимание только на те уязвимости, которые могут быть реально использованы.
• Контекстная безопасность — риск теперь считается не глобально, а в контексте приложения.

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

А как выглядит идеальная картинка Supply Chain в рамках безопасной разработки?

1. SBOM с подписанными артефактами.
2. Контекстный SCA с Reachability.
3. Runtime-наблюдение и корреляция.
4. Policy-as-code для управления зависимостями.
5. Автоматизированные pull request'ы на безопасную версию.

5. Безопасность LLM-ориентированной разработки — это не просто апишка, а целый вектор атак

Помимо того, что угрозы могут быть неспецифическими для LLM (окружение и процесс деплоя), основной пласт незнания нам создают специфические угрозы (подробнее — в нашей статье):

1. Prompt Injection.
2. Утечка данных.
3. Небезопасный вызов функций / удаленное выполнение кода.
4. Галлюцинации.
5. Авторизация через LLM и обход RBAC и прочих. 

Что же мы увидим в следующем году? 

1. Специфическое моделирование угроз под LLM — такие модели точно будут в общем доступе, и мы заметим рост их популярности.
2. Контроль и фильтрация запросов и ответов. Чувствую, что в следующем году будет повышенный интерес к файрволингу запросов и ответов модели, причем это будет выглядеть как Next Generation Application Firewall (либо полноценный хайлоад-продукт). Сделать на коленочке не получится, поэтому наблюдаем и ждем новый класс инструментов.
3. LLM-specific-логирование и аудит: теперь журналы логов будут содержать все промпты и ответы, которые надо будет изучать, чистить и собирать заново.
4. Контроль доступа LLM. Полноценный анализ доступа к агентным системам и проверка доступов, SSO для чат-ботов и все такое. Кажется, будущее не за горами! Как и счастье, кстати :) 

Вот такой душевный и осмысленный топ-5 у меня получился :) Что вы видите как обязательное условие существования бизнеса, а что не уложилось в ваш личный топ?

Топ-5 хочу/могу в AppSec

Светлана Газизова
Директор по построению процессов DevSecOps, Positive Technologies

1. Хочу: полностью автоматизированный пайплайн безопасности с автофиксом, SBOM, runtime-мониторингом и политиками.
   
   Могу: перенести все файндинги на новую страничку excel.
2. Хочу: анализ достижимости уязвимостей в зависимостях и приоритизацию только реально эксплуатируемых из них.
   
   Могу: запретить команде использовать все библиотеки, которые не пролежали в репозитории две недели.
3. Хочу: выстроенный процесс в каждой команде. Threat modeling в начале разработки каждой значимой фичи и zero-trust во всех слоях.
   
   Могу: попросить не выкатывать релиз с RCE.
4. Хочу: LLM-ассистента, который обнаруживает уязвимости, пишет безопасный код и контролирует всю команду бесшовно.
   
   Могу: спросить у chatGPT: «Что делать, если команда разработки меня газлайтит?»
5. Хочу: чтобы разработчики сами писали нормальный код, проходили курсы и ставили security-патчи по выходным.
   
   Могу: попросить ребят не публиковать креды в Gitlab. Снова.