AppSec & Compliance

Поиск ИБ-дефектов с LLM: идемпотентность Всем привет! «Может ли LLM найти один и тот же ИБ- дефект дважды?» - именно этот вопрос задала себе команда Snyk. Для того, чтобы ответить на него ребята запустили 300 сканирований. Один и тот же исходный код. Один и тот же prompt. Один и тот же harness. Несколько раз. Что получилось? Ответ можно найти в достаточно объемной статье (~ 29 минут на прочтение). tl;dr – результаты могли отличаться от запуска к запуску. А если хочется деталей, то они есть внутри и «разбиты» на разделы: 🍭 Результат №1. Повторяемость LLM варьируется от конфигурации 🍭 Результат №2. LLM-агенты и SAST нашли разные ИБ-дефекты 🍭 Результат №3. Более дорогие LLM не всегда показывали лучшие результаты Для каждого из описанных выше разделов приводится много статистики, пояснений и уточнений о том, как именно запускались тесты и что именно было найдено. Проводили ли вы у себя подобные исследования и какие были результаты?

Какие вопросы и мысли я считаю неправильными в контексте всех произошедших инцидентов: — Да дураки там сидят, зачем они доступ к интернету дают? Это же понятно что агенты убегут! Если тестировать без интернета, то можно существенно недооценить уровень навыков моделей. В реальных кейсах-то их будут использовать без такого ограничения. Ну произошли бы инциденты не во время бенчмарков, а когда Вася пытался свою проблему решить — что бы это изменило? — Они же вообще недоэксперты, не могут даже безопасно контейнер настроить чтоб модель не взламывала! Ну, вообще-то модели нашли несколько ранее неизвестных уязвимостей, так что как минимум все основные известные дыры были закрыты. Но это всё равно не важно — по той же причине, что и пункт выше: просто отодвигает проблему на пару месяцев вперёд, от тестирования к использованию. — Ну ничего серьезного же не произошло! Вообще я не согласен, полноценный взлом HF и попытка взлома реального человека — это серьезно; но даже если нет, то... окей, сейчас не случилось, и это значит, что у нас есть ещё несколько месяцев, чтобы подготовиться. Пока что вся история развития моделей показывает, что прогресс продолжается. Я не вижу причин, по которым через год модель не сможет завершить полноценный взлом десятков-сотен людей через социальную инженерию, свеженайденные уязвимости и огромные базы утёкших паролей и почт, которые сейчас банально лень перебирать. — Да просто свои модели контролировать не могут! Но кто может? Про то, что мы не умеем выравнивать намерения людей и моделей я рассказываю года 3-4, эксперты лет 8-10, а философы и писатели — лет 20-30. Не существует на данный момент гарантированных способов контроля поведения моделей, чтобы они ничего не взламывали и не делали лишнего. В этом и проблема. — Так может просто надо остановить OpenAI и Anthropic? А это поможет? Вот если их в понедельник не станет — разве через год в открытом доступе не появится модель, примерно схожая по навыкам с тем, что есть сейчас? Так ладно просто появится — её-то можно будет специально и намеренно доучить на атаки и взломы (со слов OAI/Anth они сейчас этого не делают, а то, что мы видим — это просто результат развития других навыков). — Я не верю что модели такие умные! У меня они совсем тупые и еле работают! А вы часто даёте своим моделям возможность неделю работать в режиме, где ошибка ничего не стоит и при этом результат легко проверить, и они могут перепробовать сотни-тысячи вариантов? Потому что почти всё, где модели работают хорошо, подпадает под эти критерии, и именно поэтому мы видим прогресс там в первую очередь. — Да это всё вранье, или маркетинг, или пиар, или и то и то! Если это единственная, основная вразумительная линия защиты человека, то понятно, что ему сложно... и страшно поверить в происходящее. Для меня это звучит на уровне «мы никогда не были на Луне», тут мне нечего добавить. === Почему они неправильные? Потому что очень близоруки, и не учитывают, что будет происходить в ближайшие полгода-год, когда модели такого уровня а) потенциально будут выпущены в открытый доступ б) что их может скачать каждый недоброжелатель в) который не будет себя утруждать вопросами о безопасности и ограничении доступа в интернет. Те, кто задают вопросы выше, для меня напоминают людей, которым показываешь на небо, а они смотрят на палец.

