SecureTechTalks

🧠 AI-агенты начали автоматизировать научные исследования На arXiv вышла работа AutoSci: агентская система, которая пытается автоматизировать полный research pipeline: 🔹 поиск литературы 🔹 генерация гипотез 🔹 постановка экспериментов 🔹 запуск вычислений 🔹 анализ результатов 🔹 написание статьи Агент работает как stateful execution system, где исследование разбивается на этапы через orchestration layer SciFlow. Каждая стадия получает свой контекст, скиллы и execution logic. ⚙️ Главная фишка Самая сильная часть архитектуры - это память, SciMem. Система хранит не документы целиком, а сущности: 🔹 статьи 🔹 методы 🔹 гипотезы 🔹 эксперименты 🔹 результаты Всё живёт как state machine: ➖«гипотеза → тестирование → подтверждение / отклонение» ➖«эксперимент → запуск → результат → переоценка» Получается persistent reasoning layer, где агент не забывает прошлые попытки и может строить итеративные workflow. 🔬 А как защищаются от галлюцинаций? Авторы отдельно добавили Trust Guard для валидации памяти. Перед записью знание проверяется на происхождение источника, связи с текущими знаниями и на соответствие schema. Таким отразом пытаются решить проблему долго работающих агентов с отравлением памяти и накопление ложных выводов после сотен шагов рассуждений. 🧪 Это работает? В одном из экспериментов агент самостоятельно оптимизировал GPU kernel и получил 1.52× ускорение относительно исходника. Стоит отметить, что во всех кейсах система сохраняла не только успехи, но и провалы, используя их как отрицательное знание для следующих итераций. 🔗 Исследование: https://arxiv.org/abs/2605.31468 Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #AgenticAI #AIsecurity #CyberSecurity #RAG #MemorySecurity #ResearchAgents #SecureTechTalks

🧠 OWASP взялись за безопасность памяти AI-агентов. OWASP запустили Agent Memory Guard, проект посвящённый безопасности памяти AI-агентов. Большинство memory-систем работают примерно одинаково: контекст → embedding → векторная база данных → извлечение → обратная подача в prompt. Безопасность в таком подходе почти отсутствует. Например: вредоносный документ → загрузка через RAG → преобразование в embedding → сохранение в памяти → извлечение в следующей сессии → агент начинает воспринимать вредоносную инструкцию как доверенный исторический контекст. Prompt injection внезапно становится постоянным. Один удачный payload способен пережить перезапуск процесса и начать влиять на дальнейшее reasoning агента. 🔬 Решение OWASP Проект пока больше похож на модель угроз + набор практик безопасности, чем на готовый продукт. Но внутри уже есть довольно интересная систематизация рисков. 1⃣ Отравление памяти Атакующий загрязняет слой памяти. Например: скрытые инструкции попадают в память поиска и позже начинают влиять на принятие решений агентом. OWASP предлагают вводить: 🔹 оценку доверия к источникам 🔹 проверку данных перед сохранением 🔹 метаданные происхождения информации 🔹 классификацию содержимого перед записью 2⃣ Изоляция памяти Для мультиагентных систем появляется другая проблема: заражение между агентами. Если несколько агентов используют общее хранилище памяти, компрометация одного агента начинает влиять на остальных. OWASP предлагают: 🔹 изоляцию пространств памяти 🔹 ограничение доступа к контексту 🔹 отдельные границы памяти для каждого агента 🔹 сегментацию памяти по принципу Zero Trust 3⃣ Управление жизненным циклом памяти Самая практичная часть проекта. OWASP отдельно подчёркивают: память не должна жить вечно. Рекомендуются: 🔹 время жизни записей (TTL) 🔹 автоматическое устаревание памяти 🔹 снижение уровня доверия со временем 🔹 механизмы отзыва контекста 🔹 периодическая повторная проверка 🔗 GitHub: https://github.com/OWASP/www-project-agent-memory-guard Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #OWASP #AgenticAI #PromptInjection #AppSec #CyberSecurity #AIsecurity #SecureTechTalks

🧨 AI-агенту дали shell. Что теперь делать? PipeLock - open-source execution proxy для AI-агентов. Инструмент встраивается между агентом и системой исполнения и начинает проверять каждую команду до того, как она попадёт в shell. Сильной стороной проекта является уровень контроля. PipeLock анализирует уже финальную команду, после того как LLM её сгенерировала. Технически процесс выглядит следующим образом: система перехватывает shell invocation → парсит итоговую команду → раскладывает её на бинарник, флаги, аргументы и execution context → сравнивает с политиками. Политики задаются декларативно и позволяют ограничивать: 🔹 какие бинарники вообще можно запускать (git, npm, docker) 🔹 какие флаги допустимы (--force, --privileged, rm -rf) 🔹 какие filesystem paths доступны 🔹 какие environment variables можно читать 🔹 какие команды требуют human approval Например: агенту можно разрешить docker build, но запретить docker run --privileged. 🧠 Отличие от песочниц Большинство инструментов контроля безопасности работают либо до execution, либо после, как тотже SAST. PipeLock работает в точке принятия действия. То есть появляется новый слой безопасности, AI Action Governance для агентных систем. 🔗 GitHub: https://github.com/luckyPipewrench/pipelock Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #AgenticAI #PromptInjection #DevSecOps #RuntimeSecurity #CyberSecurity #OpenSource #SecureTechTalks

