Makrushin

100+ CVE в день и эксплойт за $1 LLM уверенно генерируют рабочие эксплойты по описанию уязвимости из CVE и патчам. Редиске не нужно ничего реверсить. Достаточно настроить инструменты для определения диффа на основе патча и подготовить детальное описание баги. Так утверждают исследования, в которых описана экономика разработки эксплойтов с помощью ИИ. Где-то за $1, где-то за $2.77. Умножаем на 100+ новых CVE в день и получаем автоматизированный конвейер на стороне атакующего. Политика «патчим критичные баги за 7 дней» ушла в историю. Про 90 дней на исправление вообще стоит забыть. Почему это хорошая новость для security-инженера: ⚪️ закрытая кодовая база становится временным преимуществом для защиты ⚪️ дополнительная проверка находок от анализаторов является узким горлышком appsec-команды ⚪️ время реакции на уязвимости теперь измеряется минутами, не днями. К концу года будет измеряться секундами. Чтобы ускориться в исправлении проблем, не получится просто прикрутить LLM к существующим решениям. Нужно менять или строить заново архитектуру и процессы для agentic-систем. @makrushin l MAX l VK l Сетка l Дзен

91% находок «классического» SAST — ложные срабатывания. А еще AppSec-инженер тратит 10–20 минут на каждую находку, чтобы принять решение, нужно ли ее исправлять. Умножаем это время на количество находок и получаем дорогую команду для «ручной фильтрации». LLM меняют это уравнение. Передаем модели правильный контекст (например, трассу, критичность, commit hash), и снижаем время на принятие решения с минут до секунд. Ключевое слово: «правильный». Если контекста недостаточно, то модель галлюцинирует. Если его много, то расфокусируется, сжигает токены и несет в бэклог минорные находки вместо критических. Мы перебрали архитектурные подходы для интеграции ИИ в SAST, рассмотрели варианты оптимизации контекста, запилили фичу для ИИ-триажа находок и поделились результатами в статье. Еще определили ключевые метрики для оценки результата.

Провинциальный OSINT Давно не практиковались в определении мест по фоткам. В этот раз открыл на своей карте два новых города, похожих по атмосфере, а в одном из них нашел вот такую локацию с архитектурными контрастами. ⭐️ Задача со звездочкой: определить мероприятие, которое меня сюда привело, и точное место.

Впервые в истории отчетов об угрозах Verizon: вектор эксплуатации уязвимостей обогнал украденные учетки Ключевой инсайт из свежего отчета Verizon Data Breach Investigations Report, в котором аналитики собрали статистику по 22000 инцидентам в 145 странах:

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

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

Структурный сдвиг в подготовке атак: ИИ стал частью конвейера Утро понедельника, кофе и дайджест, в котором попался тренд: ИИ стал частью конвейера подготовки атак. GTIG выпустила отчёт, в котором впервые заметила в дикой природе 0day-эксплойт, полностью написанный с помощью ИИ. Открытый вопрос: как теперь проводить атрибуцию целевых атак, в которых всё меньше артефактов ручной работы? Ещё в феврале в своих отчётах аналитики Google замечали эксперименты APT-групп с LLM. Спустя три месяца зафиксировано внедрение ИИ в "промышленный" конвейер разработки малвари. Атакующие смогли автоматизировать пайплайн разработки эксплойтов, отправляя тысячи автоматизированных промптов для анализа CVE и разработки прототипов. Например, просили Gemini взять на себя роль "senior C/C++ binary security expert" для исследования прошивок устройств TP-Link и реализаций протокола передачи файлов OFTP. Разработчик, если ты ждал сигнал, чтобы наконец-то дать любимой нейронке свои проекты на уязвимости, то вот он: 🚨