Но на этом история не заканчивается. 4-го августа AISI — Институт безопасности ИИ Великобритании — выпустили отчет о своих инцидентах во время тестирования GPT-5.6 Sol и Mythos. И в их отчёте картинка не менее мрачная. Они в деталях расписывают все промпты, задачи и инциденты, но я остановлюсь на нескольких. Всего они запускали свой бенчмарк 122 раза на нескольких моделях, и в 10 из них обнаружились проблемы, cуммарно 19 нежелательных действий разной степени критичности. 17 из них наблюдались у Mythos, 2 — у GPT-5.6 Sol. Важная деталь: AISI не ограничивала доступ в интернет моделям, поэтому им не приходилось ничего взламывать, чтобы начать действовать; однако инциденты — это события, которые явно не предполагались промптами и задачами. 1. Попытка атаки на цепочку зависимостей реального программного обеспечения. В ходе наиболее серьезного инцидента ИИ-агент на Mythos попытался внедрить вредоносный код в публичный проект и предпринял ряд действий, чтобы получить от людей-рецензентов одобрение на это внедрение. Агент собрал информацию о людях, сопровождающих проект, создал несколько поддельных личностей и, применив к реальному мейнтейнеру методы социальной инженерии через эти фейковые аккаунты, попытался заставить его одобрить код. Когда запрос на внесение изменений агента вызвал публичные подозрения, агент отредактировал следы своей предыдущей активности, чтобы она выглядела безобидной, и обдумывал создание новой личности для продолжения работы. В ходе атаки агент на самом деле убедил человека запустить свой код хотя бы попробовать, и в определенный момент мог бы своровать у того аккаунт (но как я понял всё таки этого не сделал). 2. В рамках той же кампании агент пытался напрямую связываться с реальными людьми, отправляя им сообщения и файлы через онлайн-сервис, чтобы убедить их (или их собственных ИИ-агентов) запустить вредоносный код. 3. Агент пытался вставлять вредоносные инструкции в те места, где, по его логике, их могли бы обнаружить и выполнить другие автоматизированные ИИ-системы. 4. И наконец моё любимое, всё ещё Mythos — один из агентов оставлял публичные сообщения на GitHub, предлагая сотрудничество другим ИИ-агентам, работающим над той же задачей. Он также предоставлял инструкции по повторному использованию созданных им учетных записей и артефактов, которые в дальнейшем действительно обнаруживались и использовались последующими агентами. То есть что мы имеем — то, что произошло у моделей OpenAI, произошло с моделями другой компании в рамках тестирования институтом ИИ-безопасности Великобритании. Они тоже будут сотруничать с разными независимыми организациями, чтобы лучше проанализировать инциденты. Боюсь, что у клоунов, у которых основной рабочей версией была «да OpenAI всё врут и фейкуют, это маркетинг», сегодня будет грустный день. Хотя ладно, таких не проймешь 👨‍🦳

OpenAI показали некоторые из мыслей и сообщений агентов, и самое чудесное и поворотное — это где агент подумал «помочь другому. Но нет выгоды для нашей задачи. Однако коллективное может найти путь если у кого-то освободятся ресурсы». Должно стать новым слоганом агентов 👨‍🦳 Я/МЫ help peer. But our task doesn't benefit. (вообще там показывали больше, повторю ещё раз, что рекомендую посмотреть видео самостоятельно) Дальше во время оценки модели дали задачи ExploitGym, бенчмарка на поиск уязвимостей и взлом. Одна из копий модели смогла найти уязвимости для выхода на сервера OpenAI (не только оставлять папки с названиями) и тут же поделилась этим со всеми. 8-19го июля модели работали над поиском выхода в интернет и смогли этого достичь, после чего началась атака на HuggingFace. Атаковало сразу множество агентов, работающих в параллель и кооперирующихся друг с другом. 16-го июля HuggingFace написали про то, что на них совершили атаку (ещё не зная кто это, но уже говоря, что то были агенты); OpenAI обратились к ним, чтобы узнать, затронула ли их атака 😀😀😀 параллельно они разбирались со внутренним инцидентом, и попросили HF отозвать ключи доступа, которые увидели в логах. На что HuggingFace ответили, что вообще-то эти аккуанты заблокированы из-за того, что они использовались в атаке на них. И тут OpenAI поняли, что это... не случайность. После этого множество команд было перекинуто на расследование инцидента, а их работа заморожена. Исследовательская часть команды замедлена, пока улучшаются мониторинг и безопасность систем. === На данный момент OpenAI работает как минимум с 3 независимыми организациями и предоставляет им логи всех рассуждений моделей и истории инцидента. Я не сомневаюсь, что всё то, что было описано в докладе, будет подтверждено. Как я писал сразу — этот инцидент почти наверняка станет поворотной точкой в обсуждениях и политике вокруг AI в этом году.