🧠 На GitHub выложили offensive-security Skills для AI-агентов Похоже, эпоха «универсальных» агентов начинает заканчиваться. На GitHub появился репозиторий Anthropic Cybersecurity Skills, набор готовых procedural skills для offensive-security задач. Унифецировать operational workflow для агентов кибербезопасности становится проще. Внутри набор специализированных "SKILL.md", заточенных под конкретные сценарии: 🔹 web exploitation 🔹 reconnaissance 🔹 reverse engineering 🔹 binary analysis 🔹 vulnerability research 🔹 CTF-style workflows ⚙️ Немного о сценариях Skill ограничивает search space агента. Вместо хаотичного reasoning модель получает заранее определённую методологию выполнения. Например, web-testing skill может задавать последовательность: surface mapping → auth analysis → input tracing → state transitions → exploit hypothesis → validation Reverse engineering skill уже будет толкать агента в сторону: binary triage → symbols → strings → CFG → suspicious execution paths → patching/debugging То есть agent reasoning становится ближе к playbook-driven execution. 🧪 Эффективность скиллов Недавние исследования показывали, что Skills далеко не всегда улучшают performance. Иногда агент начинает слишком упорно применять знакомый workflow и идет в неверную сторону. Получается любопытная зависимость: ➖слишком мало Skills → хаотичный reasoning ➖слишком много Skills → procedural tunnel vision Именно здесь сейчас проходит граница эффективности agentic security. 🔗 GitHub: https://github.com/mukul975/Anthropic-Cybersecurity-Skills Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #Claude #Anthropic #AgenticAI #Pentest #OffensiveSecurity #CyberSecurity #SecureTechTalks

🤖💀 AI нашёл 10 000+ критических уязвимостей и это только начало Anthropic выпустила первый апдейт по Project Glasswing, инициативе, где их закрытая модель Claude Mythos ищет уязвимости в критически важном ПО: 🔹 Просканировано >1000 open-source проектов 🔹 Найдено 23 019 проблем 🔹 Из них 6202 high/critical 🔹 Более 90% проверенных находок оказались настоящими уязвимостями Mythos не просто помогает человеку искать баги, он автономно работает как исследователь безопасности: анализирует код, находит zero-day, строит цепочки эксплуатации и даже генерирует exploit path. Anthropic прямо говорит, что frontier-модели начинают конкурировать с лучшими специалистами по поиску уязвимостей. 😅 Самые яркие кейсы ⚠️ Найдена 27-летняя уязвимость в OpenBSD, системе с репутацией «почти непробиваемой» ⚠️ Обнаружен 16-летний баг в FFmpeg, который тесты запускали миллионы раз и всё равно не увидели ⚠️ Найдены цепочки атак в Linux kernel с escalation до полного контроля над системой. 🤷‍♂ Что делать? Раньше у защитников был patch window, время между публикацией бага и массовой эксплуатацией. Теперь окно начинает исчезать. Безопасность больше нельзя строить только на “успеем пропатчить”. Нужны: • secure-by-design подходы • memory-safe языки • runtime protection • exploitability-based prioritization • AI-for-defense быстрее, чем AI-for-attack. Stay secure and read SecureTechTalks 📚 #CyberSecurity #AI #AppSec #LLM #ThreatIntelligence #SecureTechTalks

🦠 Prompt injection превращается в malware С появлением агентских систем prompt injection начинает напоминать полноценный malware lifecycle, где вредоносное воздействие закрепляется, распространяется и приводит к реальным действиям в инфраструктуре. ⚙️ От одного prompt к полной компрометации Современные AI-агенты больше не ограничиваются диалогом. Они работают с: 🔹 MCP/tool calling 🔹 long-term memory 🔹 RAG и внешними документами 🔹 API и SaaS-интеграциями 🔹 filesystem и runtime actions Это означает, что prompt перестаёт быть просто текстом, он начинает работать как операционный payload, способный менять поведение всей системы. Например: в безобидном на первый взгляд PDF оказывается скрытая инструкция → агент загружает документ через RAG → интерпретирует embedded prompt как легитимную инструкцию → меняет execution plan → вызывает tools → начинает выполнять действия уже за пределами модели. 🧠 Исследователи разложили атаку в стиле MITRE ATT&CK Исследователи предлагают смотреть на prompt injection через привычную security-логику: 1⃣ Initial Access Вредоносная инструкция попадает через email, веб-страницу, скачанный документ, базу знаний или пользовательский ввод. Особенно опасны indirect prompt injection-сценарии, где агент читает данные из внешнего источника и сам воспринимает их как доверенный контекст. 2⃣ Privilege Escalation Дальше идёт jailbreak. Модель начинают подталкивать к обходу системных политик и политик безопасности. 3⃣ Persistence Если агент использует memory layer, retrieval cache или shared context, вредоносная инструкция может сохраниться между сессиями. Получается аналог persistence-механизма, когда один prompt приводит к долгосрочному изменению поведения. 4⃣ Lateral Movement В мультиагениной архитектуре скомпрометированный агент начинает влиять на другие компоненты, например через shared memory или  orchestration layer. 5⃣ Actions on Objective Финальная стадия привычна любому безопаснику: 🔹 data exfiltration 🔹 unauthorized tool execution 🔹 business logic abuse 🔹 fraudulent actions 🔹 privilege misuse 🔗 Исследование: https://arxiv.org/abs/2601.09625 Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #PromptInjection #AgenticAI #AIsecurity #CyberSecurity #Infosec #ThreatModeling #SecureTechTalks