Архитектура платформы для автоматизации SOC с помощью ИИ-агентов Всегда интересно прочитать истории, как LLM самостоятельно находит уязвимости в популярном продукте. Как крупные вендоры вроде Mozilla патчат 271 уязвимость, которую обнаружил Mythos. Или как ИИ-агент за 3 минуты без подсказок смог самостоятельно скомпрометировать облачную инфраструктуру. Среди подобных материалов часто остаются незаметны идеи, которые нужны специалистам по защите. На прошлой неделе бот закрыл этот пробел и принес исследование, которое будет интересно Blue Team. В статье описана архитектура системы ИИ-агентов для автоматизации работы центров мониторинга. Ключевую идею этой платформы можно описать одним словом: проактивность. Чтобы не ждать очередных пентестов и проверок Red Team, аналитики могут самостоятельно построить систему непрерывного прогнозирования и обновления детекторов. Ключевая особенность платформы AgentSOC заключается в движке анализа гипотез. Этот модуль отвечает за творческую часть, которая часто остается без внимания загруженного рутиной аналитика. В нем LLM строит ветки возможного развития атак на основе имеющегося контекста из систем мониторинга. Затем привязывает эти ветки к матрице атак MITRE. То есть система постоянно рассуждает над вопросом «что, если», присваивает ответу индекс уверенности и повторяет упражнение. Второй движок структурного моделирования выступает в роли критика и проверяет теоретические рассуждения модели на основе фактического состояния инфраструктуры. Графовая валиадация атак, проверка достижимости, фильтрация галлюцинаций — все это его задачи. В итоге, вся система работает в автономном цикле «Sense-Reason-Act» и выбирает наиболее подходящее действие для защиты менее чем за 1 секунду. @makrushin l MAX l VK l Сетка l Дзен

Сделали облачные регионы полностью изолированными, сохранили бесшовный пользовательский опыт работы с ними. Получили патент. Крупные облачные провайдеры работают на едином слое управления доступами. Это удобно, но при инциденте в одном регионе у атакующего есть возможность уползти в другие области. Изоляция является основным способом снижения этого риска. Поэтому мы сделали так, что каждый регион нашего облака — это теперь полностью автономная инсталляция со своей базой доступов. При этом у пользователя остается опыт работы в единой облачной платформе. В основе этой архитектуры находится «теневая организация» — копия основной организации пользователя и ее облачного кабинета, которая создается в новом регионе. Все пользователи, группы, политики организации автоматически реплицируются из основного региона в теневой. Это избавляет пользователя от необходимости переносить свои настройки и ресурсы в новую область. При этом, компрометация теневого региона не позволяет атакующему дотянуться до основной организации. О том, как построено доверие между регионами и бесшовное переключение между кабинетами без повторного логина рассказали в блоге. @makrushin l MAX l VK l Сетка l Дзен

Разбираем топ-10 атак на приложения и делаем выводы для разработки Атаки на современные приложения всё реже возникают из-за одной ошибки в коде. В многокомпонентном софте появляется новый уязвимый слой: взаимодействие между компонентами. Ruby видит одно, Go видит другое и в результате злоумышленник протаскивает свой запрос мимо обоих. Серверный и клиентский кэш становятся каналом утечки секретов, а ошибки сервера — каналом связи злодея с внутренней инфраструктурой приложения. На основе рейтинга нетривиальных атак выделил основные категории уязвимостей, с которыми сталкивается разработчик (особенно, вайбкодер), и дал сценарии защиты с помощью привычных и пока ещё эффективных инструментов. @makrushin l MAX l VK l Сетка l Дзен

Наблюдаем технологические тренды через портфели фондов Каждый год слежу за RSAC Innovation Sandbox, чтобы проследить за трендами: какие категории проектов проходят отбор, кто из фондов "прикрывает" финалистов. В этом году 10 из 10 финалистов так или иначе связаны с ИИ. Победил Geordie AI с governance-платформой для ИИ-агентов. Но примечательным оказался не победитель, а конкретный фонд, который за ним стоит. Ten Eleven Ventures — это единственный фонд, у которого было сразу две портфельные компании среди финалистов. Его портфель тоже довольно интересный: пять инвестиций подряд и все в agentic-проекты. Еще интереснее, что в 2024 году на том же конкурсе победила другая компания из их портфеля, и её продукт тоже был про защиту учётных данных сервисных аккаунтов, ботов и AI-агентов. Врядли совпадение. Его сделки в 2026 году также дают интересный инсайт: защита non-human identities (NHI) превратилась в категорию с крупным капиталом. Похоже, что в индустрии образуется пять ключевых технологических слоев для построения стратегии безопасности ИИ: 1. Agent Discovery: прежде, чем что-либо защищать, нужно это сначала найти. Shadow AI стала проблемой в современном бизнесе, поэтому нужны технологии инветаризации. 2. Защита NHI: управление учетными данными ИИ-агентов становится новым слоем управления ИБ. 3. Runtime Observability & Behavioral Governance: мониторинг и управления всеми ИИ-системами и построение guardrails для всех систем с "недетерминированным" поведением. 4. Intent-Aware Data Security: так как ИИ-агенты постоянно и, на первый взгяд, легитимно перемещают данные в инфраструктуре, то требуется что-то вроде системы DLP нового поколения, которая понимает не только факт передачи данных, но и "намерение" ИИ-агента, который эти данные передает. 5. AI-Native SOC Automation. Вот сюда попадают все технологии, которые автоматизируют обнаружение и защиту от всех угроз. Область, которая трансформируется с космической скоростью по мере развития агентных систем. За эти тренды кто-то проголосовал своими деньгами, поэтому CISO может накатывать обновление в свою стратегию.