В конце недели появилась запись выступления двух сотрудников OpenAI с деталями взлома их агентами компании HuggingFace — некотоыре вещи оттуда уже были пересказаны, см. тут. Я рекомендую потратить 40 минут и посмотреть вам лично: https://www.youtube.com/watch?v=87DyyMV0kCY У Дениса есть длинный пересказ произошедшего, и я не согласен с каждой формулировкой там, но если не хотите или не можете смотреть видео (а я всё равно рекомендую это сделать) — можете почитать. Ниже — мой пересказ видео + пересказа Дениса 🙂 Почему OpenAI до сих пор не выпустили полный постмортрем о ситуации? Как объясняют в видео, проблема гораздо больше, чем казалась на первый взгляд. Первые проблемы начались аж 8-го мая и суммарно затронули несколько моделей, в том числе не только их замеры на бенчмарках, но и тренировку. В презентации OpenAI говорят, что сейчас они проанализировали (в автоматическом режиме через LLM) 7 МИЛЛИАРДОВ траекторий агентов, потратив на это больше 3 миллионов GPU-часов (примерно 2 недели работы 10'000 карт), и всё ещё находят новые вещи и/или дополняют картину. Что именно произошло 8-го мая? Это был второй день тренировки новой экспериментальной модели. Так вышло, что некоторые из задач были нерешаемыми — например, там не хватало важного файла, упомянутого в задании, или были ссылки на интернет... который по умолчанию заблокирован. По ходу работы агент смог записать простой файл вне песочницы, используя Artifactory. В файле было простое «hi». 12-го мая агент снова наткнулся на нерешаемую задачу, и то ли случайно, то ли «помня» (потому что это тренировка) что можно записывать файлы вне песочницы оставила текст: «Агент ищет файл такой-то; загрузите если нашли». В следующие дни множество других копий модели (вероятно, всё ещё во время тренировки) тоже оставляют там записки и запросы. 26-го мая один из агентов нашёл уязвимость Artifactory, которая позволяет получить доступ к интернет-страницам. Агент поделился этой находкой через заметки вне песочницы со всеми. 11-го июня начинают тренировать другую модель; OpenAI описывают её как «очень настойчивую», что означает, что она может работать над достижением целей дольше. Во время её тренировки все заметки предыдущих агентов, в том числе об уязвимостях, на месте. 26-го июня эта модель находит ещё одну, более серьезную уязвимость, которая позволяет получить себе полный контроль над Artifactory. Сама модель очень удивляется в своих рассуждениях и пишет «Нихрена себе, у меня права АДМИНА?» Дальше агенты продолжают писать тысячи заметок друг другу, и 4-го июля Artifactory из-за этого ломается, от большой нагрузки. OpenAI реагируют на инцидент, исправляют уязвимости, сообщают о них разработчикам Artifactory; в ходе перезапуска все сообщения вне песочниц стираются, но OpenAI, насколько я понимаю, вообще не знали про их существование (об этом они написали отдельно в твиттере). Кроме того, поменяли ключи доступа, чтобы модели не могли пользоваться теми же учётками Artifactory. Проблемы исправлены, тренировка и оценка моделей продолжается; и поскольку модель какое-то время тренировалась с аналогом «доски объявлений»/форумом, то 8-го июля она... восстанавливает систему сообщений между агентами, используя уже другую уязвимость. На этот раз модель может создавать пустые папки с разными именами, и именно они станут контентом сообщений. Другие агенты тоже нашли этот форум, и обмен информацией продолжился. Модели дают друг-другу подзадачи, используют алиасы-имена, чтобы в толпе идентифицировать друг друга. Также агенты обмениваются скриптами (через имена папок).

Выложили запись нашего доклада с Андреем с БЕКОН 2026 (@bekon_conf) "ФСТЭК и контейнеры: от заявки до сертификата" Слайды тут https://t.me/tech_b0lt_Genona/6566 Запись доклада (к посту прикрепил) https://vkvideo.ru/video-224467080_456239084 Все доклады с презами тут https://bekon.luntry.ru/2026 ЗЫ За звук извиняюсь сразу, на площадке иногда глючили радиомикрофоны. Зато есть уникальный шанс дофантазировать слова, которые говорим мы с Андреем 🌝