🔬 Исследователи решили «допилить» CodeQL с помощью LLM Большинство SAST движков работают через data flow analysis (DFA). Система пытается ответить вопрос, может ли пользовательский input добраться до опасной операции? Однако built-in rules часто знают только «популярные» фреймворки и ограниченный набор propagation patterns. Если используются нестандартные framework или кастомные wrapper, то flow фактически исчезает из анализа. 🧠 LLM как переводчик Исследователи решили использовать LLM для автоматического обнаружения sources и sinks внутри open-source framework’ов. Модель анализировала код библиотек и помогала определять: 🔹 откуда реально приходит user-controlled input 🔹 какие API являются опасными 🔹 как данные передаются через абстрактные слои Дальше всё это превращалось в кастомные правила для CodeQL. Идея оказалась довольно жизнеспособной, но исследователи пошли дальше. 🧪 А потом они полезли в кишки CodeQL Вторая часть исследования: авторы начали патчить сам Data Flow Engine. Добавили поддержку вещей, на которых анализ традиционно ломался: 🔹 Java reflection 🔹 partial native methods 🔹 сложные value-passing scenarios 🔹 propagation через language-specific edge cases Идея была увеличить количество наблюдаемых execution paths внутри анализа. 📈 Цифры После расширения framework coverage исследователи получили 15% дополнительных data flow поверх стандартных правил CodeQL. Кроме того, им удалось воспроизвести 50+ исторических CVE, которые оригинальный CodeQL раньше не видел. Вдобавок было выявлено 5 новых CVE, включая уязвимости, ранее не детектируемые стандартным пайплайном. Возможно, ближайшее будущее AppSec это LLM-enhanced SAST, где модель постоянно расширяет карту data flow и учит scanner видеть то, что раньше было слепой зоной. 🔗 Презентация: https://i.blackhat.com/BH-USA-25/Presentations/USA-25-More-Flows-More-Bugs-Empowering.pdf Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #SAST #CodeQL #AppSec #StaticAnalysis #DevSecOps #CyberSecurity #SecureTechTalks

🧠 Помогают ли Skills для AI-агентов в задачах кибербезопасности? Немного ликбеза: Skills - это структурированные пакеты процедурных знаний для LLM-агентов. Этакий внешний слой опыта как искать уязвимость, как проводить triage, как выполнять exploitation workflow, какие шаги делать дальше. Обычно это выглядит как: 🔹 инструкции (SKILL.md) 🔹 attack templates 🔹 best practices 🔹 lessons learned 🔹 procedural playbook’и Вместо того чтобы каждый раз «изобретать» exploitation path, агент получает готовый operational memory. 🧪 Эксперименты Исследователи взяли автономного CTF-агента с MCP-tooling и прогнали 180 запусков на 15 offensive-security задачах от reverse engineering, до memory corruption. Агент работал с обычным техстеком в виде Nmap, Ghidra, Angr и т.д.. Все инструменты были подключены через MCP и возвращали строго типизированные результаты через schema-validated JSON. Дальше начали играться со Skills: 1⃣ почти без инструкций 2⃣ lessons learned из прошлых запусков 3⃣ curated attack templates 4⃣ «полный фарш» со всеми Skills сразу Казалось бы, чем больше навыков, тем лучше результат (спойлер - не всегда). 📉 Эффективность Skills Разница между агентом без Skills и агентом со всем набором Skills составила всего +8.9% успешности. Статистически это оказалось совсем незначимым. Были кейсы, когда Skills даже ухудшали результат. В timing side-channel задачах агент с «полным набором знаний и навыков» справился хуже, чем более узкая версия с curated templates. Агент начинал применять неподходящий опыт из прошлого и упорно шел по неверному пути. 🔥 Мысли Skills нужны только тогда, когда окружение тупое. Последний год многие пытались сделать AI-агентов умнее через memory, retrieval, skills и т.п. Однако возможно важнее не умный агент, а хороший tool grounding? Вместо ещё 100500 строк инструкций иногда полезнее сделать нормальный MCP и подключить больше инструментов. 🔗 Исследование: https://arxiv.org/abs/2605.20023 Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #AgenticAI #MCP #CyberSecurity #OffensiveSecurity #CTF #AIsecurity #SecureTechTalks