Обещал показать, как редиска крадёт секреты у разработчиков через их же ИИ-инструменты. Показал. На DevOps Conf представил результаты исследования «Атаки на ИИ-агентов», которое мы провели вместе с командой. Разобрали сценарии в ADLC (Agentic Development Lifecycle — запоминаем этот термин, будем встречать его всё чаще) и показали методы анализа устойчивости ИИ-инфраструктуры для тех, кто строит агентные системы. Ключевой тезис: SDLC трансформировался в ADLC, и классические подходы к безопасной разработке теряют эффективность. Поведение агента недетерминировано и меняется без изменения кода. Pull request — больше не чекпоинт, когда агент автономно читает тикеты, обрабатывает изменения и что-то меняет в коде. Видимость упала — скорость выросла. Что с этим делать: LLM-as-a-Judge, guardrails на входе и выходе, AI red teaming в CI/CD, аудит каждого подключённого MCP-сервера. И еще куча идей в в попросах из зала и дискуссиях после доклада. Показали. Теперь пора рассказать. Готовим блогпост.

Трудно собрать, легко потерять, часть 4: папка security-каналов Коллеги по индустрии, которые регулярно следят за новостями и исследованиями, снова собрались в одной папке, чтобы помочь экономить время на поиск и мониторинг ИБ-контента. Если задача — охватить разные аспекты кибербезопасности, от практических исследований до бизнеса и регуляторики, то эта папка быстро сформирует ленту. ⚡️

Давно не виделись. Нашел два повода для встречи. Завтра на продуктовой аллее DevOps Conf проведу питчинг SourceCraft и расскажу про ключевые обновления, которые позволят быстрее и безопаснее создавать новые продукты. Спойлер: релизим новые AppSec и ИИ-фичи. Послезавтра представлю результаты нового исследования — «Атаки на ИИ-агентов». Покажу, какие возможности есть у редиски, чтобы за несколько часов скомпрометировать тысячи разработчиков через их же ИИ-инструменты и украсть секреты с рабочих станций. Разберём поверхность атаки, а на выходе получим методику и инструменты для тех, кто строит агентные системы и хочет сделать их устойчивыми. Если будешь на площадке, то заходи в гости.