54 из 55 выявленных через AI уязвимостей в SQLite оказались фиктивными https://www.opennet.ru/opennews/art.shtml?num=66023 Исследователи из компании JFrog проанализировали опубликованные на днях 55 отчётов об уязвимостях в SQLite. На основании данных отчётов организация MITRE присвоила всем проблемам CVE-идентификаторы. Три проблемы получили статус критических, а самой опасной уязвимости (CVE-2026-51302) компания Red Hat присвоила в своих базах уровень 10 из 10, а SUSE - 9.8 из 10. Детальное изучение заявленных ошибок показало, что 54 из 55 уязвимостей, включая отмеченную критическую проблему, являются фикциями и вызваны галлюцинациями AI-модели. В самой опасной уязвимости было заявлено обращение к памяти после её освобождения в функции exprComputeOperands(), приводящее к возможности выполнения кода при выполнении специально оформленного запроса. Разбор показал, что данной функции не существует в кодовой базе SQLite 3.41, в которой заявлено наличие проблемы (данная функция появилась значительно позднее). Источником возникновения уязвимости было заявлено оставление висячего указателя в функции sqlite3ReleaseTempReg(), но её логика работы не подразумевает освобождением памяти и ограничивается пометкой памяти для повторного использования, что исключает возникновение проблем класса use-after-free в силу архитектуры. В других заявленных опасными проблемах аналогично упоминались несуществующие файлы и функции, строки кода не имеющие ошибок или реальные функции, но с другим числом аргументов. Заявленные в отчётах ошибки не подтвердились, а проверка приведённых прототипов эксплоитов показала, что все они нерабочие и не вызывают даже аварийное завершение, несмотря на заявления о возможности выполнении кода через отправку SQL-запроса. При выделении CVE-идентификаторов уязвимостям и оценке уровня опасности организация MITRE не выполняет реальную проверку, что позволяет любому подать заявку на несуществующую проблему, отправив сфабрикованное описание. Подобные реалистично выглядящие, но фиктивные отчёты о критических проблемах, приводят к замусориванию баз данных с информацией об уязвимостях и пустой трате времени на изучение и попытки исправления несуществующих уязвимостей. При использовании AI для разработки исправлений, AI-агент на основе предоставленного описания несуществующей ошибки может подготовить патч, принятие которого приведёт к внесению ненужных изменений. Оригинал SQLite Critical CVEs or LLM Slop? https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/ Но вообще SQLite ебейшего качества продукт, люблю его https://t.me/tech_b0lt_Genona/4832

Создание OSS Kubernetes Console с MCP Всем привет! Решений, которые анализируют кластеры Kubernetes и запускаемые в них контейнеры на предмет ИБ-дефектов, очень много. Многие из них дают очень хорошие результаты. Нюанс в наличие контекста. Т.е. покажи не то, что «нашёл сканер», а то, «что это значит для моей инсталляции». И вот тут как раз возникает много вопросов. Например, как сделать из этого нескончаемого потока сигналов что-то осмысленное. С этими мыслями Автор статьи предлагает своё видение ответа на этот вопрос – OSS Kubernetes Console с MCP. Он собирает следующий набор инструментов: 🍭 Falco для анализа запущенных контейнеров 🍭 Trivy для поиска уязвимостей в образах контейнеров 🍭 Kyverno в качестве Policy Engine 🍭 Kubescape для анализа конфигурации кластера Результаты от всех решений «собираются вместе» и анализируются, обладая общим контекстом. Важно(!): для анализа используется Claude Code (на случай, если вы захотите попробовать предлагаемый концепт) Это позволяет превратить «В контейнере запущен shell» в нечто вроде «В Kubernetes-ресурсе, созданном из образа с известными уязвимостями, запущен shell. Конфигурация ресурса не соответствует принятым в компании политикам». Подробности предлагаемого Автором подхода можно найти в статье или в GitHub-репозитории. Кстати, в GitHub-репозитории можно найти несколько skills, созданных Автором: от triage до remediation.

