Архив метки: AI

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ. Т.е. использование ИИ для разработки эксплоитов на основе патчей и публичной информации об уязвимостях. Новую неизвестную уязвимость нужно ещё понять, где искать. А найдя, придумать вменяемый сценарий атаки с эксплуатацией этой уязвимости. Это работа на удачу, своего рода золотоискательство или, вспоминая Маяковского: "…та же добыча радия. В грамм добыча, в годы труды. Изводишь единого слова [уязвимости] ради тысячи тонн словесной руды [проверенного кода и неподтвердившихся гипотез эксплуатации]." Конечно, в случае использования ПО с открытым кодом задача анализа упрощается. Но всё равно найти что-то стоящее весьма непросто. Поэтому, кстати, я противник того, чтобы результаты этой добычи бесконтрольно утекали за рубеж.

Другое дело, когда уязвимость уже известная, с присвоенным CVE, вендорским описанием, признанной критичностью и выпущенным патчем. Тут задача серьёзно упрощается.

🔹 Понятно, где искать. Очевидно, там, где вендор исправляет что-то патчем.

🔹 Понятно, что нужно получить в результате. То, о чём вендор сообщил в описании уязвимости.

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

Естественно, этим занимаются не только исследователи watchTowr Labs. 😏 Тем более, что ИИ-агенты значительно упрощают процесс вепонизации, а то и полностью его автоматизируют. Как сообщает Денис Макрушин, стоимость автономной разработки эксплоита сейчас может составлять даже меньше 3 долларов. И ведь прогресс в ИИ пока не останавливается! Разработанные эксплойты могут выкладываться исследователями в паблик ради самопиара и общественного блага (ну, как они его себе видят), а могут и не выкладываться, а, например, продаваться на чёрном рынке. 😈 А затем эти эксплоиты будут использоваться в атаках на организации, пока их не спалят и факт эксплуатации уязвимости не станет подтверждённым. И всё это бесконечно повторяется для всё новых и новых уязвимостей. It's the circle of life and it moves us all…

Что вся эта движуха означает для простого VM'щика? Нарратив, который двигали многие VM-вендоры: "Патчьте только 3% уязвимостей, которые мы вам подсветим, а на остальные просто забейте", с самого начала выглядел булшитненько и безответственно, а в условиях ускорения и удешевления вепонизации n-day-уязвимостей и подавно. Аргументов, что любая уязвимость может внезапно выстрелить и привести к инциденту, значительно прибавилось. А значит, нужно стремиться к приоритизированному устранению всех уязвимостей, что создаёт значительную нагрузку на IT, особенно если IT-инфраструктура организации не была изначально рассчитана на непрерывную установку и тестирование обновлений безопасности. 🤷‍♂️ То, что VM-щик сможет запросто влиять на изменение инфраструктуры организации - сценарий более чем оптимистичный, на который не стоит всерьёз рассчитывать. Но агитировать за такие архитектурные изменения и стараться заводить задачи на устранение всех выявленных уязвимостей - святая обязанность VM-щика. Делай, что должен, и будь, что будет.

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире. Сама статья за paywall-ом, и мои комментарии там, вполне естественно и ожидаемо, были сильно сокращены, поэтому я приведу их здесь в развёрнутом виде.

Насколько адекватно делать выводы о динамике раскрытия уязвимостей, основываясь только на БДУ ФСТЭК России? (такую статистику привели коллеги из ЛК, привязав к ней анонс Kaspersky VM 😉)

Говоря о базе уязвимостей БДУ ФСТЭК России, важно учитывать, что она методологически не предназначена для учёта всех существующих уязвимостей: в неё включаются данные об уязвимостях отечественных продуктов, а также иностранных коммерческих и опенсорсных решений, применяемых в ГИС и на объектах КИИ. Поэтому БДУ не покрывает весь спектр уязвимостей, актуальных для российских инфраструктур, и её данных недостаточно для анализа глобальных трендов; для этого лучше использовать более полные источники, такие как PT DBugs или NIST NVD. Для визуализации статистики NVD удобно использовать дашборды, такие как CVE ICU. Текущие данные NVD показывают значительное увеличение скорости добавления новых CVE: за одинаковый период в 2025 году было зарегистрировано 22 041 уязвимость, а в 2026 году уже 31 917, что соответствует увеличению на 44,8%.

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