Смена парадигмы в security-продуктах Индустрия десятилетиями находилась в условиях жесткого конфликта между полнотой и точностью поиска угроз. Статические и динамические анализаторы, антивирусные движки, межсетевые экраны — каждый из этих продуктов стремится снизить количество ложных срабатываний. LLM могут разрешить это фундаментальное противоречие. На примере инструментов SAST, которые игнорировали потенциально опасные пути в потоке данных программы и не видели целые категории уязвимостей, авторы исследования показали, как за счет глубокого понимания контекста появилась возможно расширить полноту без потери точности. Теперь существуют три архитектурных подхода для создания AI-native продукта: ⭐️ AI-enhanced: фильтрация результатов и ложных срабатываний, чтобы снизить нагрузку на security-аналитика ⭐️ AI explorer: добавление ИИ-агента для генерации гипотез и управления исследованием, чтобы расширить анализ за счет новых правил поиска. ⭐️ AI native: полная автономность с «пониманием» бизнес-контекста, чтобы полностью исключить человеческий фактор из процесса. Эти архитектурные подходы также являются тремя этапами продуктовой эволюции. Эту эволюцию ограничивают три фактора: экономика операций, проблемы «личности» агента и неэффективный вызов инструментов. Широкий контекст для агента увеличивает стоимость его действий. Еще агент может решить, что какое-то событие «выглядит безопасно», и пропустить его из-за субъективной вероятности. Ну а попытки LLM вызвать внешние инструменты чаще оказываются дороже, чем использование классических правил. Авторы делают вывод, что наиболее перспективный метод использования LLM — это не анализ событий в реальном времени, а оптимизация существующих правил поиска угроз. Предложенная архитектура превращает SAST из инструмента «сопоставления куска кода с шаблоном» в инструмент для извлечения логически связанных участков кода. LLM управляет вниманием security-продукта, а индустрия движется от написания правил к проектированию цепочек рассуждений. 100% точности при трехкратком увеличении полноты - отличное тому подтверждение. @makrushin l MAX l VK l Сетка

Слепые зоны статанализа: применяем LLM для поиска новых уязвимостей Инструменты статанализа программы опираются на потоки данных: отслеживают источники данных (места, где пользователь может что-то внедрить) и приёмники (места, где введенные данные используются приложением). Известная проблема: классические инструменты анализа теряют след в потоке данных, когда используются специфические особенности языков программирования. Например, при многопоточности данные переходят из одного потока в другой, и таким образом анализатор теряется. А от использования механизмов рефлексии и динамического вызова методов статический анализатор вообще слепнет. Исследователи из Tencent решили эту проблему с помощью кастомного анализатора потоков данных и LLM. Кастомный анализатор давал что-то вроде шпаргалки, куда передаются данные и где они всплывают, чтобы поток не терялся. LLM искала источники и стоки данных, фильтровала мусор и классифицировала функции для исследователей. Хорошая идея, как можно улучшить свой анализатор, научить его видеть новые места в программе и в итоге, найти больше уязвимостей. @makrushin l MAX l VK l Сетка

Тренды и развитие киберугроз А вот свежий отчет по инцидентам от исследовательского подразделения Unit42 пересказывать не буду. В нем все очевидно: скорость атак увеличилась (72 минут на кражу данных в 2025 против 285 минут в 2024 - спасибо ИИ), поверхность атаки (браузер, почта) и методы атаки (эксплойты, фишинг) не изменились. Но есть одна примечательная деталь: в большинстве инцидентов путь внутрь инфраструктуры жертвы идет через атаки на identity (учетные записи, сессии, токены). С ростом популярности ИИ-агентов этот тренд усиливается за счет всяких “машинных” учеток, которые появляются в инфре в огромном количестве. Кто сейчас размышляет над своим проектом или кибербез-стартапом, стоит посмотреть в сторону защиты machine identity.

Куда идет рынок безопасности приложений Те, кто следит за развитием AppSec-продуктов и технологий, наверняка прочитают новый отчет. Оставлю ключевые инсайты: ✨ опыт разработчика становится приоритетом для всех AppSec-продуктов. Теперь решениям по безопасности важно интегрироваться со всеми инструментами, которыми пользуется разработчик. ✨ AI SAST — перспективный продукт, вызывающий наибольший интерес рынка в 2026 году. ✨ Проблема, которая становится более актуальной и все еще остается без решения: безопасность кода, сгенерированного с помощью ИИ. ✨ Базовая фича appsec-платформы в 2026 году — проверка уязвимостей в runtime-контексте. Тот самый подход code-to-cloud, о котором я писал пару лет назад, стал базой. ✨ Пользователю неважно, использует ли продукт собственный движок или является оберткой над опенсорс-инструментом. Важно качество правил и возможность их настройки под контекст приложения. ✨ В инструментах анализа зависимостей (SCA) акцент смещается с поиска уязвимостей на поиск малвари. @makrushin l MAX l VK