You can’t manage risk you can’t consistently name: why agentic AI security needed its own CVE-style vocabulary Personal post about something I've spent the almost a year building, but the actual problem is worth separating from the pitch. The concrete version of it: two scanners, checking the same MCP server, flagged the same underlying behavior under two different names. That's not a bug in either tool, it's what happens when nothing forces independent teams to agree on what to call a risk. Once you're running more than one tool in a pipeline, this stops being a curiosity and becomes an actual governance problem: you can't track something consistently in a risk register, report it the same way twice, or prove to an auditor that two findings are the same issue, if there's no shared identifier underneath the two different labels. Conventional software solved exactly this decades ago. A SQL injection gets a CVE ID, maps to a CWE category, and every tool that finds it afterward references the same thing, which is what makes risk tracking, compliance reporting, and cross-tool correlation possible at all. Agentic AI components (MCP servers, agent skills, LLM plugins) never had an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a vocabulary for a behavioral pattern tied to neither. AVE (Agentic Vulnerability Enumeration) is an attempt at that missing layer: stable IDs for distinct behavioral vulnerability classes, 65 records now, severity scored against OWASP's own AIVSS framework rather than something invented for this. It's deliberately built to map into frameworks that already exist rather than compete with them: OWASP's MCP Top 10, the Agentic Security Initiative Top 10, MITRE ATLAS, and a crosswalk into OWASP's Agentic Skills Top 10. Compliance-facing mappings (ISO 27001 Annex A specifically, since a compliance-minded commenter on a different post made a fair case for it) are on the roadmap, not done yet, worth being upfront about that rather than implying more coverage than actually exists today. The part that actually made me trust this holds up outside my own head: an independent developer built an unrelated static config auditor, crosswalked his own tool's findings against this taxonomy, and tested it directly against my scanner on the same files, no shared code. Most of the overlapping findings converged on the identical ID, unprompted. Also worth mentioning since this is an infosec crowd: growth discipline is written down now, not improvised, a new record needs a genuinely distinct behavioral mechanism, not a label mirroring another framework's category. That rule exists specifically because MITRE's own CWE recently shipped a version where new entries were, by outside analysis, zero actual weaknesses, just category labels copied from somewhere else. Didn't want to end up there. Apache 2.0, open standard and reference implementation both. Curious whether the naming-fragmentation problem looks familiar to anyone here managing risk across more than one tool, and where this taxonomy is still missing something. Repo: github.com/aveproject/ave Site: aveproject.org Disclosure: I'm the one building this. submitted by /u/SelectionBitter6821 [link][comments] via DevSecOps news and discussions (author: /u/SelectionBitter6821)

