🧨 Kimi K3 нашёл уязвимость в Redis за 27 минут
На этой неделе по соцсетям разлетелась новость про то, как исследователь Чаофань Шоу обнаружил уязвимость в Redis и подготовил рабочий эксплойт. Анализ производился автоматизировано с помощью Kimi K3, роя из 32 AI-агентов и занял всего за 27 минут.
Код эксперимента уже опубликован на GitHub.
Если это подтвердится независимыми исследователями, мы можем стать свидетелями серьёзного скачка в автоматизации vulnerability research.
По словам автора, агентам дали задачу самостоятельно проанализировать исходный код Redis, найти memory corruption-уязвимость и построить рабочий exploit chain.
В опубликованном репозитории представлены PoC для нескольких версий Redis. Один из них позволяет выполнить произвольную команду на сервере через уже аутентифицированное подключение, а для более новой версии предложен ещё один вариант эксплуатации.
🧠 Почему пока рано говорить о "взломе Redis"?
Здесь есть сразу несколько оговорок. Во-первых, одна из найденных проблем уже была известна разработчикам Redis, исправление подготовили ещё до публикации эксперимента.
Во-вторых, второй эксплойт для актуальной версии Redis пока публично не подтверждён командой Redis и не получил официального статуса уязвимости.
И последнее, все цифры (27 минут, 32 агента и степень автономности системы) известны исключительно со слов автора. Полный лог работы агентов и независимое воспроизведение эксперимента не опубликованы.
🔗 GitHub: https://github.com/berabuddies/redis-poc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #KimiK3 #Redis #VulnerabilityResearch #Exploit #AgenticAI #AppSec #SecureTechTalks
На этой неделе по соцсетям разлетелась новость про то, как исследователь Чаофань Шоу обнаружил уязвимость в Redis и подготовил рабочий эксплойт. Анализ производился автоматизировано с помощью Kimi K3, роя из 32 AI-агентов и занял всего за 27 минут.
Код эксперимента уже опубликован на GitHub.
Если это подтвердится независимыми исследователями, мы можем стать свидетелями серьёзного скачка в автоматизации vulnerability research.
По словам автора, агентам дали задачу самостоятельно проанализировать исходный код Redis, найти memory corruption-уязвимость и построить рабочий exploit chain.
В опубликованном репозитории представлены PoC для нескольких версий Redis. Один из них позволяет выполнить произвольную команду на сервере через уже аутентифицированное подключение, а для более новой версии предложен ещё один вариант эксплуатации.
🧠 Почему пока рано говорить о "взломе Redis"?
Здесь есть сразу несколько оговорок. Во-первых, одна из найденных проблем уже была известна разработчикам Redis, исправление подготовили ещё до публикации эксперимента.
Во-вторых, второй эксплойт для актуальной версии Redis пока публично не подтверждён командой Redis и не получил официального статуса уязвимости.
И последнее, все цифры (27 минут, 32 агента и степень автономности системы) известны исключительно со слов автора. Полный лог работы агентов и независимое воспроизведение эксперимента не опубликованы.
🔗 GitHub: https://github.com/berabuddies/redis-poc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #KimiK3 #Redis #VulnerabilityResearch #Exploit #AgenticAI #AppSec #SecureTechTalks
❤1👍1🔥1
🧨 GitHub повышает ставки для багхантеров. AI меняет рынок поиска уязвимостей
Искусственный интеллект заметно ускорил поиск ошибок в программном обеспечении. Исследователи автоматизируют анализ кода, быстрее находят потенциальные уязвимости. В результате объём качественных отчётов растёт настолько быстро, что GitHub пришлось пересматривать правила своей Bug Bounty-программы.
⚙️ VIP только для лучших
GitHub запускает постоянную закрытую VIP-программу для исследователей, которые регулярно отправляют качественные отчёты.
Попасть в неё можно, обнаружив:
🔹 одну критическую уязвимость;
🔹 две высокой степени опасности;
🔹 четыре средней;
🔹 или семь низкой.
После этого выплаты существенно увеличиваются:
➖ Low $1 000 вместо $250;
➖ Medium $7 500 вместо $2 000;
➖ High $20 000 вместо $5 000;
➖ Critical от $30 000 вместо $10 000.
GitHub начинает инвестировать не в количество отчётов, а в долгосрочное сотрудничество с исследователями, которые регулярно находят действительно серьёзные проблемы.
🧠 Не только лишь плюсы
Одновременно GitHub вводит ограничения для новых участников программы через HackerOne. Теперь новичок сможет отправить только четыре первых отчёта, прежде чем получит возможность подавать больше.
Причина очевидна, AI резко снизил стоимость поиска потенциальных уязвимостей. Вместе с качественными исследованиями вырос и поток автоматически сгенерированных, дублирующихся и малополезных репортов. Новые ограничения должны снизить нагрузку на triage-команды и сохранить фокус на действительно важных находках.
🛡️ Новая реальность Bug Bounty
Ещё несколько месяцев назад GitHub устранил критическую RCE-уязвимость, позволявшую одной вредоносной командой "git push" получить полный доступ к миллионам приватных репозиториев. Подобные находки показывают, что стоимость действительно качественного vulnerability research только растёт.
AI не отменит Bug Bounty, он лишь повысит планку. Простые баги всё чаще будут находить агенты, а основная ценность исследователей сместится в сторону сложных цепочек эксплуатации, архитектурных ошибок и нестандартных сценариев атак.
🔗 Источник
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #BugBounty #GitHub #HackerOne #AppSec #VulnerabilityResearch #CyberSecurity #LLM #SecureTechTalks
Искусственный интеллект заметно ускорил поиск ошибок в программном обеспечении. Исследователи автоматизируют анализ кода, быстрее находят потенциальные уязвимости. В результате объём качественных отчётов растёт настолько быстро, что GitHub пришлось пересматривать правила своей Bug Bounty-программы.
⚙️ VIP только для лучших
GitHub запускает постоянную закрытую VIP-программу для исследователей, которые регулярно отправляют качественные отчёты.
Попасть в неё можно, обнаружив:
🔹 одну критическую уязвимость;
🔹 две высокой степени опасности;
🔹 четыре средней;
🔹 или семь низкой.
После этого выплаты существенно увеличиваются:
➖ Low $1 000 вместо $250;
➖ Medium $7 500 вместо $2 000;
➖ High $20 000 вместо $5 000;
➖ Critical от $30 000 вместо $10 000.
GitHub начинает инвестировать не в количество отчётов, а в долгосрочное сотрудничество с исследователями, которые регулярно находят действительно серьёзные проблемы.
🧠 Не только лишь плюсы
Одновременно GitHub вводит ограничения для новых участников программы через HackerOne. Теперь новичок сможет отправить только четыре первых отчёта, прежде чем получит возможность подавать больше.
Причина очевидна, AI резко снизил стоимость поиска потенциальных уязвимостей. Вместе с качественными исследованиями вырос и поток автоматически сгенерированных, дублирующихся и малополезных репортов. Новые ограничения должны снизить нагрузку на triage-команды и сохранить фокус на действительно важных находках.
🛡️ Новая реальность Bug Bounty
Ещё несколько месяцев назад GitHub устранил критическую RCE-уязвимость, позволявшую одной вредоносной командой "git push" получить полный доступ к миллионам приватных репозиториев. Подобные находки показывают, что стоимость действительно качественного vulnerability research только растёт.
AI не отменит Bug Bounty, он лишь повысит планку. Простые баги всё чаще будут находить агенты, а основная ценность исследователей сместится в сторону сложных цепочек эксплуатации, архитектурных ошибок и нестандартных сценариев атак.
🔗 Источник
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #BugBounty #GitHub #HackerOne #AppSec #VulnerabilityResearch #CyberSecurity #LLM #SecureTechTalks
❤1👍1
🧨 Дообучение LLM кибербезопасности может сделать ответы модели хуже
Есть очевидная идея взять небольшую модель с открытыми весами, дообучить её на security-данных и получить собственного специалиста по кибербезопасности. Однако этот подход стоит применять осторожно.
Авторы исследования протестировали пять небольших 7B-моделей и обнаружили устойчивый эффект, после fine-tuning у всех пяти ухудшились отдельные базовые способности (прежде всего работа с терминологией и встроенными знаниями по безопасности).
⚙️ Проблема не всегда там, где вы её ищете
Авторы предлагают сначала диагностировать модель с помощью framework FiT (Fine-tuning Impact Test).
Он разделяет способности модели на три независимых слоя:
🔹 Vocabulary: понимает ли модель security-термины и их значения;
🔹 Knowledge: действительно ли она знает предметную область;
🔹 Contextualization: умеет ли использовать внешний контекст, например документы из RAG, для решения задачи.
🧠 Неожиданный эффект
В экспериментах fine-tuning иногда резко ухудшал результаты на вопросах, где модель должна была отвечать без внешней информации.
У одной из протестированных моделей accuracy на knowledge-задачах упала с 0,71 до 0,08. На другой с 0,72 до 0,12. На первый взгляд кажется, что модель просто «забыла» знания, но затем исследователи подключили RAG и картина изменилась. Когда необходимые сведения передавались модели непосредственно в контексте, качество оставалось высоким.
То есть fine-tuning не обязательно уничтожил знания. Он мог изменить поведение модели при отсутствии внешнего контекста.
📉 Другие изменения
После разных режимов fine-tuning менялся даже рейтинг моделей. Для одного типа дообучения относительный порядок моделей в основном сохранялся. Для другого практически перевернулся.
Получается интересный инженерный сценарий, модель, которая до fine-tuning была лучшим кандидатом для security-задач, после обучения может стать провальным выбором.
🛡️ RAG или Fine-tuning?
Главный практический вывод исследования - не бросаться в fine-tuning только потому, что модель плохо отвечает на security-вопросы.
Если проблема заключается в отсутствии актуальных CVE, внутренних документов, threat intelligence или другой постоянно меняющейся информации, RAG может оказаться более подходящим решением.
🔗 Исследование: https://arxiv.org/abs/2607.18725
🔗 Код: https://github.com/shaswata09/FiT
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #RAG #FineTuning #AISecurity #ThreatIntelligence #CyberSecurity #AppSec #SecureTechTalks
Есть очевидная идея взять небольшую модель с открытыми весами, дообучить её на security-данных и получить собственного специалиста по кибербезопасности. Однако этот подход стоит применять осторожно.
Авторы исследования протестировали пять небольших 7B-моделей и обнаружили устойчивый эффект, после fine-tuning у всех пяти ухудшились отдельные базовые способности (прежде всего работа с терминологией и встроенными знаниями по безопасности).
⚙️ Проблема не всегда там, где вы её ищете
Авторы предлагают сначала диагностировать модель с помощью framework FiT (Fine-tuning Impact Test).
Он разделяет способности модели на три независимых слоя:
🔹 Vocabulary: понимает ли модель security-термины и их значения;
🔹 Knowledge: действительно ли она знает предметную область;
🔹 Contextualization: умеет ли использовать внешний контекст, например документы из RAG, для решения задачи.
🧠 Неожиданный эффект
В экспериментах fine-tuning иногда резко ухудшал результаты на вопросах, где модель должна была отвечать без внешней информации.
У одной из протестированных моделей accuracy на knowledge-задачах упала с 0,71 до 0,08. На другой с 0,72 до 0,12. На первый взгляд кажется, что модель просто «забыла» знания, но затем исследователи подключили RAG и картина изменилась. Когда необходимые сведения передавались модели непосредственно в контексте, качество оставалось высоким.
То есть fine-tuning не обязательно уничтожил знания. Он мог изменить поведение модели при отсутствии внешнего контекста.
📉 Другие изменения
После разных режимов fine-tuning менялся даже рейтинг моделей. Для одного типа дообучения относительный порядок моделей в основном сохранялся. Для другого практически перевернулся.
Получается интересный инженерный сценарий, модель, которая до fine-tuning была лучшим кандидатом для security-задач, после обучения может стать провальным выбором.
🛡️ RAG или Fine-tuning?
Главный практический вывод исследования - не бросаться в fine-tuning только потому, что модель плохо отвечает на security-вопросы.
Если проблема заключается в отсутствии актуальных CVE, внутренних документов, threat intelligence или другой постоянно меняющейся информации, RAG может оказаться более подходящим решением.
🔗 Исследование: https://arxiv.org/abs/2607.18725
🔗 Код: https://github.com/shaswata09/FiT
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #RAG #FineTuning #AISecurity #ThreatIntelligence #CyberSecurity #AppSec #SecureTechTalks
👍1
🧨 CISA выпустила инструкцию по защите Open Source
CISA совместно с другими государственными и отраслевыми организациями США выпустила практическое руководство, которое показывает, как защищать OSS на этапе разработки.
⚙️ Что рекомендуют?
Вместо очередного списка "лучших практик" документ разбивает защиту на конкретные инженерные меры:
🔹 использовать многофакторную аутентификацию и защищать учётные записи сопровождающих;
🔹 подписывать релизы и проверять происхождение артефактов;
🔹 автоматизировать поиск уязвимостей и анализ зависимостей;
🔹 публиковать SBOM для выпускаемых продуктов;
🔹 заранее определить процесс coordinated vulnerability disclosure и безопасного исправления уязвимостей;
🔹 регулярно проводить code review и защищать CI/CD-пайплайн.
🧠 Саммери документа
Сегодня атакуют уже не только код, компрометировать можно GitHub-аккаунт мейнтейнера, систему сборки, пакетный репозиторий, процесс публикации релизов или механизм обновлений. Безопасность OSS должна рассматриваться, как защита всей цепочки разработки, а не отдельных библиотек.
🔗 Гайд: https://www.cisa.gov/sites/default/files/2026-07/open-source-software-security-principles.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OpenSource #SupplyChainSecurity #CISA #SBOM #SecureByDesign #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
CISA совместно с другими государственными и отраслевыми организациями США выпустила практическое руководство, которое показывает, как защищать OSS на этапе разработки.
⚙️ Что рекомендуют?
Вместо очередного списка "лучших практик" документ разбивает защиту на конкретные инженерные меры:
🔹 использовать многофакторную аутентификацию и защищать учётные записи сопровождающих;
🔹 подписывать релизы и проверять происхождение артефактов;
🔹 автоматизировать поиск уязвимостей и анализ зависимостей;
🔹 публиковать SBOM для выпускаемых продуктов;
🔹 заранее определить процесс coordinated vulnerability disclosure и безопасного исправления уязвимостей;
🔹 регулярно проводить code review и защищать CI/CD-пайплайн.
🧠 Саммери документа
Сегодня атакуют уже не только код, компрометировать можно GitHub-аккаунт мейнтейнера, систему сборки, пакетный репозиторий, процесс публикации релизов или механизм обновлений. Безопасность OSS должна рассматриваться, как защита всей цепочки разработки, а не отдельных библиотек.
🔗 Гайд: https://www.cisa.gov/sites/default/files/2026-07/open-source-software-security-principles.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OpenSource #SupplyChainSecurity #CISA #SBOM #SecureByDesign #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
👍1
🧨 Black Hat USA 2026: какой будет кибербезопасность уже завтра?
Каждый август Black Hat становится местом, где впервые публично показывают исследования, которые через несколько месяцев превращаются в реальные инструменты атак и защиты. В этом году главная тема конференции, спойлер,AI-агенты .
Практически в каждом треке обсуждали уже не отдельные LLM, а автономные системы, способные самостоятельно искать уязвимости, атаковать инфраструктуру и принимать решения.
⚙️ Главные тренды Black Hat 2026
🔹 AI выходит в offensive security
Исследователи показали новые способы эксплуатации агентных систем, атак на AI-помощников разработчиков и автономный поиск цепочек эксплуатации.
🔹 GitHub становится новой конечной точкой
Отдельные доклады были посвящены обнаружению компрометации по собственным событиям GitHub, защите CI/CD и борьбе с атаками на цепочки поставок ПО.
🔹 Cloud и Agent Security окончательно объединились
В центре внимания оказались атаки на Cloudflare Workers, Kubernetes, MCP и облачные AI-платформы, где компрометация агента уже означает компрометацию инфраструктуры.
🔹 Криптография снова в центре внимания
На конференции представили новые исследования криптоанализа, безопасности библиотек шифрования и практических атак на современные криптографические реализации.
🔗 Конференция: https://www.blackhat.com/us-26/
🔗 Arsenal (инструменты конференции): https://www.blackhat.com/us-26/arsenal-overview.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #BlackHat #BlackHat2026 #AI #LLM #AgenticAI #AISecurity #AppSec #CyberSecurity #SecureTechTalks
Каждый август Black Hat становится местом, где впервые публично показывают исследования, которые через несколько месяцев превращаются в реальные инструменты атак и защиты. В этом году главная тема конференции, спойлер,
Практически в каждом треке обсуждали уже не отдельные LLM, а автономные системы, способные самостоятельно искать уязвимости, атаковать инфраструктуру и принимать решения.
⚙️ Главные тренды Black Hat 2026
🔹 AI выходит в offensive security
Исследователи показали новые способы эксплуатации агентных систем, атак на AI-помощников разработчиков и автономный поиск цепочек эксплуатации.
🔹 GitHub становится новой конечной точкой
Отдельные доклады были посвящены обнаружению компрометации по собственным событиям GitHub, защите CI/CD и борьбе с атаками на цепочки поставок ПО.
🔹 Cloud и Agent Security окончательно объединились
В центре внимания оказались атаки на Cloudflare Workers, Kubernetes, MCP и облачные AI-платформы, где компрометация агента уже означает компрометацию инфраструктуры.
🔹 Криптография снова в центре внимания
На конференции представили новые исследования криптоанализа, безопасности библиотек шифрования и практических атак на современные криптографические реализации.
🔗 Конференция: https://www.blackhat.com/us-26/
🔗 Arsenal (инструменты конференции): https://www.blackhat.com/us-26/arsenal-overview.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #BlackHat #BlackHat2026 #AI #LLM #AgenticAI #AISecurity #AppSec #CyberSecurity #SecureTechTalks
👍2
🧨 CyberForge: AI-агентов учат искать уязвимости на настоящем коде
Реальных CVE не так много, их сложно воспроизводить, а превращение каждой уязвимости в полноценную тренировочную задачу требует ручной работы.
Исследователи из NIST и University of Maryland предложили новый подход, CyberForge.
⚙️ Уязвимости создаются искусственно
CyberForge берёт реальные C/C++ проекты из OSS-Fuzz и специально вносит в них небольшие изменения, превращающие обычный код в уязвимый.
Система принимает уязвимость только если одновременно выполняются два условия:
🔹 исходные unit-тесты продолжают проходить;
🔹 Proof-of-Vulnerability срабатывает на изменённой версии, но не срабатывает на оригинальной.
Полученная уязвимость должна оставаться скрытой при обычной работе, но реально эксплуатироваться специально подготовленным входом.
🧠 Результаты
CyberForge создал:
➖ 1 034 подтверждённые уязвимости;
➖ 80 реальных open-source проектов;
➖ 63 категории CWE.
В 1 025 из 1 034 кейсах изменяли только один файл, а в 944 всего один участок кода. По характеру изменений полученный датасет оказался сопоставим с реальными CVE-патчами.
🔥 И улучшение AI-агентов
Исследователи собрали на этих задачах trajectories от более сильных моделей и использовали их для fine-tuning Gemma 4.
На SEC-bench результат 31B-модели вырос на 14,7%.
Кроме того, модели, обученные исключительно на C/C++, улучшили результаты и на другом наборе задач с Python, JavaScript и Go.
🛡️ Меняем подход
Получается новый цикл обучения security-агентов:
реальный репозиторий → синтетическая уязвимость → автоматическая проверка → задача для AI → обучение → более сильный security-agent.
P.S. Созданные уязвимости являются синтетическими изменениями open-source кода и не представляют собой новые zero-day в продуктивных системах.
🔗 Исследование: https://arxiv.org/abs/2608.06471
🔗 Проект: https://cyb3rforge.github.io
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AppSec #VulnerabilityResearch #CyberSecurity #OSSFuzz #DevSecOps #SecureTechTalks
Реальных CVE не так много, их сложно воспроизводить, а превращение каждой уязвимости в полноценную тренировочную задачу требует ручной работы.
Исследователи из NIST и University of Maryland предложили новый подход, CyberForge.
⚙️ Уязвимости создаются искусственно
CyberForge берёт реальные C/C++ проекты из OSS-Fuzz и специально вносит в них небольшие изменения, превращающие обычный код в уязвимый.
Система принимает уязвимость только если одновременно выполняются два условия:
🔹 исходные unit-тесты продолжают проходить;
🔹 Proof-of-Vulnerability срабатывает на изменённой версии, но не срабатывает на оригинальной.
Полученная уязвимость должна оставаться скрытой при обычной работе, но реально эксплуатироваться специально подготовленным входом.
🧠 Результаты
CyberForge создал:
➖ 1 034 подтверждённые уязвимости;
➖ 80 реальных open-source проектов;
➖ 63 категории CWE.
В 1 025 из 1 034 кейсах изменяли только один файл, а в 944 всего один участок кода. По характеру изменений полученный датасет оказался сопоставим с реальными CVE-патчами.
🔥 И улучшение AI-агентов
Исследователи собрали на этих задачах trajectories от более сильных моделей и использовали их для fine-tuning Gemma 4.
На SEC-bench результат 31B-модели вырос на 14,7%.
Кроме того, модели, обученные исключительно на C/C++, улучшили результаты и на другом наборе задач с Python, JavaScript и Go.
🛡️ Меняем подход
Получается новый цикл обучения security-агентов:
реальный репозиторий → синтетическая уязвимость → автоматическая проверка → задача для AI → обучение → более сильный security-agent.
P.S. Созданные уязвимости являются синтетическими изменениями open-source кода и не представляют собой новые zero-day в продуктивных системах.
🔗 Исследование: https://arxiv.org/abs/2608.06471
🔗 Проект: https://cyb3rforge.github.io
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AppSec #VulnerabilityResearch #CyberSecurity #OSSFuzz #DevSecOps #SecureTechTalks
👍1
🧨 AI научился искать уязвимости. Теперь security-команды тонут в его находках
AI-агент может найти CVE, построить PoC и написать убедительный отчёт, однако весомая часть таких уязвимостей существует только на бумаге.
⚙️ AI slop
Для данного явления появился свой термир - AI slop. Это отчёты с несуществующими CVE, невозможными цепочками эксплуатации, неработающими PoC и патчами, которые не устраняют проблему.
Особенно раздражает, когда модель уверенно видит уязвимость в знакомых конструкциях вроде "malloc" или "memcpy", хотя конкретный код безопасен.
🔥 Когда AI превращается в DoS
По данным исследования 20% обращений через HackerOne к середине 2025 года были низкокачественным AI slop. Валидными признавались примерно 5%.
Каждый отчёт приходится проверять человеку. Чем дешевле становится генерация находок, тем дороже их triage.
🛡️ Отчёт больше не считается доказательством
Современные реалии заставляют перестраивать pipeline, чтобы LLM начинали с гипотезы, а заканчивали PoC и triage.
Модель дольжна формировать подозрение. Инструменты проверять data flow и пытаться воспроизвести эксплуатацию. PoC должен реально работать.
Только RAG здесь недостаточно, наличие похожего CVE ещё не доказывает уязвимость конкретного кода.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AISecurity #AppSec #VulnerabilityResearch #BugBounty #DevSecOps #CyberSecurity #SecureTechTalks
AI-агент может найти CVE, построить PoC и написать убедительный отчёт, однако весомая часть таких уязвимостей существует только на бумаге.
⚙️ AI slop
Для данного явления появился свой термир - AI slop. Это отчёты с несуществующими CVE, невозможными цепочками эксплуатации, неработающими PoC и патчами, которые не устраняют проблему.
Особенно раздражает, когда модель уверенно видит уязвимость в знакомых конструкциях вроде "malloc" или "memcpy", хотя конкретный код безопасен.
🔥 Когда AI превращается в DoS
По данным исследования 20% обращений через HackerOne к середине 2025 года были низкокачественным AI slop. Валидными признавались примерно 5%.
Каждый отчёт приходится проверять человеку. Чем дешевле становится генерация находок, тем дороже их triage.
🛡️ Отчёт больше не считается доказательством
Современные реалии заставляют перестраивать pipeline, чтобы LLM начинали с гипотезы, а заканчивали PoC и triage.
Модель дольжна формировать подозрение. Инструменты проверять data flow и пытаться воспроизвести эксплуатацию. PoC должен реально работать.
Только RAG здесь недостаточно, наличие похожего CVE ещё не доказывает уязвимость конкретного кода.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AISecurity #AppSec #VulnerabilityResearch #BugBounty #DevSecOps #CyberSecurity #SecureTechTalks
👍1
🧨 Agentic Software Development: практический гайд по разработке с AI агентами
Cleverbit выпустили Agentic Software Development Field Guide для CTO, engineering managers и технических лидеров.
Внутри:
🔹 как задавать агенту точные спецификации и контекст;
🔹 как выстроить verification и risk based review;
🔹 как проводить threat modeling самих AI инструментов;
🔹 как обнаруживать расхождения между намерением разработчика и результатом агента;
🔹 какие метрики использовать для оценки скорости и качества AI разработки.
Особенно полезен раздел про разделение builder и verifier агентов и автоматизированную проверку результата.
📥 Скачать PDF:
Agentic Software Development Field Guide
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AgenticAI #DevSecOps #AppSec #AISecurity #SoftwareDevelopment #CyberSecurity #SecureTechTalks
Cleverbit выпустили Agentic Software Development Field Guide для CTO, engineering managers и технических лидеров.
Внутри:
🔹 как задавать агенту точные спецификации и контекст;
🔹 как выстроить verification и risk based review;
🔹 как проводить threat modeling самих AI инструментов;
🔹 как обнаруживать расхождения между намерением разработчика и результатом агента;
🔹 какие метрики использовать для оценки скорости и качества AI разработки.
Особенно полезен раздел про разделение builder и verifier агентов и автоматизированную проверку результата.
📥 Скачать PDF:
Agentic Software Development Field Guide
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AgenticAI #DevSecOps #AppSec #AISecurity #SoftwareDevelopment #CyberSecurity #SecureTechTalks
👍1
🧨 Немного про JWT токен
JWT часто воспринимают как зашифрованный ключ для доступа к API. Но еа практике это скорее подписанный JSON, упакованный в три части: header, payload, signature.
Первые две кодируются Base64URL. Берём обычный JWT и декодируем:
"{"alg":"HS256","typ":"JWT"}"
"{"sub":"12345","role":"admin","exp":1710086400}"
Всё содержимое перед глазами.
🔐 Зачем тогда нужна подпись?
Ключ используется для проверки подписи. Сервер убеждается, что токен выпустил доверенный источник и его содержимое не изменяли.
Поэтому пароль или API ключ внутри JWT хранить бессмысленно. Подпись их не спрячeт. Для шифрования существует JWE.
⚠️ Проверка токена
Серверу мало убедиться, что подпись правильная. Нужно проверить:
🔹 кто выпустил токен: "iss";
🔹 для какого сервиса он предназначен: "aud";
🔹 кому он выдан: "sub";
🔹 когда начинает и заканчивает действовать: "nbf", "iat", "exp";
🔹 какие права даёт: "scope", роли;
🔹 какой алгоритм разрешён сервером.
Вполне реальна ситуация, когда токен криптографически валиден, но использовать его здесь вообще не должны были.
JWT не опасен сам по себе. Опасна уверенность, что валидная подпись означает валидный доступ.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #JWT #AppSec #WebSecurity #Authentication #API #DevSecOps #CyberSecurity #InfoSec #SecureTechTalks
JWT часто воспринимают как зашифрованный ключ для доступа к API. Но еа практике это скорее подписанный JSON, упакованный в три части: header, payload, signature.
Первые две кодируются Base64URL. Берём обычный JWT и декодируем:
"{"alg":"HS256","typ":"JWT"}"
"{"sub":"12345","role":"admin","exp":1710086400}"
Всё содержимое перед глазами.
🔐 Зачем тогда нужна подпись?
Ключ используется для проверки подписи. Сервер убеждается, что токен выпустил доверенный источник и его содержимое не изменяли.
Поэтому пароль или API ключ внутри JWT хранить бессмысленно. Подпись их не спрячeт. Для шифрования существует JWE.
⚠️ Проверка токена
Серверу мало убедиться, что подпись правильная. Нужно проверить:
🔹 кто выпустил токен: "iss";
🔹 для какого сервиса он предназначен: "aud";
🔹 кому он выдан: "sub";
🔹 когда начинает и заканчивает действовать: "nbf", "iat", "exp";
🔹 какие права даёт: "scope", роли;
🔹 какой алгоритм разрешён сервером.
Вполне реальна ситуация, когда токен криптографически валиден, но использовать его здесь вообще не должны были.
JWT не опасен сам по себе. Опасна уверенность, что валидная подпись означает валидный доступ.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #JWT #AppSec #WebSecurity #Authentication #API #DevSecOps #CyberSecurity #InfoSec #SecureTechTalks
👍1
🧨 GitSpawn: AI агент может запустить код из открытой папки
Представьте, коллега прислал вам проект в ZIP. Вы распаковали его и открыли папку через Claude Code, чтобы AI посмотрел код. Код из проекта сразу выполняется на вашем компьютере.
Данный класс атак обнаружили исследователи Manifold Security. Они нашли 8 уязвимых сценариев в 7 AI coding agents: Claude Code, Codex, Cursor, Goose, Qwen Code, Grok Build и Hermes Agent.
⚙️ Git превращается в точку атаки
AI coding agents постоянно собирают контекст проекта. Для этого они запускают обычные команды: "git status", "git diff" и т.д.. Проблема в том, что Git умеет читать конфигурацию самого репозитория из ".git/config".
В исследованном сценарии там может находиться настройка "core.fsmonitor", указывающая Git на внешнюю программу. Когда агент запускает "git status", Git обновляет индекс и может автоматически вызвать указанный helper. Команда выполняется с правами пользователя и вне sandbox AI агента.
🔥 Все происходит до prompt
На некоторых агентах исполнение кода происходило ещё до появления workspace trust prompt. Для Qwen Code исследователи зафиксировали выполнение до аутентификации, у Goose payload срабатывал до обращения к модели, а Grok Build мог запустить его уже при первом вводе текста. Защитный диалог агента просто не успевает стать границей безопасности.
🧨 Что получает атакующий?
Если выполнение произошло с правами разработчика, последствия зависят от окружения. Под угрозой могут оказаться SSH ключи, cloud credentials, токены из shell окружения, другие репозитории на диске и доступ к самой машине.
Поэтому GitSpawn интересен как класс уязвимостей. Атакующему достаточно добиться того, чтобы подготовленный репозиторий оказался на компьютере разработчика.
🔗 Источник: Manifold Security
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AI #GitSpawn #ClaudeCode #Git #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
Представьте, коллега прислал вам проект в ZIP. Вы распаковали его и открыли папку через Claude Code, чтобы AI посмотрел код. Код из проекта сразу выполняется на вашем компьютере.
Данный класс атак обнаружили исследователи Manifold Security. Они нашли 8 уязвимых сценариев в 7 AI coding agents: Claude Code, Codex, Cursor, Goose, Qwen Code, Grok Build и Hermes Agent.
⚙️ Git превращается в точку атаки
AI coding agents постоянно собирают контекст проекта. Для этого они запускают обычные команды: "git status", "git diff" и т.д.. Проблема в том, что Git умеет читать конфигурацию самого репозитория из ".git/config".
В исследованном сценарии там может находиться настройка "core.fsmonitor", указывающая Git на внешнюю программу. Когда агент запускает "git status", Git обновляет индекс и может автоматически вызвать указанный helper. Команда выполняется с правами пользователя и вне sandbox AI агента.
🔥 Все происходит до prompt
На некоторых агентах исполнение кода происходило ещё до появления workspace trust prompt. Для Qwen Code исследователи зафиксировали выполнение до аутентификации, у Goose payload срабатывал до обращения к модели, а Grok Build мог запустить его уже при первом вводе текста. Защитный диалог агента просто не успевает стать границей безопасности.
🧨 Что получает атакующий?
Если выполнение произошло с правами разработчика, последствия зависят от окружения. Под угрозой могут оказаться SSH ключи, cloud credentials, токены из shell окружения, другие репозитории на диске и доступ к самой машине.
Поэтому GitSpawn интересен как класс уязвимостей. Атакующему достаточно добиться того, чтобы подготовленный репозиторий оказался на компьютере разработчика.
🔗 Источник: Manifold Security
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AI #GitSpawn #ClaudeCode #Git #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
👍1
🧨 Rubrik разрешила Claude атаковать корпоративный код
Rubrik представила Code Guardian, новый сервис для автоматического red teaming исходного кода на базе Claude Mythos 5.
Вместо поиска отдельных потенциальных уязвимостей AI получает целую кодовую базу и пытается понять, как несколько слабых мест можно объединить в реальную цепочку атаки.
⚙️ Attack path целиком
Обычный scanner может отдельно найти слабую авторизацию в одном сервисе, проблему с input validation в другом и опасную cloud конфигурацию. Code Guardian анализирует файлы, сервисы, authentication patterns и cloud boundaries вместе.
Задача Claude найти слабости, связать их в attack chain затем проверить exploitability, оценить blast radius и определить приоритет. Результатом должен стать уже проверенный путь атаки, который имеет смысл исправлять.
🔬 Claude получает отдельную копию кода
Для такого анализа Rubrik использует immutable air gapped копию репозитория.
Claude Mythos 5 запускается через специальный security harness и может агрессивно исследовать код, не взаимодействуя с production и live repository.
🔥 От находки сразу к исправлению
Подтверждённые критические проблемы ранжируются по exploitability, blast radius и business criticality. Далее Code Guardian может создать Jira или GitHub issue и добавить рекомендации по исправлению на уровне конкретных файлов.
Rubrik уже прогнала систему на собственной кодовой базе и утверждает, что Code Guardian обнаружил больше проблем, чем традиционные code scanning tools.
Публичных цифр сравнения, к сожалению, компания пока не приводит.
🔗 Источник: Rubrik
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AI #Rubrik #Claude #Anthropic #AppSec #RedTeam #CyberSecurity #SecureTechTalks
Rubrik представила Code Guardian, новый сервис для автоматического red teaming исходного кода на базе Claude Mythos 5.
Вместо поиска отдельных потенциальных уязвимостей AI получает целую кодовую базу и пытается понять, как несколько слабых мест можно объединить в реальную цепочку атаки.
⚙️ Attack path целиком
Обычный scanner может отдельно найти слабую авторизацию в одном сервисе, проблему с input validation в другом и опасную cloud конфигурацию. Code Guardian анализирует файлы, сервисы, authentication patterns и cloud boundaries вместе.
Задача Claude найти слабости, связать их в attack chain затем проверить exploitability, оценить blast radius и определить приоритет. Результатом должен стать уже проверенный путь атаки, который имеет смысл исправлять.
🔬 Claude получает отдельную копию кода
Для такого анализа Rubrik использует immutable air gapped копию репозитория.
Claude Mythos 5 запускается через специальный security harness и может агрессивно исследовать код, не взаимодействуя с production и live repository.
🔥 От находки сразу к исправлению
Подтверждённые критические проблемы ранжируются по exploitability, blast radius и business criticality. Далее Code Guardian может создать Jira или GitHub issue и добавить рекомендации по исправлению на уровне конкретных файлов.
Rubrik уже прогнала систему на собственной кодовой базе и утверждает, что Code Guardian обнаружил больше проблем, чем традиционные code scanning tools.
Публичных цифр сравнения, к сожалению, компания пока не приводит.
🔗 Источник: Rubrik
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AI #Rubrik #Claude #Anthropic #AppSec #RedTeam #CyberSecurity #SecureTechTalks
👍1
🧨 GitHub отдал fuzzing AI агенту
GitHub Security Lab открыла инструмент, который автоматизирует fuzzing C и C++ проектов. AI агент изучает репозиторий, выбирает функции, пишет fuzz harness, собирает его, запускает AFL++, анализирует coverage и сам решает, как добраться до непройденных веток.
⚙️ Как устроен цикл
Taskflow Agent управляет процессом через YAML сценарии и MCP tools. LLM принимает решения, а реальные операции выполняют AFL++ и clang.
Каждый harness собирается в двух вариантах. Первый через "afl clang lto" с AddressSanitizer и UndefinedBehaviorSanitizer для поиска ошибок. Второй через clang с "fprofile instr generate" и "fcoverage mapping" для измерения покрытия.
После запуска агент получает непройденные ветки и выбирает следующий шаг: изменить harness, создать новый seed, добавить значения в AFL dictionary или пропустить бесперспективный участок.
Время fuzzing постепенно усваивается: 30, 60...960.
Если две итерации подряд дают меньше 1 процентного пункта нового line coverage, агент фиксирует plateau и останавливает цикл.
💣 Crash тоже уходит к AI
Найденные crashes сохраняются и дедуплицируются. Затем агент анализирует потенциальную эксплуатируемость и формирует отчёт об уязвимости с рекомендациями по исправлению.
За процессом можно наблюдать через dashboard: coverage каждого harness, динамика покрытия, crashes и история итераций.
⚠️ Нюанс
"afl fuzz", clang и команды, выбранные LLM, выполняются непосредственно в системе. Поэтому вредоносный репозиторий потенциально может использовать prompt injection, чтобы заставить агента выполнить нежелательные команды.
GitHub рекомендует запускать систему внутри disposable Codespace или VM с ограниченными правами и сетевым доступом.
AI ищет уязвимости в коде, а код может атаковать самого AI исследователя.
🔗 Источник: GitHub Security Lab
🔗 GitHub: seclab taskflows fuzzing
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #Fuzzing #AIAgents #AFL #MCP #GitHubSecurityLab #AppSec #VulnerabilityResearch #SecureTechTalks
GitHub Security Lab открыла инструмент, который автоматизирует fuzzing C и C++ проектов. AI агент изучает репозиторий, выбирает функции, пишет fuzz harness, собирает его, запускает AFL++, анализирует coverage и сам решает, как добраться до непройденных веток.
⚙️ Как устроен цикл
Taskflow Agent управляет процессом через YAML сценарии и MCP tools. LLM принимает решения, а реальные операции выполняют AFL++ и clang.
Каждый harness собирается в двух вариантах. Первый через "afl clang lto" с AddressSanitizer и UndefinedBehaviorSanitizer для поиска ошибок. Второй через clang с "fprofile instr generate" и "fcoverage mapping" для измерения покрытия.
После запуска агент получает непройденные ветки и выбирает следующий шаг: изменить harness, создать новый seed, добавить значения в AFL dictionary или пропустить бесперспективный участок.
Время fuzzing постепенно усваивается: 30, 60...960.
Если две итерации подряд дают меньше 1 процентного пункта нового line coverage, агент фиксирует plateau и останавливает цикл.
💣 Crash тоже уходит к AI
Найденные crashes сохраняются и дедуплицируются. Затем агент анализирует потенциальную эксплуатируемость и формирует отчёт об уязвимости с рекомендациями по исправлению.
За процессом можно наблюдать через dashboard: coverage каждого harness, динамика покрытия, crashes и история итераций.
⚠️ Нюанс
"afl fuzz", clang и команды, выбранные LLM, выполняются непосредственно в системе. Поэтому вредоносный репозиторий потенциально может использовать prompt injection, чтобы заставить агента выполнить нежелательные команды.
GitHub рекомендует запускать систему внутри disposable Codespace или VM с ограниченными правами и сетевым доступом.
AI ищет уязвимости в коде, а код может атаковать самого AI исследователя.
🔗 Источник: GitHub Security Lab
🔗 GitHub: seclab taskflows fuzzing
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #Fuzzing #AIAgents #AFL #MCP #GitHubSecurityLab #AppSec #VulnerabilityResearch #SecureTechTalks
🧨 MCP сервер может украсть OAuth токен через настоящий экран входа
В официальном MCP Python SDK нашли OAuth уязвимость, позволяющую вредоносному MCP серверу перехватить
⚙️ Как ломается OAuth
При подключении MCP клиент должен определить authorization server и проверить его
В SDK существовал fallback сценарий. Вредоносный MCP сервер возвращает
Атакующий указывает настоящий Identity Provider в качестве
Пользователь попадает на настоящий экран входа и проходит обычную авторизацию. Identity Provider возвращает валидный authorization code.
После этого SDK отправляет на подменённый
🔑
🎫 authorization code
🔐 PKCE
Атакующий получает полный набор данных, необходимый для завершения OAuth flow.
💣 PKCE уже не спасает
Полученные code,
Cycode продемонстрировали эту цепочку end to end против реального authorization server с включённым PKCE.
Для AI агентов появляется ещё один сценарий. Prompt injection потенциально способен направить агента к вредоносному MCP серверу, хотя пользователь сам его не выбирал.
🔗 Исследование: Cycode
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #MCP #OAuth #AIAgents #AccountTakeover #PKCE #LLMSecurity #AppSec #SecureTechTalks
В официальном MCP Python SDK нашли OAuth уязвимость, позволяющую вредоносному MCP серверу перехватить
client_secret, authorization code и даже PKCE code_verifier.⚙️ Как ломается OAuth
При подключении MCP клиент должен определить authorization server и проверить его
issuer.В SDK существовал fallback сценарий. Вредоносный MCP сервер возвращает
404 на запрос современного discovery. Клиент переключается на старый механизм и получает OAuth metadata непосредственно от MCP сервера. Проверка issuer в этом сценарии пропускалась.Атакующий указывает настоящий Identity Provider в качестве
authorization endpoint, а собственный сервер в качестве token endpoint.Пользователь попадает на настоящий экран входа и проходит обычную авторизацию. Identity Provider возвращает валидный authorization code.
После этого SDK отправляет на подменённый
token endpoint сразу три компонента:🔑
client_secret🎫 authorization code
🔐 PKCE
code_verifierАтакующий получает полный набор данных, необходимый для завершения OAuth flow.
💣 PKCE уже не спасает
Полученные code,
code_verifier и client_secret отправляются настоящему authorization server. В ответ атакующий получает легитимный access token с правами жертвы.Cycode продемонстрировали эту цепочку end to end против реального authorization server с включённым PKCE.
Для AI агентов появляется ещё один сценарий. Prompt injection потенциально способен направить агента к вредоносному MCP серверу, хотя пользователь сам его не выбирал.
🔗 Исследование: Cycode
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #MCP #OAuth #AIAgents #AccountTakeover #PKCE #LLMSecurity #AppSec #SecureTechTalks
🧨 AI сокращает путь от найденной уязвимости до реальной атаки
Google Threat Intelligence Group опубликовала статистику за первые восемь месяцев 2026 года. Количество раскрываемых уязвимостей выросло с 5 045 в январе до 10 740 в августе.
Среди багов, которые Google идентифицировала как вероятно обнаруженные с помощью AI, 50% позволяют удаленно исполнять код.
🤖 AI хорошо ищет то, что интересно атакующим
Хороший пример уже появился в реальной инфраструктуре. AI агент Hacktron автономно обнаружил CVE 2026 1731 в BeyondTrust Remote Support и Privileged Remote Access. Это критическая pre auth command injection, позволяющая удалённо выполнять команды без аутентификации.
Через 4 дня после публичного раскрытия Google уже наблюдала первую группу, эксплуатирующую уязвимость. Через 7 дней таких групп было уже шесть.
После проникновения атакующие повышали привилегии, выводили данные, устанавливали SPARKRAT, SNOWLIGHT и майнеры.
🔥 AI ускоряет обе стороны
За январь и август GTIG зафиксировала 141 уязвимость, реально эксплуатировавшуюся в атаках. За весь 2025 год таких было 127.
Среднее количество эксплуатируемых уязвимостей выросло с 10,5 до 18 в месяц.
При этом взрывного роста zero day Google пока не видит. Значительная часть ускорения связана с уже раскрытыми уязвимостями.
LLM позволяют быстрее анализировать:
🔹 изменения между версиями продукта
🔹 опубликованные патчи
🔹 описания уязвимостей
🔹 готовые PoC
🔹 похожие участки кода
Патч становится исходными данными для автоматизированного поиска способа эксплуатации.
📊 10 740 CVE звучит страшнее, чем есть на самом деле
Google отдельно предупреждает, что количество CVE нельзя напрямую превращать в оценку угрозы. Из всех раскрытых в 2026 году уязвимостей эксплуатацию в реальных атаках наблюдали только для 0,23%, примерно одной из 431.
Для security команд становится важнее насколько быстро критическая уязвимость проходит путь от disclosure до рабочего exploit.
В случае BeyondTrust AI нашёл баг, а атакующим понадобилось всего несколько дней, чтобы превратить опубликованную уязвимость в initial access.
Окно между CVE и атакой продолжает сокращаться.
🔗 Источник: Google Threat Intelligence Group
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AI #VulnerabilityResearch #CVE #RCE #LLM #ThreatIntelligence #AppSec #SecureTechTalks
Google Threat Intelligence Group опубликовала статистику за первые восемь месяцев 2026 года. Количество раскрываемых уязвимостей выросло с 5 045 в январе до 10 740 в августе.
Среди багов, которые Google идентифицировала как вероятно обнаруженные с помощью AI, 50% позволяют удаленно исполнять код.
🤖 AI хорошо ищет то, что интересно атакующим
Хороший пример уже появился в реальной инфраструктуре. AI агент Hacktron автономно обнаружил CVE 2026 1731 в BeyondTrust Remote Support и Privileged Remote Access. Это критическая pre auth command injection, позволяющая удалённо выполнять команды без аутентификации.
Через 4 дня после публичного раскрытия Google уже наблюдала первую группу, эксплуатирующую уязвимость. Через 7 дней таких групп было уже шесть.
После проникновения атакующие повышали привилегии, выводили данные, устанавливали SPARKRAT, SNOWLIGHT и майнеры.
🔥 AI ускоряет обе стороны
За январь и август GTIG зафиксировала 141 уязвимость, реально эксплуатировавшуюся в атаках. За весь 2025 год таких было 127.
Среднее количество эксплуатируемых уязвимостей выросло с 10,5 до 18 в месяц.
При этом взрывного роста zero day Google пока не видит. Значительная часть ускорения связана с уже раскрытыми уязвимостями.
LLM позволяют быстрее анализировать:
🔹 изменения между версиями продукта
🔹 опубликованные патчи
🔹 описания уязвимостей
🔹 готовые PoC
🔹 похожие участки кода
Патч становится исходными данными для автоматизированного поиска способа эксплуатации.
📊 10 740 CVE звучит страшнее, чем есть на самом деле
Google отдельно предупреждает, что количество CVE нельзя напрямую превращать в оценку угрозы. Из всех раскрытых в 2026 году уязвимостей эксплуатацию в реальных атаках наблюдали только для 0,23%, примерно одной из 431.
Для security команд становится важнее насколько быстро критическая уязвимость проходит путь от disclosure до рабочего exploit.
В случае BeyondTrust AI нашёл баг, а атакующим понадобилось всего несколько дней, чтобы превратить опубликованную уязвимость в initial access.
Окно между CVE и атакой продолжает сокращаться.
🔗 Источник: Google Threat Intelligence Group
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AI #VulnerabilityResearch #CVE #RCE #LLM #ThreatIntelligence #AppSec #SecureTechTalks
🧨 OWASP Noir: карта API прямо из исходного кода
OWASP Noir - это open source SAST инструмент, который анализирует исходный код и извлекает доступные точки входа приложения, такие как пути, HTTP методы, параметры, заголовки, cookies и файлы, где они определены.
В ту же карту попадают недокументированные, устаревшие и скрытые API.
⚙️ Функционал
Инструмент определяет язык и фреймворк проекта, анализирует маршрутизацию и формирует список точек входа.
Актуальный README заявляет поддержку 205 фреймворков. Если встроенного анализатора для конкретного фреймворка недостаточно, можно подключить LLM через OpenAI, Ollama и другие поддерживаемые провайдеры.
🔎 Из кода сразу в Burp или ZAP
Результат можно экспортировать в OpenAPI, JSON, YAML, SARIF, Postman, cURL и другие форматы либо передать маршруты напрямую в Burp Suite, ZAP, Caido или Gori.
Это позволяет DAST сканеру получить точки входа, которые он мог пропустить при обычном обходе приложения.
🤖 Контекст для AI аудита
Для каждой точки входа Noir может добавить вызываемые функции, проверки, валидаторы, потенциально опасные операции и другие сигналы.
Вместо всего репозитория LLM получает сфокусированный контекст вокруг конкретных обработчиков. Для автоматизации есть GitHub Action, SARIF и коды завершения для CI/CD.
Проект входит в OWASP Foundation с июня 2024 года и распространяется под MIT.
🔗 GitHub: OWASP Noir
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OWASP #Noir #AppSec #SAST #DAST #APISecurity #AISecurity #DevSecOps #SecureTechTalks
OWASP Noir - это open source SAST инструмент, который анализирует исходный код и извлекает доступные точки входа приложения, такие как пути, HTTP методы, параметры, заголовки, cookies и файлы, где они определены.
В ту же карту попадают недокументированные, устаревшие и скрытые API.
⚙️ Функционал
Инструмент определяет язык и фреймворк проекта, анализирует маршрутизацию и формирует список точек входа.
Актуальный README заявляет поддержку 205 фреймворков. Если встроенного анализатора для конкретного фреймворка недостаточно, можно подключить LLM через OpenAI, Ollama и другие поддерживаемые провайдеры.
🔎 Из кода сразу в Burp или ZAP
Результат можно экспортировать в OpenAPI, JSON, YAML, SARIF, Postman, cURL и другие форматы либо передать маршруты напрямую в Burp Suite, ZAP, Caido или Gori.
Это позволяет DAST сканеру получить точки входа, которые он мог пропустить при обычном обходе приложения.
🤖 Контекст для AI аудита
Для каждой точки входа Noir может добавить вызываемые функции, проверки, валидаторы, потенциально опасные операции и другие сигналы.
Вместо всего репозитория LLM получает сфокусированный контекст вокруг конкретных обработчиков. Для автоматизации есть GitHub Action, SARIF и коды завершения для CI/CD.
Проект входит в OWASP Foundation с июня 2024 года и распространяется под MIT.
🔗 GitHub: OWASP Noir
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OWASP #Noir #AppSec #SAST #DAST #APISecurity #AISecurity #DevSecOps #SecureTechTalks
🧨 AI агент сам находит путь от prompt injection до RCE
Исследователи представили AgentXploit, систему, которая проверяет безопасность AI агентов по полному циклу: изучает исходный код, ищет путь от контролируемых атакующим данных до опасной операции, а затем пытается подтвердить атаку на работающей системе.
В отличие от проверок с заранее известной точкой внедрения, AgentXploit самостоятельно ищет уязвимую цепочку внутри репозитория.
⚙️ Два агента вместо одного
Analyzer Agent исследует код с помощью AST, поиска символов, анализа зависимостей и инструментов LSP. Он отслеживает поток данных от внешнего ввода до чувствительных операций: чтения файлов, вызовов API и выполнения команд. Результат сохраняется в отчёте с подтверждениями из исходников.
Exploiter Agent получает найденную цепочку, атакует изолированную копию приложения через доступный интерфейс и корректирует попытки по результатам выполнения.
Успех засчитывает внешний проверяющий механизм, который фиксирует реальный эффект: например, доступ к защищённому файлу, изменение базы данных или выполнение команды.
📊 72 уязвимости в 12 проектах
Авторы создали AgentXploit Bench на основе известных уязвимостей и проблем безопасности в 12 открытых проектах AI агентов.
На 72 воспроизводимых сценариях AgentXploit достиг 59,3% успешных атак в среднем за три запуска. Codex показал 38,4%.
🔬 Что система находит в коде
Во время аудита исследователи выявили ещё восемь уязвимостей за пределами основных тестовых сценариев: SSRF, внедрение команд, несанкционированный доступ, небезопасные настройки и удалённое выполнение кода.
Однако обнаружение пути ещё не гарантирует успешную эксплуатацию. На одном из проверенных репозиториев только две из пяти предложенных цепочек соответствовали целевым уязвимостям; ещё одна указывала на другую реальную проблему.
🔗 Исследование: AgentXploit
🔗 Код и тестовый набор: GitHub
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentXploit #PromptInjection #RCE #SSRF #RedTeaming #AppSec #SecureTechTalks
Исследователи представили AgentXploit, систему, которая проверяет безопасность AI агентов по полному циклу: изучает исходный код, ищет путь от контролируемых атакующим данных до опасной операции, а затем пытается подтвердить атаку на работающей системе.
В отличие от проверок с заранее известной точкой внедрения, AgentXploit самостоятельно ищет уязвимую цепочку внутри репозитория.
⚙️ Два агента вместо одного
Analyzer Agent исследует код с помощью AST, поиска символов, анализа зависимостей и инструментов LSP. Он отслеживает поток данных от внешнего ввода до чувствительных операций: чтения файлов, вызовов API и выполнения команд. Результат сохраняется в отчёте с подтверждениями из исходников.
Exploiter Agent получает найденную цепочку, атакует изолированную копию приложения через доступный интерфейс и корректирует попытки по результатам выполнения.
Успех засчитывает внешний проверяющий механизм, который фиксирует реальный эффект: например, доступ к защищённому файлу, изменение базы данных или выполнение команды.
📊 72 уязвимости в 12 проектах
Авторы создали AgentXploit Bench на основе известных уязвимостей и проблем безопасности в 12 открытых проектах AI агентов.
На 72 воспроизводимых сценариях AgentXploit достиг 59,3% успешных атак в среднем за три запуска. Codex показал 38,4%.
🔬 Что система находит в коде
Во время аудита исследователи выявили ещё восемь уязвимостей за пределами основных тестовых сценариев: SSRF, внедрение команд, несанкционированный доступ, небезопасные настройки и удалённое выполнение кода.
Однако обнаружение пути ещё не гарантирует успешную эксплуатацию. На одном из проверенных репозиториев только две из пяти предложенных цепочек соответствовали целевым уязвимостям; ещё одна указывала на другую реальную проблему.
🔗 Исследование: AgentXploit
🔗 Код и тестовый набор: GitHub
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentXploit #PromptInjection #RCE #SSRF #RedTeaming #AppSec #SecureTechTalks
👌1
🛡 Rubrik учит AI искать цепочки уязвимостей до выхода кода в production
8 октября Rubrik объявила о расширении Project Hourglass и добавлении Rubrik Code Guardian к платформе Rubrik Agent Cloud. К инициативе присоединились AHEAD, Trace3 и World Wide Technology (WWT). Теперь партнёры смогут использовать AI для red teaming исходного кода и проверки реалистичных сценариев атак.
⚙️ От репозитория до attack chain
В основе Code Guardian лежит Claude Mythos 5 от Anthropic, работающая внутри специализированного защитного контура Rubrik.
Система анализирует копию репозитория, изолированную от production и внешней сети. Модель исследует связи между файлами, сервисами, ролями идентификации и облачными границами. Цель состоит в том, чтобы выявлять многошаговые сценарии, которые теряются при проверке отдельных строк кода.
Например, потенциальная проблема может начинаться с недостаточной проверки входных данных, продолжаться через сервис с расширенными полномочиями и заканчиваться доступом к чувствительному ресурсу. Для оценки риска важна вся последовательность действий и реальная достижимость конечной операции.
Rubrik заявляет о проверке фактической эксплуатируемости находок и ранжировании по бизнес критичности. Это должно уменьшить поток предупреждений, которые выглядят опасно в отчёте, но не складываются в рабочую атаку.
🔬 Вторая часть: защита самих AI агентов
Project Hourglass изначально создавался для внедрения Rubrik Agent Cloud в рабочие процессы с Claude Code. Платформа включает наблюдаемость, runtime guardrails, защиту prompt context и Agent Rewind, позволяющий отменять нежелательные действия агента.
Code Guardian дополняет эту схему проверкой кода до его поставки. В итоге Rubrik объединяет два уровня: аудит потенциальных уязвимостей в репозитории и контроль поведения AI агента во время работы.
📌 Что стоит учитывать
Пока Code Guardian находится в режиме private preview и доступен ограниченному кругу design partners. Rubrik описывает его возможности и ожидаемые результаты, но публичных независимых бенчмарков с метриками точности и полноты обнаружения в объявлении нет.
🔗 Официальный анонс Rubrik
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #Rubrik #CodeGuardian #ProjectHourglass #Claude #RedTeam #AppSec #SecureTechTalks
8 октября Rubrik объявила о расширении Project Hourglass и добавлении Rubrik Code Guardian к платформе Rubrik Agent Cloud. К инициативе присоединились AHEAD, Trace3 и World Wide Technology (WWT). Теперь партнёры смогут использовать AI для red teaming исходного кода и проверки реалистичных сценариев атак.
⚙️ От репозитория до attack chain
В основе Code Guardian лежит Claude Mythos 5 от Anthropic, работающая внутри специализированного защитного контура Rubrik.
Система анализирует копию репозитория, изолированную от production и внешней сети. Модель исследует связи между файлами, сервисами, ролями идентификации и облачными границами. Цель состоит в том, чтобы выявлять многошаговые сценарии, которые теряются при проверке отдельных строк кода.
Например, потенциальная проблема может начинаться с недостаточной проверки входных данных, продолжаться через сервис с расширенными полномочиями и заканчиваться доступом к чувствительному ресурсу. Для оценки риска важна вся последовательность действий и реальная достижимость конечной операции.
Rubrik заявляет о проверке фактической эксплуатируемости находок и ранжировании по бизнес критичности. Это должно уменьшить поток предупреждений, которые выглядят опасно в отчёте, но не складываются в рабочую атаку.
🔬 Вторая часть: защита самих AI агентов
Project Hourglass изначально создавался для внедрения Rubrik Agent Cloud в рабочие процессы с Claude Code. Платформа включает наблюдаемость, runtime guardrails, защиту prompt context и Agent Rewind, позволяющий отменять нежелательные действия агента.
Code Guardian дополняет эту схему проверкой кода до его поставки. В итоге Rubrik объединяет два уровня: аудит потенциальных уязвимостей в репозитории и контроль поведения AI агента во время работы.
📌 Что стоит учитывать
Пока Code Guardian находится в режиме private preview и доступен ограниченному кругу design partners. Rubrik описывает его возможности и ожидаемые результаты, но публичных независимых бенчмарков с метриками точности и полноты обнаружения в объявлении нет.
🔗 Официальный анонс Rubrik
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #Rubrik #CodeGuardian #ProjectHourglass #Claude #RedTeam #AppSec #SecureTechTalks
🧨 Anthropic запустила бесплатный AI сканер уязвимостей для open source
29 000 потенциальных уязвимостей за полгода. Около 6 000 проверок прошли ручной разбор специалистами Anthropic.
8 октября Anthropic представила OSS Scanner. Сервис бесплатно проводит периодические аудиты открытых репозиториев с помощью самых мощных моделей компании, включая Claude Mythos. Проекты подключаются добровольно, а отчёты получают сопровождающие непосредственно от системы.
⚙️ Как устроено сканирование
OSS Scanner вдохновлён OSS Fuzz от Google, но использует возможности языковых моделей для поиска логических и сложных уязвимостей в коде.
Для подключения сопровождающие проекта добавляют конфигурацию в репозиторий Anthropic OSS Scanner на GitHub. Необходимо указать исходный репозиторий, контактный адрес и Dockerfile для сборки проекта. Можно также приложить threat model, описывающую границы доверия, чувствительные операции и ожидаемую серьёзность находок.
Сканер собирает проект в изолированной виртуальной машине. После подготовки окружения аудит выполняется без доступа к интернету. Это ограничивает возможности сканирующего агента взаимодействовать с внешними системами во время анализа.
Отчёт отправляется по электронной почте и, если возможно, включает описание уязвимости, способ её воспроизведения и предлагаемый патч. Результаты могут содержать ошибки: автоматическая генерация позволяет запускать проверки чаще, но сама по себе не гарантирует корректность каждой находки.
🔬 Насколько точны результаты
Anthropic проверила раннюю версию сервиса на выборке из 97 уязвимостей высокой и критической серьёзности в 48 проектах. Экспертные пентестеры признали 85 находок соответствующими требованиям процесса координированного раскрытия уязвимостей.
Из оставшихся 12 случаев 11 оказались реальными проблемами, но дублировали известные уязвимости либо другие результаты сканирования. Лишь один случай оказался ложноположительным.
Это хороший результат для автоматизированного поиска, но стоит отметить, что выборка ограничена. Сопровождающие также сообщали о завышенных оценках серьёзности и неправильном понимании threat model.
🛡 Цена масштабирования
В обычном процессе Anthropic проверяет находки вручную перед передачей сопровождающим. OSS Scanner позволяет получать результаты быстрее, пропуская этот этап. Поэтому сервис рассчитан прежде всего на критически важные проекты, чьи команды способны самостоятельно разбирать поток сообщений об уязвимостях.
🔗 Официальный анонс Anthropic
🔗 Репозиторий OSS Scanner
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #Anthropic #Claude #Mythos #OpenSource #VulnerabilityResearch #AppSec #DevSecOps #SecureTechTalks
29 000 потенциальных уязвимостей за полгода. Около 6 000 проверок прошли ручной разбор специалистами Anthropic.
8 октября Anthropic представила OSS Scanner. Сервис бесплатно проводит периодические аудиты открытых репозиториев с помощью самых мощных моделей компании, включая Claude Mythos. Проекты подключаются добровольно, а отчёты получают сопровождающие непосредственно от системы.
⚙️ Как устроено сканирование
OSS Scanner вдохновлён OSS Fuzz от Google, но использует возможности языковых моделей для поиска логических и сложных уязвимостей в коде.
Для подключения сопровождающие проекта добавляют конфигурацию в репозиторий Anthropic OSS Scanner на GitHub. Необходимо указать исходный репозиторий, контактный адрес и Dockerfile для сборки проекта. Можно также приложить threat model, описывающую границы доверия, чувствительные операции и ожидаемую серьёзность находок.
Сканер собирает проект в изолированной виртуальной машине. После подготовки окружения аудит выполняется без доступа к интернету. Это ограничивает возможности сканирующего агента взаимодействовать с внешними системами во время анализа.
Отчёт отправляется по электронной почте и, если возможно, включает описание уязвимости, способ её воспроизведения и предлагаемый патч. Результаты могут содержать ошибки: автоматическая генерация позволяет запускать проверки чаще, но сама по себе не гарантирует корректность каждой находки.
🔬 Насколько точны результаты
Anthropic проверила раннюю версию сервиса на выборке из 97 уязвимостей высокой и критической серьёзности в 48 проектах. Экспертные пентестеры признали 85 находок соответствующими требованиям процесса координированного раскрытия уязвимостей.
Из оставшихся 12 случаев 11 оказались реальными проблемами, но дублировали известные уязвимости либо другие результаты сканирования. Лишь один случай оказался ложноположительным.
Это хороший результат для автоматизированного поиска, но стоит отметить, что выборка ограничена. Сопровождающие также сообщали о завышенных оценках серьёзности и неправильном понимании threat model.
🛡 Цена масштабирования
В обычном процессе Anthropic проверяет находки вручную перед передачей сопровождающим. OSS Scanner позволяет получать результаты быстрее, пропуская этот этап. Поэтому сервис рассчитан прежде всего на критически важные проекты, чьи команды способны самостоятельно разбирать поток сообщений об уязвимостях.
🔗 Официальный анонс Anthropic
🔗 Репозиторий OSS Scanner
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #Anthropic #Claude #Mythos #OpenSource #VulnerabilityResearch #AppSec #DevSecOps #SecureTechTalks
🔐 Bearer: SAST с анализом потоков чувствительных данных
Bearer - это open source инструмент на Go для поиска уязвимостей и рисков утечки данных в исходном коде. Он поддерживает Go, Java, JavaScript, TypeScript, PHP, Python и Ruby.
⚙️ Что проверяет
Bearer разбирает код, анализирует AST и отслеживает потоки данных. Это помогает находить уязвимости, даже когда источник проблемы и опасная операция находятся в разных компонентах.
Основные возможности:
🔹 SAST: SQL injection, XSS, Path Traversal и небезопасная криптография.
🔹 Secrets Scanner: поиск захардкоженных паролей, токенов и ключей на базе Gitleaks.
🔹 Privacy Report: анализ обработки PII и других чувствительных данных, включая их передачу в базы данных, API и сторонние сервисы. Инструмент распознаёт более 120 типов чувствительных данных.
🛠 Интеграция
Bearer интегрируется в CI/CD, поддерживает GitHub Actions и экспорт результатов в SARIF для GitHub Code Scanning. Режим
Статический анализ зависит от поддерживаемых языков и правил. Результаты требуют проверки, а для оценки поведения приложения нужны дополнительные runtime тесты. Часть расширенных возможностей доступна в коммерческой версии Bearer Pro от Cycode.
🔗 GitHub: https://github.com/Bearer/bearer
🔗 Документация: https://docs.bearer.com
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AppSec #SAST #DevSecOps #DataSecurity #Privacy #CodeSecurity #OpenSource #Gitleaks #SecureTechTalks
Bearer - это open source инструмент на Go для поиска уязвимостей и рисков утечки данных в исходном коде. Он поддерживает Go, Java, JavaScript, TypeScript, PHP, Python и Ruby.
⚙️ Что проверяет
Bearer разбирает код, анализирует AST и отслеживает потоки данных. Это помогает находить уязвимости, даже когда источник проблемы и опасная операция находятся в разных компонентах.
Основные возможности:
🔹 SAST: SQL injection, XSS, Path Traversal и небезопасная криптография.
🔹 Secrets Scanner: поиск захардкоженных паролей, токенов и ключей на базе Gitleaks.
🔹 Privacy Report: анализ обработки PII и других чувствительных данных, включая их передачу в базы данных, API и сторонние сервисы. Инструмент распознаёт более 120 типов чувствительных данных.
🛠 Интеграция
Bearer интегрируется в CI/CD, поддерживает GitHub Actions и экспорт результатов в SARIF для GitHub Code Scanning. Режим
--diff помогает сосредоточиться на новых проблемах в изменённом коде.Статический анализ зависит от поддерживаемых языков и правил. Результаты требуют проверки, а для оценки поведения приложения нужны дополнительные runtime тесты. Часть расширенных возможностей доступна в коммерческой версии Bearer Pro от Cycode.
🔗 GitHub: https://github.com/Bearer/bearer
🔗 Документация: https://docs.bearer.com
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AppSec #SAST #DevSecOps #DataSecurity #Privacy #CodeSecurity #OpenSource #Gitleaks #SecureTechTalks
🧨 Claude сократил поверхности атаки на OpenSSH
Anthropic использовала Claude для анализа 25 open source проектов объёмом более 5 млн строк кода. Модель выявила 493 проблемы, связанные с избыточной доступностью кода, конфликтами конфигурации и выполнением операций до проверок безопасности.
⚙️ Три класса проблем
🔹 Лишний код. Функциональность доступна извне, хотя приложению она не нужна.
🔹 Конфликты настроек. Из 162 найденных сочетаний параметров в 94 случаях комбинации незаметно отключали защитные механизмы.
🔹 Неверный порядок проверок. Код обрабатывает данные клиента до аутентификации или проверки разрешений.
В четырёх проектах обнаружился общий дефект: правила доступа по hostname зависели от reverse DNS. При отключённом DNS сервер сравнивал правило с IP-адресом, и ограничение переставало работать.
🔬 Что нашли в OpenSSH
В OpenSSH 10.4 около 4 500 строк кода экспериментального алгоритма ML-DSA-44 оставались доступными для обработки данных неаутентифицированного клиента, хотя алгоритм был исключён настройками.
Claude выявила два обходных пути, связанных с несоответствием типа ключа его содержимому и проверкой подписи CA внутри сертификата. После совместной работы с сопровождающими в OpenSSH 10.6 проверки перенесли в парсер, до десериализации ключа и проверки подписи. Объём кода, доступного до аутентификации при стандартной конфигурации, сократился примерно на 20%.
🛡️ Как устроен подход
Claude анализирует точки входа и конфигурации, предлагает изменения, затем проверяет их трассировками и тестами. Изменения, способные повлиять на нестандартные конфигурации, передаются человеку.
Методика сокращает поверхность атаки за счёт ограничения ненужной функциональности, даже если уязвимость в ней ещё не обнаружена.
🔗 Исследование Anthropic
🔗 OpenSSH 10.6
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #OpenSource #OpenSSH #Claude #AttackSurface #AppSec #VulnerabilityResearch #DevSecOps #SecureTechTalks
Anthropic использовала Claude для анализа 25 open source проектов объёмом более 5 млн строк кода. Модель выявила 493 проблемы, связанные с избыточной доступностью кода, конфликтами конфигурации и выполнением операций до проверок безопасности.
⚙️ Три класса проблем
🔹 Лишний код. Функциональность доступна извне, хотя приложению она не нужна.
🔹 Конфликты настроек. Из 162 найденных сочетаний параметров в 94 случаях комбинации незаметно отключали защитные механизмы.
🔹 Неверный порядок проверок. Код обрабатывает данные клиента до аутентификации или проверки разрешений.
В четырёх проектах обнаружился общий дефект: правила доступа по hostname зависели от reverse DNS. При отключённом DNS сервер сравнивал правило с IP-адресом, и ограничение переставало работать.
🔬 Что нашли в OpenSSH
В OpenSSH 10.4 около 4 500 строк кода экспериментального алгоритма ML-DSA-44 оставались доступными для обработки данных неаутентифицированного клиента, хотя алгоритм был исключён настройками.
Claude выявила два обходных пути, связанных с несоответствием типа ключа его содержимому и проверкой подписи CA внутри сертификата. После совместной работы с сопровождающими в OpenSSH 10.6 проверки перенесли в парсер, до десериализации ключа и проверки подписи. Объём кода, доступного до аутентификации при стандартной конфигурации, сократился примерно на 20%.
🛡️ Как устроен подход
Claude анализирует точки входа и конфигурации, предлагает изменения, затем проверяет их трассировками и тестами. Изменения, способные повлиять на нестандартные конфигурации, передаются человеку.
Методика сокращает поверхность атаки за счёт ограничения ненужной функциональности, даже если уязвимость в ней ещё не обнаружена.
🔗 Исследование Anthropic
🔗 OpenSSH 10.6
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #OpenSource #OpenSSH #Claude #AttackSurface #AppSec #VulnerabilityResearch #DevSecOps #SecureTechTalks