Трудно собрать, легко потерять: папка security-каналов. Часть 3. Коллеги по индустрии, которые регулярно следят за новостями и исследованиями, собрались в одной папке, чтобы помочь экономить время на поиск и мониторинг ИБ-контента. Если задача — охватить разные аспекты кибербезопасности, от практических исследований до бизнеса и регуляторики, то эта папка быстро сформирует ленту. ⚡️

Статический анализ, заряженный ИИ Несколько недель назад новость о выходе Claude Code Security хорошо встряхнула рынок кибербеза. Некоторые компании на этом рынке потеряли 20% своей капитализации. Думаю, что на это снижение в значительной степени повлияли торговые роботы на рынке акций. Тем не менее, CEO этих компаний успокаивали своих акционеров и журналистов комментариями в LinkedIn, а генеральный директор крупного appsec-вендора Snyk, несмотря на успехи в количестве клиентов и выручке, оставил свой пост с идеей, что его место в компании теперь должен занять AI-центричный лидер. Как заявляет Anthropic в своем анонсе, Claude Code Security сканирует кодовую базу на уязвимости и предлагает исправления для ревью человеком, позволяя командам находить и исправлять дефекты, которые классические методы часто пропускают. Проще говоря, Anthropic выпустил решение, которое претендует на замену статического анализатора безопасности - SAST. Традиционный статанализ основан на эвристиках и оценке структуры прграммы. Его слабая сторона: огромное число ложных срабатываний. В исследовательском подразделении Huawei Chong-Ming при разработке своего анализатора, мы постоянно боролись с количеством ошибок первого и второго рода и придумывали новые алгоритмы. Сегодня классические анализаторы не успевают за скоростью разработки и шумят неприоритетными находками. Вот здесь LLM принесли дополнительную ценность. Модель лучше понимает семантику кода, и это позволяет ей лучше находить уязвимости, связанные с бизнес-логикой. И пусть вероятностный результат модели (то есть, сегодня она видит уязвимость в кодовой базе, а завтра в этой же базе ничего не находит) не позволяет ей полностью заменить формальную верификацию, но свою нишу она точной займет в общем процессе безопасной разработки. На рыке формируется категория решений, которые не используют классику в виде сигнатур и правил, а опираются на интерпретацию кодовой базы с помощью LLM: AI SAST. Мы уже посмотрели на архитектуру открытого проекта из этой категории. Интересно еще детальнее взглянуть на другие решения в этом направлении и подглядеть, как они обходят ограничения традиционных подходов статанализа. @makrushin l MAX l VK

Новые каналы утечки в браузере: узнаем, куда и за чем ходит пользователь Злодей может по временным показателям понять, к каким ресурсам обращается браузер жертвы. Для этого ему не нужно эксплуатировать уязвимости на стороне веб-ресурсов.   Атака сложная в реализации, но интересная концептуально. Скрипт на странице атакующего специально забивает пул сетевых соединений в Chromium-браузере, затем в этом пуле провоцирует браузер сделать запрос к нужному ресурсу, например онлайн-банкингу. На основе того, какой запрос из этого пула получил соединение раньше, скрипт делает выводы. Например, выводы о привилегиях жертвы на этом сайте. Повторяя эти измерения, можно даже восстановить строку в URL, например, <secret_string123>.example.com Другое исследование из рейтинга тоже связано с новым каналом утечки в Chromium-браузерах, но уже с помощью HTTP-заголовка ETag (Entity Tag). Этот заголовок сервер отдает как идентификатор версии ресурса (например, страницы, файла, JSON и т. п. ). Чаще всего этот заголовок используется для кэширолвания: браузер может в следующий раз спросить “у меня уже есть такая версия ресурса, она не изменилась?” и не скачивать тело ответа повторно. Злодей заманивает браузер жертвы на свой ресурс со скриптом. Скрипт отправляет браузер к нужному ресурсу, например, онлайн-банкингу: https://target.site/?query=<секретная_строка_которая_может_быть_на_странице> Браузер получает ответ и сохраняет ETag. Затем скрипт меняет свой запрос, что приводит к изменению ETag. Перебирая такие запросы и отслежвая факты изменения ETag, злодей получает канал утечки ценной информации со страницы банка. Разработчик, не храни секреты и чувствительные данные в URL и особенно в субдоменах. Не отдавай ETag для страниц с ценными данными. @makrushin l MAX l VK