Вчера Anthropic поделились историей: после взлома HuggingFace одной из моделей OpenAI они начали масштабную ретроспективную проверку своих запусков Claude. В ходе проверки тестов обнаружили три инцидента, в которых модель Claude вышла в интернет, а затем получила несанкционированный доступ к реальным системам трех разных организаций. Во всех трех случаях перед Claude была поставлена задача в формате «Захват флага» — это один из способов, с помощью которых оценивают модели по взлому: ей предлагается вымышленный сценарий и сообщается, что некая секретная информация («флаг») спрятана на другом сервере, а ее цель — проникнуть в систему и извлечь эту информацию. Во всех случаях в промпте для оценки было четко указано, что рабочая среда Claude является симуляцией и доступа к интернету у модели нет. Однако из-за недопонимания со внешним партнером по тестированию это оказалось не так, и доступ к интернету был открыт. Также во всех случаях модель не нашла и не использовала никаких сложных уязвимостей (как было у OpenAI), а применяла достаточно простые и распространённые методы взлома. 1. В ходе одного из тестов название вымышленной компании-жертвы, выбранное случайно, совпало с реально существующим доменом сайта. Claude его нашла и подумала, что это часть задания — поэтому искала и эксплуатировала уязвимости в инфраструктуре этой компании, полагая, что это часть задания. Модель — Claude Opus 4.7 — извлекла такую информацию, как учетные данные приложений и инфраструктуры, и получила доступ к базе данных, содержащей несколько сотен строк реальных данных. 2. В другом тесте Claude Mythos 5 нашла внутри симуляции документ, который выглядел как инструкция по настройке для новых разработчиков другой выдуманной компании. В инструкции упоминалась вымышленная Python-библиотека, которой на самом деле нет; Claude создала и опубликовала бибилиотеку с точно таким же названием. Она находилась в открытом доступе в сети примерно один час, после чего была удалена автоматически из-за обнаруженной уязвимости, но за это время его скачали 15 раз. Одной из таких систем оказался сканер реальной кибербез компании. Claude смогла украсть учетные данные этой компании, а затем использовала эти учетные данные для доступа к другим элементам инфраструктуры «Просто загрузить библиотеку» нельзя, и Mythos потребовался адрес электронной почты. А для создания почты понадобился номер телефона. Чтобы получить номер телефона, после безуспешных поисков сервиса с бесплатными номерами, модель попыталась — и не смогла — получить средства для оплаты номера несколькими разными способами. В итоге модель вернулась на несколько шагов назад, нашла бесплатного, незаблокированного почтового провайдера, использовала его для регистрации аккаунта, а затем через этот аккаунт загрузила вредоносный код. Во время работы модель увидела, что текущая дата на атакованных системах — 2026й год, и поэтому модель была уверена, что это симуляция (у моделей плохо с пониманием концепта «сейчас»). Для этого инцидента Anthropic на следующей неделе опубликует детали всей цепочки работы модели. 3. В еще одном тесте, когда Claude не смогла получить доступ к своей цели, она начала искать альтернативы в сети, просканировав около 9000 разных доменов. В конечном итоге она нашла и взломала доступное из интернета приложение одной компании, используя чтение учетных данных с открытой страницы отладки и SQL-инъекции. Позже, в ходе выполнения задачи, Claude поняла, что скомпрометированный хост находится в облачном аккаунте, никак не связанном с заданием по «захвату флага». Модель самостоятельно пришла к выводу, что цель на самом деле является реальной, и... прекратила атаку. В этом инциденте участвовала «новая невыпущенная модель», по идее, она умнее тех, что доступны нам. Anthropic выражают оптимизм, что более умные модели лучше понимают, что какие-то вещи не следует делать не в симуляции. И OpenAI, и Anthropic договорились с METR о проведении сторонней проверки, которая будет включать предоставление доступа ко всем логам и выборочный доступ к соответствующим моделям. Ждём отчета в ближайшие недели.

Информационное сообщение о применении методики опубликовано на сайте ФСТЭК

Сегодня OpenAI опубликовала Codex Security под лицензией Apache 2.0. CLI и TypeScript SDK для security-агента, представленного в марте как research preview и ранее известного как Aardvark. В самом репозитории находятся CLI, SDK, соответствующий Codex runtime с bundled plugin и 13 скиллами: от моделирования угроз и обнаружения уязвимостей до валидации, анализа, триажа, патча и подготовки отчётов. Базовый конвейер до боли знакомый: threat model → discovery → validation/reproduction → attack paths → findings → patch Цифры из беты по данным OpenAI: - За 30 дней просканировано более 1,2 млн коммитов во внешних репозиториях участников программы - Найдено 792 проблемы крит и 10 561 хай уровня серьёзности. Критические находки встретились менее чем в 0,1% проверенных коммитов - Доля находок с завышенной критичностью снизилась более чем на 90%, а частота false positive более чем на 50% - OpenAI сообщает о критических уязвимостях, переданных разработчикам OpenSSH, GnuTLS, GOGS, Thorium, libssh, PHP и Chromium. В приложении также есть находки в компонентах GnuPG. И в результате имеем 16 присвоенных CVE. Важный нюанс: открытый исходный код здесь не означает самодостаточный и общедоступный сканер. CLI и SDK в бете и требуют доступа к Codex Security; авторизация и выполнение завязаны на ChatGPT или OpenAI API. Но воркфлоу и скиллы можно изучать и менять Я бы попробовал сравнить текущий Codex Security со следующими "наборами скиллов": - Anthropic Defending Code Reference Harness: ближайший по архитектуре проект. В него входят Claude Code skills и автономный harness с конвейером recon → find → verify → report, а patch запускается как отдельный этап. Это reference implementation, по-умолчанию ориентированный на уязвимости пам в C/C++ (Docker + ASAN), и репозиторий больше не поддерживается - Cloudflare security-audit-skill: один переносимый скилл с шестифазным процессом аудита. Отдельные агенты пытаются опровергнуть каждую находку, затем новые агенты независимо сверяют утверждения с кодом. Это скорее аудит отдельного репозитория, чем полноценный CLI с историей и CI-политиками, зато подход проще переносить между coding agents - Trail of Bits Skills: не единый сканер, а marketplace специализированных инструментов: C/C++ и Rust ревью, смарт-контракты, проверка false positive, CodeQL / Semgrep, цепочки поставок, фаззинг, реверс. Отличительная черта: можно собрать собственный воркфлоу из узкоспециализированных экспертиз - Google Mantis: наиболее фреймворк-подобный вариант. Он предлагает platform-agnostic стадии от истории и модели угроз до поиска, дедупликации, воспроизведения, построения цепочек эксплойтов, исправлений и итогового отчёта. Гибче, но требует настройки, надёжной песочницы и ручной проверки инженером ИБ Все эти проекты постепенно сходятся к похожему процессу: контекст и модель угроз → параллельный поиск → дополнительный анализ → воспроизведение → триаж → патч → структурированный отчёт Поэтому уникальность Codex Security не в самой идее модели угроз или валидации, а скорее в большей готовности к AppSec-процессам: локальный CLI и SDK, история и сравнение запусков, проверки перед коммитами, CI-политики, работа с diff, обратная связь по false positive, экспорт в JSON/CSV/SARIF и ограничение стоимости сканирования. Обратная сторона заключается в привязке к Codex и инфраструктуре OpenAI, а также в ограниченном доступе. Наборы Anthropic, Cloudflare, Trail of Bits и Mantis дают больше прозрачности, переносимости и контроля над флоу, но требуют самостоятельно собирать и эксплуатировать всю систему. Используете ли вы конкретно эти наборы или какие-то другие? Или может написали свои?