Что сейчас происходит с Vulnerability Management рынком?

Рынок Vulnerability Management в последние годы растёт как в России, так и в мире. В России важным фактором стал уход западных вендоров в 2022 году, что привело к появлению новых отечественных игроков. Внутренняя конкуренция стимулирует развитие функциональности решений, повышение качества детектирования, точности приоритизации и расширение интеграций с другими средствами защиты и ИТ-системами. Отдельно стоит отметить внимание ФСТЭК России к этой теме: разработка методических документов и требований способствует формированию более структурированного подхода к управлению уязвимостями.

Если смотреть ретроспективно, рынок Vulnerability Management прошёл путь от массового сканирования и детектирования CVE-уязвимостей к платформенному управлению защищённостью инфраструктуры. Полный и качественный поиск уязвимостей остаётся важной базовой функциональностью, однако сегодня всё больше учитывается контекст: критичность затронутых активов и возможность реальной компрометации через комбинацию выявленных уязвимостей. На Западе всё чаще говорят не о классическом Vulnerability Management, а о более широком подходе - Exposure Management или Continuous Threat Exposure Management (CTEM), где объектом управления становятся не только уязвимости с CVE/BDU-идентификаторами, но и уязвимости в широком смысле ("экспозиции"): ошибки конфигурации, проблемы с учётками, небезопасные настройки, избыточная сетевая связность активов и т.п. Обнаруженные проблемы используются CTEM-решениями для моделирования возможных путей развития атаки (attack paths), что позволяет выявлять и приводить в порядок наиболее проблемные участки инфраструктуры, повышая сложность и стоимость реальной атаки для злоумышленников.

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

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием. Вместе с Дмитрием Беляевым и Рустамом Гусейновым обсудили Vulnerability Management и Exposure Management, CVSS/EPSS/KEV и приоритизацию уязвимостей, AI-агентов и нейросети в триаже, автоматизированный патчинг, моделирование атак, зашивание безопасности в разработку, проблемы взаимодействия с IT, работу с системами, которые нельзя патчить, будущее VM-специалистов и особенности управления уязвимостями в Linux, Kubernetes, контейнерах и облаках. Классно посидели, мне очень понравилось. Надо будет как-нибудь продолжить общение по теме. 😉

Таймстемпы:

00:00 Приветствие, медиа-партнёры
03:25 Справедливо ли мнение, что CVSS как основная метрика приоритизации - это уже "технология 2002 года"? Почему в 2026 году компании всё ещё живут в логике "сортируем по CVSS", хотя есть EPSS, KEV и трендовые метрики? Это лень, незнание или инерция?
07:49 Насколько вопросы триажа, ранжирования и приоритизации уязвимостей делаются лучше с помощью нейросетей? Будет ли в будущем происходить быстрое сопоставление по разным шкалам и интегральная оценка с учётом искажений, которые есть в тех или иных системах метрик?
10:09 Автономные AI-агенты и VM
12:00 System-hardening и патчинг уязвимостей агентами без участия человека - уже реальность?
15:33 Насколько справедливо утверждение, что Exposure Management - это не просто "VM 2.0", а действительно другой взгляд на управление риском? В твоём понимании это эволюция или всё-таки революция, но с новым ценником? (Я тут попутал "croûton" и "croissant" в известной кино-цитате - сорян 🤦‍♂️🤷‍♂️🙂)
20:32 Про зашивание безопасности в IT/разработку, почему так много Linux-уязвимостей, и нужна ли замена Linux Kernel
30:08 Если завтра появится "идеальный ИИ", который с точностью 99% предсказывает, что уязвимость будет эксплуатирована в течение 30 дней, - правда ли, что роль VM-специалиста всё равно не исчезнет? В чём тогда останется человеческая зона ответственности?
32:31 О реализуемости полного моделирования путей атаки и автоматизированном реагировании
37:46 Насколько справедливо утверждение, что IT-отделы часто фактически саботируют VM? Как это выглядит на практике: это злой умысел, защита своих интересов или просто боль от перегрузки?
42:43 Как выглядит VM-процесс для систем, которые нельзя патчить или даже активно сканировать?
45:51 Как превратить IT-шников в ответственных хозяев своих активов?
48:48 Насколько сильно отличается подход к детектированию и управлению уязвимостями в Linux, контейнерах, Kubernetes и облаках от классического сканирования Windows-хостов? Где сегодня самые большие слепые зоны?
51:30 Детектирование - это только начало, а вся драма начинается после? Какие этапы после детекции чаще всего "рассыпаются" в реальных компаниях?
54:26 Блиц-вопросы
56:11 Заключение