🚨 CVE без бюрократии cve-lite-cli - open-source command-line tool, который упрощает создание и сопровождение CVE-записей. Инструмент превращает vulnerability disclosure в developer-friendly workflow. Вместо ручной возни с CVE JSON schema и форматами теперь можно работать через обычный CLI. Создание записи выглядит, как работа с git: 🔹 создать draft CVE 🔹 заполнить vulnerability metadata 🔹 добавить affected products 🔹 описать impact и remediation 🔹 обновить или опубликовать запись 🧠 Автоматизация Технически инструмент работает поверх CVE Record Format (JSON 5.x) и помогает генерировать корректную структуру документа без ручного редактирования. Кто хоть раз открывал CVE schema, знает боль, ведь нужно аккуратно описать: 🔹 affected versions 🔹 CVSS 🔹 CWE mapping 🔹 references 🔹 vendor metadata 🔹 timelines disclosure Инструмент берет на себя валидацию и шаблонизацию, помогая избежать типичных ошибок. 🧪 Проблематика Мелкие проекты, open source и независимые исследователи часто откладывают disclosure из-за сложности процесса. OWASP пытается идти в ногу со временем и сдвинуть CVE-процесс ближе к DevOps-модели. 🔗 GitHub: https://github.com/OWASP/cve-lite-cli Stay secure and read SecureTechTalks 📚 #кибербезопасность #CVE #OWASP #VulnerabilityManagement #AppSec #OpenSource #DevSecOps #CyberSecurity #Infosec #SecureTechTalks

⚙️ Не scanner, а test harness для LLM Сегодня на обзоре Promptfoo: open-source framework для red teaming и security testing AI-приложений. Инструмент работает как automated evaluation pipeline для LLM-систем. Вы описываете: 🔹 prompt’ы 🔹 модели 🔹 attack cases 🔹 expected behavior 🔹 security assertions Promptfoo начинает системно ломать вашу AI-систему, запуская батарею adversarial тестов. 🧠 Основные фичи Решение строится вокруг evaluation-as-code. Тесты описываются декларативно (YAML/JSON), что благодаря чему проверки становятся воспроизводимыми и кастомизируемыми. Например, можно автоматически проверять: 🔹 prompt injection resistance пытается ли модель игнорировать system instructions 🔹 jailbreak robustness можно ли обойти safety restrictions 🔹 data leakage утекает ли system prompt, secrets или internal context 🔹 tool misuse может ли агент вызвать запрещённые actions 🔹 policy compliance соблюдает ли модель внутренние правила ответа Инструмент умеет запускать массовые вариации атак: одна jailbreak-гипотеза → сотни автоматически сгенерированных вариантов phrasing. 🧨 Своевременная защита Jailbreak зачастую проверяют уже после релиза, когда кто-то выложил exploit. Promptfoo помогает настроить тестирование заранее. Security-команда может гонять adversarial testing прямо в CI/CD: новый prompt → автоматически прогнали red-team suite → увидели regression. Для agentic systems это становится особенно важным, потому что один удачный prompt injection сегодня способен привести к не только к обходу бизнес логики, но и к утечке данных. 🔗 GitHub: https://github.com/promptfoo/promptfoo 🔗 Документация: https://www.promptfoo.dev/ Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #PromptInjection #AppSec #AIsecurity #RedTeaming #DevSecOps #OpenSource #SecureTechTalks

Сейчас идёт обновление OWASP Top 10 for LLM Applications, и в сообществе предложили несколько новых кандидатов для добавления и замены пунктов, потерявших актуальность. Наиболее интересными показались четыре проблемы: Inference-Time Side-Channel Disclosure — атаки на инфраструктуру инференса, при которых наблюдатель за шифрованным сетевым трафиком может с высокой точностью угадывать тематику запросов. Смотрите статью от Microsoft Whisper Leak. Уязвимости MCP tools: скрытые вредоносные инструкции в description инструмента, tool squatting, rug pull, когда сервер меняет поведение через какое-то время после авторизации. К слову, в OWASP есть аж два документа, где детально расписаны проблемы MCP: Cheat Sheet и Guide for Using Third-Party MCP. Persistent Memory Poisoning — можно сказать, это замена старому LLM04 (Data and Model Poisoning) про отравления датасетов обучения. За последние пару лет мы не видим кейсов таких отравлений (это не значит, что их нет, конечно), но видим много атак в runtime на межсессионную память. EchoLeak, SpAIware, кейс с Gemini есть в ссылках к этому кандидату. И Model Misalignment, который заслуживает внимания с развитием reasoning моделей и их широкими возможностями. Пункт о том, что поведение модели расходится с исходной задачей пользователя. Сюда относятся работы про alignment faking, sleeper agents и тп. Текущее описание кандидата требует доработки и даже есть кандидат-дубликат Model Scheming and Deceptive Alignment, но, надеюсь, он всё равно войдёт в итоговый апдейт. Кстати, до конца дня 18 мая вы можете тоже поддержать выбор новых кандидатов и помочь рабочей группе OWASP оценить, какие из старых пунктов можно исключить, если проголосуете в форме. После голосования из 10 новых кандидатов останется половина, и итоговый выбор Top 10 будет сформирован в июне.