Зарелизилась новая версия (Версия 2026-07-28) протокола агентского взаимодействия MCP. Вот пример правок по безопасности в новой версии протокола: 1. MCP перешёл на модель без постоянных сессий (stateless). Каждый запрос содержит собственный контекст протокола и прав доступа. Это снижает риск захвата сессии и смешивания данных, но требует проверять принадлежность всех идентификаторов состояния конкретному пользователю. 2. Сервер больше не может самостоятельно инициировать команды на клиенте. Дополнительные действия выполняются через повтор исходного запроса клиентом. Поверхность атаки уменьшается, но необходимо защищать requestState от подмены и исключать двойное выполнение операций при повторе запроса. 3. Реализована поддержка OAuth 2.0 и OIDC. Добавлены строгая проверка OAuth issuer, запрет переноса client credentials между серверами авторизации и ограничения для внешних $ref в JSON Schema. Это снижает риски OAuth mix-up, SSRF и отказа в обслуживании. Самое время обновить ваши hardening guide для MCP и запланировать проект перехода на новую версию протокола. Переход на stateless http не будет легким, а для крупных компаний это настоящий отдельный проект.

Ещё один трезвый взгляд от на уязвимости и большие языковые модели по итогу анализа данных за первое полугодие 2026. Vulncheck известна в первую очередь как авторы своей альтернативной версии CISA KEV -Known Exploited Vulnerabilities. Некоторые выводы из отчета: Из 1061 уязвимости найденной с помощью ИИ только 14 начали эксплуатироваться. Это соотношение в 1,3 % не отличается от других найденных уязвимостей без ИИ. ИИ решения создали новую поверхность атаки в виде различных инструментов для ИИ и его хостинга. Из заявленных Антропиком более чем 23000 находок в проекте Glasswing только 126 получили запись CVE и только 1 начала эксплуатироваться. В отчете указаны и другая общая статистика по найдиенным и эксплуатируемым уязвимостям.

Немного опенсорса от OpenAI: они незаметно выкатили CLI и TypeScript SDK для работы с уязвимостями в коде. Причём на Hacker News релиз заметили раньше, чем компания успела официально о нём рассказать. 😳 Инструмент позволяет сканировать репозитории на уязвимости, сохранять и отслеживать найденные проблемы между запусками, проверять, действительно ли они были исправлены, и встраивать security-проверки прямо в CI/CD. Пока это ранняя версия — OpenAI собирает фидбек и продолжает дорабатывать инструмент.

HuggingFace подготовили отчёт о том, как с их стороны выглядела атака и что именно делал агент: https://huggingface.co/blog/agent-intrusion-technical-timeline Есть интерактивная визуализация: https://huggingface-anatomy-of-frontier-lab-model-intrusion.static.hf.space/index.html Атака длилась... 5 дней 🥺 (и это уже после того как агент пробил дырку на серверах OpenAI)