📺 Смотрите на платформах: VK Видео, RUTUBE, YouTube.
🎧 Слушайте на платформах: Яндекс Музыка, Звук, Spotify, Pocket Casts, Deezer, Podcast Addict, Mave.

Собираюсь поучаствовать в конференции "ПЕРИМЕТР" от METASCAN 22 мая в Москве

Собираюсь поучаствовать в конференции ПЕРИМЕТР от METASCAN 22 мая в Москве

Собираюсь поучаствовать в конференции "ПЕРИМЕТР" от METASCAN 22 мая в Москве. Конференция позиционируется как оффенсерская и техническая: "пространство, где инженеры ИБ, реверсеры, хардварщики и исследователи уязвимостей говорят на одном языке и могут спокойно уходить в детали". При этом именно с акцентом на детектировании уязвимостей на сетевом периметре и его пробиве. Профильная VM-ная конфа! 🤩 В программе заявлены доклады об уязвимостях Рунета, ограничениях сетевого сканирования и использовании AI в ресёрче. 😉 Будет и подборка интересных находок на периметре за 2025-2026 год. Сам я выступлю с мини-докладом о роли и месте EASM в VM/CTEM-процессе. Кроме того, поучаствую в круглом столе "Управление безопасностью внешнего периметра: практики и вызовы".

Партнёры конференции Сбербанк, Xello, Mitigator и Indeed также выступят с докладами.

Помимо докладов ожидаются хардкорные гиковские развлекушечки: lockpicking, RFID и NFC-эксперименты, соревновательный OSINT, конкурс по обходу фильтров антифишинга (в каком состоянии - не уточняется 🙂), ретро-компьютеры (ZX Spectrum, Commodore 64, Commodore Amiga, Микроша, Atari), демосцена. Даже турнир по DOOM II будет. 🫶

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

Похоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного Хаоса

Похоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного ХаосаПохоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного Хаоса

Похоже, что эра AI Slop-а в ресёрче и репортинге уязвимостей заканчивается и начинается эра Высококачественного Хаоса. Об этом в своём блоге пишет Daniel Stenberg - создатель и ведущий разработчик проекта curl. В конце прошлого года он показывал статистику багрепортов на HackerOne: подтверждённых уязвимостей становилось меньше, а общее число репортов при этом росло, в основном за счёт низкокачественной AI-генерёнки. Ситуация усугубилась в начале 2026 года до той степени, что 1 февраля curl закрыли свою баг-баунти программу на HackerOne и начали принимать репорты только на GitHub. Но спустя месяц они вернулись на HackerOne ("как только поняли, что GitHub недостаточно хорош") и обнаружили, что характер сдаваемых репортов о проблемах безопасности изменился:

📈 Больше объём, выше качество. Проблема со slop-ом больше не актуальна. Частота поступления репортов выше, чем когда-либо. В последнее время она примерно в два раза выше, чем в 2025 году, который и так более чем вдвое превышал предыдущие годы. Качество выше. Доля подтверждённых уязвимостей вернулась на уровень до эпохи AI в 2024 году и даже превысила его примерно на 15-16%. Кроме того, значительно выросла доля репортов с багами, а не с уязвимостями.

🤖 Почти каждый репорт сейчас в той или иной степени формируется с использованием AI. Это видно по формулировкам, стилю изложения и по тому, что даже повторные репорты об уже известной проблеме выглядят тщательно проработанными ("and also by the fact that they now easily get very detailed duplicates"). Люди вручную не могут так писать. Однако разница по сравнению с прошлым в том, что сейчас большинство таких репортов очень высокого качества.

📊 Такая картина не только с curl. Daniel Stenberg провёл быстрый неформальный опрос в Mastodon, чтобы выяснить, наблюдают ли другие open source проекты аналогичные тенденции. И, как оказалось, да. Представители ряда проектов подтвердили, что также фиксируют данный тренд. Речь о Apache HTTP Server, BIND, curl, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, Linux kernel, OpenLDAP, PowerDNS, python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark, wolfSSL… Разумеется, конкретные показатели и масштабы различаются, однако это указывает на то, что явление не является специфичным для какого-либо одного проекта. Daniel Stenberg предполагает, что этот список проектов - просто случайная выборка тех, кто увидел его опрос. Проектов наверняка больше.

💥 Взрывной рост количества уязвимостей. Когда команда curl выпустит curl 8.20.0, в конце апреля 2026 года, там пофиксят как минимум шесть новых уязвимостей. Если предположить, что тренд сохранится хотя бы до конца года, а Daniel Stenberg считает это разумным предположением, то в этом году проект curl пофиксит рекордное количество CVE. В 2026 году может быть опубликовано около 50 уязвимостей curl. Что-то подобное должно ожидаться и в других проектах, т.к. тренд универсальный.

Что будет дальше?

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

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

🔻 Данная лавинообразная динамика, вероятно, ещё больше усилит нагрузку на мейнтейнеров. Ряду проектов будет сложно справляться с ростом бэклога без привлечения дополнительной поддержки.

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

🔻 В дальнейшем всем пользователям потребуется обновляться до новых исправленных версий пакетов, что, как ожидается, может занять значительное время.

Таким образом, отрасль, вероятно, ожидает период повышенной нестабильности.

От себя могу добавить, что рост количества исправляемых CVE в Linux-софте (не только в ядре!) виден и в рамках Linux Patch Wednesday. В апреле количество CVE было максимальным (1035) за всё время (май 2024 года исключаем, там высокое значение было связано с изменением алгоритма). Будем наблюдать и анализировать. 😉

Почитываю, что там пишут про Anthropic Claude Mythos

Почитываю, что там пишут про Anthropic Claude Mythos

Почитываю, что там пишут про Anthropic Claude Mythos. От алармизма и восторженных отзывов, что эта вундервафля пачками обнаруживает эксплуатабельные 0-day уязвимости без какого-либо участия человека (и якобы поэтому крайне этичные Anthropic включили режим почтальона Печкина: "я вам её не отдам, у вас документов нету"), всё скатилось к "пирожку с ничем". То есть буквально: в The Register вчера вечером вышла статья "Anthropic's super-scary bug hunting model Mythos is shaping up to be a nothingburger".

Моё мнение по этому поводу: все комментирующие правы! 🙂

🔹 Офигели ли Anthropic со своим бесстыжим маркетингом и нагнетанием необоснованного хайпа? Конечно, да!

🔹 Есть ли подвижки в автоматическом детектировании эксплуатабельных уязвимостей? Безусловно!

Когда CTO Mozilla говорит по поводу 271 уязвимости в Firefox 150, найденных Mythos:

"Мы не увидели ни одной ошибки, которую не смог бы найти высококлассный (elite) исследователь-человек."

Это не критика инструмента, который пока не круче человека. Это суперкомплимент! Вы вообще много высококлассных ресёрчеров знаете? А тех, которые эффективно масштабируются и работают 24/7? 😏 Вот то-то.

Поэтому даже если Mythos - полная ерунда и чистый хайп (в чём я лично сомневаюсь 🤔), расслабляться точно не стоит. "Манхэттенский проект" в области разработки кибероружия уже вовсю идёт и останавливаться не собирается. И там далеко не мифосом единым. Это особенно интересно смотрится в контексте опубликованного на днях манифеста Palantir о милитаризации США (и их сателлитов Германии и Японии), ведущей роли в этом американского бигтеха, новом ИИ-сдерживании (заменяющем сдерживание ядерное). На весь этот надвигающийся мрачняк придётся чем-то отвечать. 🤷‍♂️ И, учитывая разницу в ресурсах и технологическом уровне (включая ИИ) между США и Россией, отвечать придётся как-то асимметрично.

Имхо, для начала неплохо хотя бы прекратить утечку наресёрченных в стране критичных уязвимостей за рубеж. Да-да, кто о чём, а я опять про централизацию репортинга - это важно! Также неплохо бы подумать о том, как хоть в какой-то мере закрыться от цунами низкокачественного нагенерённого кода, в котором искать уязвимости будет особенно просто. Кода, генерируемого, к слову, в основном на сервисах потенциального (или вполне фактического) противника. Что тоже должно поднимать обоснованные вопросики. 😉

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства. При этом зачастую его апологеты пропагандируют вещи откровенно вредные. Что уметь программировать больше не нужно. Разбираться во фреймворках и библиотеках - тем более не нужно. Достаточно просто поставить задачу, даже в самом общем виде, волшебному кодогенератору да докинуть токенов облачного AI-сервиса. А дальше ОНО ВСЁ ДЕЛАЕТ САМО! 🪄 И через несколько часов получаешь нужный результат.

А главное, что это не обман. Таким образом действительно можно получить программное решение, которое РАБОТАЕТ (пусть и не с первой итерации). Правда, фиг его знает, как оно написано и какие там могут быть сюрпризы - но кого ж это волнует, правда? 😏

В результате:

🔹 В ширнармассах возникает весьма понятное ощущение - вот оно! 🤑 Теперь для того, чтобы слепить стартап, больше не нужны технари! Волшебная машинка, накормленная токенами, выдаст приложульку сама. А фаундер может целиком посвятить себя окучиванию инвесторов и получению прочих бенефитов.

🔹 Да и состоявшиеся корпорации тоже не прочь по возможности сэкономить на разработчиках. 😇

К чему это приведёт в обозримом будущем? К тому, что разработкой (генерацией) кода начнёт заниматься огромное количество новых игроков, абсолютно незрелых и безответственных. Без какого-либо понимания о процессе безопасной разработки, правильной архитектуре, способах определения уязвимостей в собственном (лол 😅) коде и зависимостях (зачастую в такой же безответственной генерёнке 🤷‍♂️), нормальном выпуске обновлений с бюллетенями безопасности, CVE-шками и прочим.

И будьте покойны, эти новые игроки нагенерят ОГРОМНОЕ количество чёрти как работающего кода. Как коммерческого, так и опенсурсного. Настолько много, что все традиционные более-менее ответственные игроки потеряются на фоне массы этой новой вайбкодерной гопоты. И либо не смогут толком конкурировать с ней, либо сами деграднут до её уровня. 😏

Мы ещё будем с ностальгией вспоминать то благословенное время, когда код писали ручками, профессиональные программисты. Решение проблем с ПО, с которыми мы сталкивались раньше, было сродни плесканию на мелководье. А сейчас на нас надвигается цунами и что с этим делать, не особенно понятно.