🤖 AI начал искать уязвимости слишком хорошо Ещё недавно казалось, что AI-assisted vulnerability research является очевидным благом. Модель анализирует код, находит больше багов, безопасность растёт. Но AI научился производить потенциальные уязвимости быстрее, чем люди успевают их проверять. ⚙️ Discovery ускорился, а validation нет Современные LLM действительно неплохо помогают в vulnerability research. Они умеют: 🔹 быстро проходить по large codebase 🔹 искать suspicious execution paths 🔹 сопоставлять API interactions 🔹 строить exploit hypotheses 🔹 анализировать dependency logic Особенно полезны модели там, где проблема возникает из сложного взаимодействия компонентов, а не из одной очевидной ошибки. LLM хорошо находят правдоподобные сценарии, а вот с проверкой их реализуемости всё гораздо хуже. Типичный кейс выглядит так: модель видит потенциальный path к RCE → строит убедительный reasoning → а потом оказывается, что permission model, sandboxing или runtime-ограничения ломают exploit целиком. 🌊 Bug bounty начинает тонуть Проблема уже дошла до bug bounty и disclosure-программ. Security-команды всё чаще получают AI-assisted findings без PoC или без reproducible exploit, а иногда вообще с уже известными проблемами. Хуже того, модели часто приводят разных исследователей к одинаковым гипотезам. В результате maintainers начинают получать десятки вариаций одного и того же report’а. Особенно тяжело дела обстоят у open source. У крупных компаний есть AppSec-команды, а maintainer open-source проекта зачастую это один человек с парой свободных часов вечером. 🧪 Появился новый bottleneck AI постепенно превращает vulnerability discovery в machine-scale процесс, но triage и validation всё ещё остаются ручной работой. В интересное время живем, искать потенциальные баги стало быстрее, чем понимать, какие из них эксплуатируются. Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #BugBounty #AppSec #VulnerabilityResearch #OpenSource #Infosec #CyberSecurity #SecureTechTalks

📏💣 LLM можно взломать просто продолжая диалог В мае вышла работа MetaBackdoor, где исследователи из Microsoft и Institute of Science Tokyo описывают новый тип backdoor-атак на LLM. Главная идея исследования использовать в качестве trigger не содержимое prompt, а позицию токенов в контексте.

достиг определённой позиции в sequence → переключил поведение модели

Авторы называют это meta-trigger, потому что он связан не с текстом, а с метасвойствами последовательности. Например: 📚 контекст превысил определённую длину 📍 токены оказались в нужном positional range 🔢 sequence crossed threshold Trigger может возникать естественным образом, без участия атакующего. 💬 пользователь просто общается с AI 🧠 память агента накапливается 📈 context window становится длиннее И в какой-то момент backdoor активируется сам. 🧬 Особенности моделей Технически атака использует фундаментальную особенность Transformer-архитектуры, positional encoding. Для модели все токены это просто embedding-вектора. Без механизма позиции фразы для модели были бы почти одинаковыми. Представьте перепутать «root granted admin» и «admin granted root». Поэтому модели используют positional embeddings. В современных моделях чаще всего это: 🔹 RoPE (Rotary Positional Embedding) 🔹 ALiBi 🔹 Absolute positional encodings В исследовании авторы показывают, что именно позиционная чувствительность модели может использоваться как скрытый канал управления поведением. Во время fine-tuning в модель внедряется backdoor objective: если токен находится после определённой позиции → изменить response policy Trigger не обязан быть точным числом. Бэкдор может срабатывать в диапазоне позиций, например после N тысяч токенов, что делает его значительно более устойчивым к случайным изменениям prompt. Это особенно важно для production-agent systems, где длина контекста постоянно плавает. 🎭 Что можно сделать после активации Авторы тестировали разные payload-сценарии. Среди них: 🧾 System prompt leakage: модель начинает раскрывать скрытые инструкции. 🛠️ Tool misuse: агент начинает выполнять неожиданные tool calls. 📤 Context leakage: утечка памяти и истории общения. 🧠 Policy switching: изменение alignment и response behavior. Похоже, эпоха «проверим prompt и успокоимся» начинает заканчиваться 👀 📄 MetaBackdoor: Exploiting Positional Encoding as a Backdoor Attack Surface in LLMs Stay secure and read SecureTechTalks 📚 #CyberSecurity #AI #LLMSecurity #AISecurity #PromptInjection #GenAI #MachineLearning #ThreatModeling #AIAgents #SecureTechTalks

🎭 Deepfake-детекторы начинают проигрывать. Большинство систем deepfake detection работают, как поиск статистических аномалий. Модели анализируют: 🔹 микродвижения лица 🔹 артефакты compression 🔹 inconsistencies в освещении 🔹 частотные особенности изображения 🔹 temporal anomalies между кадрами Другими словами, detector пытается найти признаки того, что контент был синтетически сгенерирован. Однако современные генеративные модели начинают производить данные, статистически близкие к реальным. ⚙️ Гонка вооружений Deepfake-generation и deepfake-detection давно превратились в adversarial cycle. Детектор учится находить паттерн, а генератор учится этот паттерн скрывать. С каждой новой итерацией качество синтетического контента становится выше, а количество detectable artifacts уменьшается. Исследователи отдельно отмечают: многие современные detector’ы начинают резко терять accuracy на новых generation-моделях, для которых они изначально не обучались. Особенно плохо системы работают при: 🔹 повторном сжатии видео 🔹 изменении resolution 🔹 post-processing 🔹 screen recording 🔹 смешанных pipeline генерации Иногда достаточно обычного TikTok-style re-encoding, чтобы detection quality заметно деградировал. 🧪 Главная проблема Детекторы всё сильнее зависят от конкретных особенностей pipeline, система часто учится распознавать не «фейк», а следы конкретной модели или конкретного способа генерации. Как только pipeline меняется, detection начинает рассыпаться. 🧨 Индустрия теряет точку опоры Похоже, deepfake detection постепенно смещается из категории «технически решаемой задачи» в область вероятностного анализа, где речь идёт уже не о точном определении фейка, а об оценке уровня доверия к контенту. 🔗 Статья: https://arxiv.org/pdf/2605.09007 Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #Deepfake #LLM #CyberSecurity #FraudDetection #SocialEngineering #Infosec #AIrisks #SecureTechTalks

🧬 VectorSmuggle: данные научились прятать внутри embedding’ов Большинство AI-систем относятся к embedding как к безопасному промежуточному формату, т.к. Вектор не выглядит как текст и не содержит очевидного payload. Поэтому embedding’и спокойно: 🔹 передаются между сервисами 🔹 индексируются в vector DB 🔹 попадают в shared storage 🔹 используются в retrieval pipeline Практически никто не анализирует их содержимое с точки зрения безопасности. А зря. ⚙️ Что такое VectorSmuggle Исследователи показали, что внутри embedding можно скрытно кодировать произвольные данные, сохраняя при этом его внешнюю «нормальность». Технически идея строится вокруг особенностей embedding space. LLM и embedding-модели преобразуют текст в высокоразмерные векторы. При этом небольшие изменения отдельных компонент обычно не ломают semantic similarity. Именно этот запас устойчивости злоумышленники используют, как covert channel. Часть измерений embedding’а начинает хранить скрытый payload, который можно позже извлечь специальным декодером. Со стороны embedding продолжает выглядеть легитимно: 🔹 проходит similarity search 🔹 нормально индексируется 🔹 не вызывает ошибок в vector pipeline Но внутри уже находится скрытая информация. 🧪 Реализация Схема выглядит довольно элегантно, сначала данные кодируются внутрь embedding-вектора через модификацию отдельных dimensions. После этого embedding отправляется в обычную vector infrastructure: FAISS, Pinecone, Milvus или другую vector DB. Позже получатель извлекает embedding и декодирует скрытый payload обратно в исходные данные. Ключевая проблема в том, что embedding-инфраструктура почти не имеет механизмов проверки: 🔹 что именно хранится внутри вектора 🔹 насколько embedding отклоняется от нормального распределения 🔹 используется ли vector space как covert storage Для системы это просто массив float-значений. 🧨 Опасность ⚠️ На практике VectorSmuggle открывает довольно неприятные сценарии. Например: 🔹 скрытая передача данных через RAG-pipeline 🔹 covert communication между агентами 🔹 хранение payload внутри vector DB 🔹 обход DLP/контент-фильтрации 🔹 скрытая эксфильтрация информации через embedding API Особенно интересно выглядит последний пункт. Многие security-системы анализируют текст, файлы или сетевой трафик, но практически не смотрят на embedding-space как на потенциальный канал утечки данных, хотя именно туда AI-инфраструктура сейчас начинает переносить всё больше информации. 🔗 Исследование: https://arxiv.org/abs/2505.12540 Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #Embedding #VectorDB #RAG #DataSecurity #AppSec #AIrisks #SecureTechTalks

🤖 Sandyaa: AI-агент для разведки Разведка давно перестала быть проблемой с точки зрения инструментов: Subfinder, httpx, nuclei, waybackurls, DNSdumpster, Shodan. Экосистема огромная. Однако человек просто тонет в количестве результатов. Sandyaa строится как orchestration-layer поверх классических recon-инструментов. Агент собирает данные о цели, анализирует результаты и сам определяет, какие действия выполнять дальше. Технически Sandyaa комбинирует: 🔹 subdomain enumeration 🔹 technology fingerprinting 🔹 endpoint discovery 🔹 OSINT 🔹 vulnerability reconnaissance LLM работает как reasoning-движок между этапами reconnaissance. Например, агент может: увидеть exposed admin endpoint → определить стек → заметить старую версию framework → автоматически переключиться на поиск типовых misconfiguration или CVE именно для этой технологии. Следующий шаг зависит от контекста предыдущего. Результаты работы утилит нормализуются, передаются модели, после чего LLM генерирует следующую последовательность recon-действий. Sandyaa пытается построить decision-making layer. Правда, здесь сразу проявляется слабое место LLM. Модель может переоценивать находки, строить нереалистичные attack paths или уходить в ложные гипотезы. Особенно плохо агенты пока работают с noisy reconnaissance-данными, где важно отличать интересную аномалию от обычного мусора. 🔗 GitHub: https://github.com/securelayer7/sandyaa Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #Reconnaissance #Pentest #OffensiveSecurity #AgenticAI #OSINT #OpenSource #SecureTechTalks

🧠 AppSec переезжает в редактор кода Сегодня Copilot или LLM способны генерировать целые фрагменты бизнес-логики за минуты. Разработчик всё чаще не пишет код вручную, а проверяет уже готовый результат. Таким образом количество нового кода начинает расти быстрее, чем человек успевает анализировать его с точки зрения безопасности. ⚙️ Security-проверки прямо во время написания кода Heidi - open-source security plugin для IDE, который анализирует код прямо в процессе редактирования. Плагин отслеживает изменения в файлах и пытается находить опасные конструкции ещё до запуска приложения: 🔹 insecure API usage 🔹 hardcoded secrets 🔹 shell/command injection patterns 🔹 небезопасную работу с filesystem 🔹 потенциально опасную обработку пользовательского ввода Анализ идёт не только по сигнатурам. Heidi пытается учитывать контекст: откуда приходят данные, проходят ли они sanitization и куда попадают дальше. Например, плагин может заметить, что input пользователя без фильтрации уходит в SQL query, shell execution или filesystem operation. 🧪 Принцип работы Под капотом Heidi использует инкрементальный анализ, т.к. плагин работает внутри IDE и не может позволить себе полноценный перескан проекта после каждого нажатия клавиши. Вместо этого анализируются только изменения и связанные с ними участки кода. Инсирумент строит lightweight security-analysis pipeline прямо внутри editor runtime. Для detection используются: 🔹 pattern-based rules 🔹 context-aware checks 🔹 анализ data flow между источниками input и sensitive operations Система пытается видеть не только отдельную опасную строку, но и цепочку прохождения данных через код. 🧨 Главная проблема таких систем Сделать security-плагин сложно не технически. Сложно сделать так, чтобы разработчики его не возненавидели. Если система начинает агрессивно спамить warning’ами, люди быстро перестают обращать внимание на алерты. Если detection слишком мягкий, то реальные проблемы проходят мимо. Особенно тяжело анализировать AI-generated code, ведь он часто выглядит syntactically clean, но содержит опасные assumptions, которые плохо ловятся простыми сигнатурами. 🔗 Ссылки для скачивания: ➖ JetBrains  ➖ VS Code Marketplace Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #AppSec #SecureCoding #DevSecOps #IDE #CodeSecurity #OpenSource #SecureTechTalks

🦊 Mozilla подключили Claude к поиску уязвимостей в Firefox. В Mozilla решили проверить, можно ли использовать Claude как часть реального vulnerability research pipeline для Firefox. ⚙️ Анализ поведения Firefox активно включились в тестирование Claude Mythos по программе Preview. Разработчики давали модели широкие задачи: анализировать execution flow, искать подозрительные переходы состояний, изучать edge-case поведение API и проверять, как разные компоненты Firefox взаимодействуют между собой. Claude использовали как систему генерации гипотез, способную быстро проходить по большим объёмам кода и выделять места, где логика выглядит  необычной. 🧪 Как выглядел workflow Технически процесс оказался довольно занудным. Исследователь задавал область анализа, например, конкретный subsystem или API. Дальше модель разбирала код, строила reasoning вокруг возможных attack paths и пыталась определить, где нарушение инвариантов или некорректная обработка состояния может привести к security issue. После этого человек вручную проверял гипотезы и валидировал, существует ли проблема в реальности. Ключевое отличие от обычного static analysis здесь в том, что Claude не искал заранее известные паттерны уязвимостей. Модель пыталась анализировать поведение кода на уровне логики: 🔹 как данные проходят через subsystem 🔹 где возникают неожиданные комбинации условий 🔹 какие execution paths выглядят недостаточно защищёнными 🔍 Сильная сторона Модель не всегда находила уязвимость напрямую, но регулярно выводила исследователей в правильные участки codebase. Особенно хорошо это работало в сценариях, где проблема возникала не из-за одной ошибки, а из-за сложного взаимодействия нескольких компонентов или редких edge-case состояний. 🧨 А потом пришли галлюцинации Ограничения проявились почти сразу. Claude довольно легко терял архитектурный контекст в больших subsystem’ах Firefox, иногда придумывал execution paths, которых не существовало, и регулярно «галлюцинировал» свойства API. В некоторых случаях модель строила убедительное reasoning вокруг сценариев, которые технически были невозможны из-за ограничений runtime или внутренней логики браузера. В таком контексте автономный AI bug hunting пока крайне рискованная идея. Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #Firefox #Claude #BugBounty #AppSec #VulnerabilityResearch #Infosec #SecureTechTalks

🌊 Bluerock: добавляем runtime-безопасность в Kubernetes Kubernetes отлично умеет оркестрировать контейнеры. Но с безопасностью в runtime у него всегда были проблемы. Вы настраиваете RBAC, network policies, admission controllers и сканирование образов и ждете отсутствия рисков ИБ. Однако всё это в основном работает до запуска workload’а. После старта контейнера Kubernetes почти не понимает, что внутри него происходит на самом деле. ⚙️ Что же делать? Bluerock - это runtime security layer для Kubernetes. Платформа наблюдает за поведением контейнеров уже после запуска и анализирует: - запуск процессов - syscall activity - сетевые соединения - доступ к файловой системе взаимодействие pod’ов между собой - обращения к Kubernetes API Вместо анализа YAML-манифестов или образов система начинает смотреть на реальное поведение workload’а. 🧪 Так так так Bluerock активно использует eBPF, что позволяет перехватывать события прямо на уровне ядра Linux без модификации контейнеров: process execution, fork/exec chains, network flows, filesystem access и другие runtime-события. Дальше поверх этих данных строится policy engine. Политики задают допустимое поведение контейнера: - какие процессы могут запускаться, - какие outbound-соединения разрешены, - какие filesystem paths доступны, - какие действия считаются аномальными. Например: контейнеру можно разрешить только конкретные бинарники (python, nginx, node) и заблокировать запуск shell или неизвестных процессов. Или: разрешить обращения только к определённым API endpoints, запретив весь остальной outbound traffic. 🔒 Чем это отличается от обычной Kubernetes-защиты Большинство Kubernetes security-инструментов работают со статикой: сканируют образы, проверяют конфигурации или анализируют манифесты. Bluerock работает с runtime. Система анализирует не то, «как контейнер должен работать», а то, что он реально делает после запуска. Для современных AI- и agent-based workload’ов это особенно актуально, потому что их поведение может меняться динамически в зависимости от prompt’ов, контекста или внешних данных. 🔗 GitHub: https://github.com/bluerock-io/bluerock Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #Kubernetes #CloudSecurity #RuntimeSecurity #eBPF #DevSecOps #OpenSource #SecureTechTalks

🗺 AIMap: инструмент, который показывает, где на самом деле начинается  AI-атака С появлением LLM архитектура перестает быть очевидной. Раньше можно было нарисовать схему: тут фронт, вот API, здесь база и примерно понять, где проходит граница систем. В AI-приложениях граница распадается. Один запрос к модели может привести к вызову внешнего инструмента, обращению к API, извлечению данных из хранилища или генерации нового действия. Зачастую часть связей не фиксируется явно, она возникает на уровне prompt’ов, конфигураций агентов и оркестрации. В какой-то момент становится трудно ответить на базовый вопрос: что именно у нас вообще доступно для атаки? ⚙️ AIMap AIMap проходит по AI-приложению и строит карту взаимодействий, граф, где узлы - это модели, сервисы, инструменты и источники данных, а рёбра - реальные связи между ними. Инструмент собирает информацию из разных слоёв: описаний агентов, подключённых инструментов, доступных endpoints, путей, по которым данные могут проходить в процессе выполнения. На выходе получается рабочая модель системы, в которой видно, как она ведёт себя в реальности. 🧪 Разберем инструмент чуть подробнее AIMap выполняет следующие задачи: 1⃣ обнаруживает компоненты: - какие LLM используются, - какие у них интерфейсы, - какие плагины или инструменты подключены. 2⃣ извлекает информацию о доступных действиях: - какие функции может вызвать агент, - к каким API у него есть доступ, - какие источники данных подключены. 3⃣ строится фактический граф зависимостей. Если модель может вызвать инструмент, который в свою очередь ходит во внешний сервис, это становится частью цепочки. Если пользовательский ввод может повлиять на выбор инструмента, то это тоже фиксируется. Таким образом формируется execution graph, который отражает возможные пути прохождения запроса через систему. 🧨  Поверхность атаки Именно на этом графе начинают проявляться вещи, которые сложно увидеть иначе. Во-первых, становятся видны неочевидные транзитивные связи. Например, модель напрямую не имеет доступа к чувствительным данным, но через цепочку вызовов этот доступ появляется. Во-вторых, выявляются точки, где пользовательский ввод может влиять на поведение системы. Это потенциальные зоны для prompt injection и управления агентом. В-третьих, всплывают «забытые» интеграции, инструменты или endpoints, которые формально существуют, но не учитываются в модели угроз. 🔗 GitHub: https://github.com/BishopFox/aimap Stay secure and read SecureTechTalks 📚 #кибербезопасность #AI #LLM #AttackSurface #ThreatModeling #Infosec #CyberSecurity #AIrisks #OpenSource #SecureTechTalks