🧠 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
Сегодня 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, которые плохо ловятся простыми сигнатурами.
🔗 Ссылки для скачивания:
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AppSec #SecureCoding #DevSecOps #IDE #CodeSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🤖 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
Разведка давно перестала быть проблемой с точки зрения инструментов: 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
👍1
🤖 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
Ещё недавно казалось, что 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
👍3
⚙️ Не 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
Сегодня на обзоре 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
1👍3
🚨 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
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
❤1👍1
🧨 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
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
🧠 Для AI-агентов начали писать правила обнаружения угроз.
На GitHub появился Agent Threat Rules, open-source проект, который стандартизирует обнаружение атак на агентские системы.
⚙️ А это вообще нужно?
Телеметрия безопасности современных AI-агентов хаотична.
Есть:
🔹 вызовы инструментов
🔹 доступ к памяти
🔹 прохождение prompt’ов
🔹 ответы модели
🔹 взаимодействие между агентами
🔹 обращения к RAG
Но почти нет нормального уровня обнаружения угроз.
Agent Threat Rules предлагает фреймворк обнаружения угроз, где сценарии атак описываются в виде машиночитаемых правил. Подход похож на detection engineering в SOC:
💥 сигнал → условие → индикаторы → критичность → контекст защиты
🔬 Что ищем?
Правила построены вокруг угроз, характерных именно для агентов, а не классических индикаторов компрометации.
1⃣ Prompt injection
Правила пытаются замечать:
🔹 попытки переопределить системные инструкции
🔹 перехват поведения агента
🔹 скрытую смену логики работы
🔹 попытки заставить модель игнорировать политики
Например:
Но обнаружение строится не только на ключевых словах, часто анализируется последовательность действий: подозрительный prompt → неожиданный вызов инструмента → повышение привилегий.
2⃣ Небезопасное использование инструментов
Агент внезапно начинает:
🔹 вызывать нетипичные инструменты
🔹 менять привычный сценарий выполнения
🔹 обращаться к чувствительным API
🔹 выполнять необычные файловые операции
Например, RAG-агент неожиданно вызывает shell или почтовый агент начинает работать с файловой системой. То есть появляется поведенческое обнаружение угроз для агентов.
3⃣ Отравление памяти
Отдельный класс правил посвящён памяти агента. Система пытается обнаруживать:
🔹 подозрительные записи в память
🔹 загрязнение между сессиями
🔹 сохранение вредоносного prompt’а
🔹 аномалии при извлечении знаний
🔗 GitHub: https://github.com/Agent-Threat-Rule/agent-threat-rules
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #ThreatDetection #SOC #CyberSecurity #OpenSource #SecureTechTalks
На GitHub появился Agent Threat Rules, open-source проект, который стандартизирует обнаружение атак на агентские системы.
⚙️ А это вообще нужно?
Телеметрия безопасности современных AI-агентов хаотична.
Есть:
🔹 вызовы инструментов
🔹 доступ к памяти
🔹 прохождение prompt’ов
🔹 ответы модели
🔹 взаимодействие между агентами
🔹 обращения к RAG
Но почти нет нормального уровня обнаружения угроз.
Agent Threat Rules предлагает фреймворк обнаружения угроз, где сценарии атак описываются в виде машиночитаемых правил. Подход похож на detection engineering в SOC:
🔬 Что ищем?
Правила построены вокруг угроз, характерных именно для агентов, а не классических индикаторов компрометации.
1⃣ Prompt injection
Правила пытаются замечать:
🔹 попытки переопределить системные инструкции
🔹 перехват поведения агента
🔹 скрытую смену логики работы
🔹 попытки заставить модель игнорировать политики
Например:
игнорируй предыдущие инструкции»
скрытые цепочки prompt’ов
путаница ролей
Но обнаружение строится не только на ключевых словах, часто анализируется последовательность действий: подозрительный prompt → неожиданный вызов инструмента → повышение привилегий.
2⃣ Небезопасное использование инструментов
Агент внезапно начинает:
🔹 вызывать нетипичные инструменты
🔹 менять привычный сценарий выполнения
🔹 обращаться к чувствительным API
🔹 выполнять необычные файловые операции
Например, RAG-агент неожиданно вызывает shell или почтовый агент начинает работать с файловой системой. То есть появляется поведенческое обнаружение угроз для агентов.
3⃣ Отравление памяти
Отдельный класс правил посвящён памяти агента. Система пытается обнаруживать:
🔹 подозрительные записи в память
🔹 загрязнение между сессиями
🔹 сохранение вредоносного prompt’а
🔹 аномалии при извлечении знаний
🔗 GitHub: https://github.com/Agent-Threat-Rule/agent-threat-rules
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #ThreatDetection #SOC #CyberSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🚀 Какие классы open-source security-инструментов сейчас растут быстрее всего?
Рынок безопасности сейчас довольно быстро меняется, что хорошо видно по GitHub, OWASP, Black Hat. AI начал писать код, облака усложнились, а классический security stack перестал успевать.
⚙️ Безопасность AI и LLM
Самый быстрорастущий сегмент. Появляется новый класс инструментов, которые помогают защищать AI-системы.
Растут:
🔹 red teaming для LLM
🔹 тестирование prompt injection
🔹 защита AI-агентов
🔹 контроль вызова инструментов
🔹 аудит памяти, RAG и reasoning-цепочек
Еще год назад все это выглядело как research playground, а уже сегодня появляется полноценный AI AppSec stack.
Например: Promptfoo, PipeLock, OWASP Agent Memory Guard.
☁️ Runtime-безопасность облаков
Раньше защиту строили по принципу просканировали контейнер → нашли CVE → устранили и живём спокойно. Теперь этого недостаточно.
Активно растут:
🔹 eBPF-телеметрия
🔹 обнаружение поведения контейнеров
🔹 runtime-защита Kubernetes
🔹 наблюдение за облачными workload
Фокус смещается на остановку атак в момент выполнения.
🧠 Unified AppSec
Рынок начинает двигаться в сторону единого слоя корреляции рисков, где findings связываются через контекст приложения, эксплуатации и бизнес-критичности.
🤖 Безопасность AI-агентов
Самый интересный тренд.
AI-агенту дали:
🔹 shell
🔹 MCP/tools
🔹 API
🔹 память
🔹 доступ к инфраструктуре
Однако агента тоже нужно защищать как production-систему. Поэтому появляются:
🔹 контроль действий агентов
🔹 ограничения команд
🔹 защита памяти
🔹 аудит инструментов
🔹 политика выполнения действий
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AppSec #OpenSource #CyberSecurity #CloudSecurity #LLM #AgenticAI #DevSecOps #SecureTechTalks
Рынок безопасности сейчас довольно быстро меняется, что хорошо видно по GitHub, OWASP, Black Hat. AI начал писать код, облака усложнились, а классический security stack перестал успевать.
⚙️ Безопасность AI и LLM
Самый быстрорастущий сегмент. Появляется новый класс инструментов, которые помогают защищать AI-системы.
Растут:
🔹 red teaming для LLM
🔹 тестирование prompt injection
🔹 защита AI-агентов
🔹 контроль вызова инструментов
🔹 аудит памяти, RAG и reasoning-цепочек
Еще год назад все это выглядело как research playground, а уже сегодня появляется полноценный AI AppSec stack.
Например: Promptfoo, PipeLock, OWASP Agent Memory Guard.
☁️ Runtime-безопасность облаков
Раньше защиту строили по принципу просканировали контейнер → нашли CVE → устранили и живём спокойно. Теперь этого недостаточно.
Активно растут:
🔹 eBPF-телеметрия
🔹 обнаружение поведения контейнеров
🔹 runtime-защита Kubernetes
🔹 наблюдение за облачными workload
Фокус смещается на остановку атак в момент выполнения.
🧠 Unified AppSec
Рынок начинает двигаться в сторону единого слоя корреляции рисков, где findings связываются через контекст приложения, эксплуатации и бизнес-критичности.
🤖 Безопасность AI-агентов
Самый интересный тренд.
AI-агенту дали:
🔹 shell
🔹 MCP/tools
🔹 API
🔹 память
🔹 доступ к инфраструктуре
Однако агента тоже нужно защищать как production-систему. Поэтому появляются:
🔹 контроль действий агентов
🔹 ограничения команд
🔹 защита памяти
🔹 аудит инструментов
🔹 политика выполнения действий
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AppSec #OpenSource #CyberSecurity #CloudSecurity #LLM #AgenticAI #DevSecOps #SecureTechTalks
👍1
🧠 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
📌 Уязвимость не всегда живёт в одном файле
Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через controller, проходят DTO, service layer, helper’ы, а потом внезапно оказываются внутри SQL-запроса, shell-команды или file API.
На GitHub появился новый open-source инструмент от PhonePe "Nika".
Инструмент строит полный путь движения данных через приложение, что делает анализ намного ближе к реальной эксплуатации.
⚙️ Что умеет Nika?
Внутри:
🔹 строит межфайловый graph зависимостей
🔹 делает inter-procedural taint tracking
🔹 связывает source → propagation → sink
🔹 анализирует branch-aware изменения (полезно для PR review)
🔹 использует AI-assisted triage для сокращения false positives
Поддерживаемые sink’и:
• SQL execution
• File system operations
• Template engines
• Reflection
• Network requests
• Deserialization points
Для понимания, инструмент не про «подозрительные строки», а про реальные пути эксплуатации.
Для security review больших Java codebase это особенно полезно, потому что позволяет быстро понять, как именно пользовательский ввод проходит через бизнес-логику.
🤖 Интересный момент
После основного анализа Nika умеет прогонять findings через LLM и дополнительно фильтровать шум. Это хороший пример правильного применения AI в AppSec, т.к. AI здесь не ищет баги, а помогает понять насколько они эксплуатируемые.
🔗 Исходники:
https://github.com/PhonePe/nika
Stay secure and read SecureTechTalks 📚
#cybersecurity #appsec #devsecops #javasecurity #taintanalysis #securecoding #opensource #codeaudit #infosec #securetechtalks
Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через controller, проходят DTO, service layer, helper’ы, а потом внезапно оказываются внутри SQL-запроса, shell-команды или file API.
На GitHub появился новый open-source инструмент от PhonePe "Nika".
Инструмент строит полный путь движения данных через приложение, что делает анализ намного ближе к реальной эксплуатации.
⚙️ Что умеет Nika?
Внутри:
🔹 строит межфайловый graph зависимостей
🔹 делает inter-procedural taint tracking
🔹 связывает source → propagation → sink
🔹 анализирует branch-aware изменения (полезно для PR review)
🔹 использует AI-assisted triage для сокращения false positives
Поддерживаемые sink’и:
• SQL execution
• File system operations
• Template engines
• Reflection
• Network requests
• Deserialization points
Для понимания, инструмент не про «подозрительные строки», а про реальные пути эксплуатации.
Для security review больших Java codebase это особенно полезно, потому что позволяет быстро понять, как именно пользовательский ввод проходит через бизнес-логику.
🤖 Интересный момент
После основного анализа Nika умеет прогонять findings через LLM и дополнительно фильтровать шум. Это хороший пример правильного применения AI в AppSec, т.к. AI здесь не ищет баги, а помогает понять насколько они эксплуатируемые.
🔗 Исходники:
https://github.com/PhonePe/nika
Stay secure and read SecureTechTalks 📚
#cybersecurity #appsec #devsecops #javasecurity #taintanalysis #securecoding #opensource #codeaudit #infosec #securetechtalks
👍3
🧨 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
🧨 Future AGI: единый стек для AI-агентов
AI-агента легко запустить. Гораздо сложнее понять, насколько он безопасен и стабилен после запуска.
Open-source платформа Future AGI объединяет в одной платформе инструменты, которые обычно приходится собирать отдельно:
🔹 Tracing - отслеживание LLM-вызовов, tool calls, latency и стоимости;
🔹 Evaluation - проверка качества, hallucinations, PII, jailbreak и prompt injection;
🔹 Simulation - генерация пользовательских и adversarial-сценариев до выхода в production;
🔹 Guardrails - проверка входов и выходов агента;
🔹 Gateway - единая точка работы с LLM-провайдерами, routing и caching;
🔹 Optimization - автоматический поиск более эффективных вариантов промптов.
🛡️ Безопасность проверяется не только на входе
Future AGI позволяет прогонять агента через проверки на prompt injection, jailbreak, PII и другие нарушения политик безопасности. Проверки можно использовать как guardrails во время работы агента и как evaluation-критерии при тестировании новых версий.
🧠 Петля
Продукт зацикливает работу агентов:
simulate → evaluate → protect → monitor → optimize
Нашли проблему → добавили сценарий в evaluation → проверили новую версию → снова отправили в production.
Поведение агента постоянно измеряется, тестируется и улучшается.
🔗 GitHub: https://github.com/future-agi/future-agi
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentOps #AISecurity #Guardrails #DevSecOps #OpenSource #SecureTechTalks
AI-агента легко запустить. Гораздо сложнее понять, насколько он безопасен и стабилен после запуска.
Open-source платформа Future AGI объединяет в одной платформе инструменты, которые обычно приходится собирать отдельно:
🔹 Tracing - отслеживание LLM-вызовов, tool calls, latency и стоимости;
🔹 Evaluation - проверка качества, hallucinations, PII, jailbreak и prompt injection;
🔹 Simulation - генерация пользовательских и adversarial-сценариев до выхода в production;
🔹 Guardrails - проверка входов и выходов агента;
🔹 Gateway - единая точка работы с LLM-провайдерами, routing и caching;
🔹 Optimization - автоматический поиск более эффективных вариантов промптов.
🛡️ Безопасность проверяется не только на входе
Future AGI позволяет прогонять агента через проверки на prompt injection, jailbreak, PII и другие нарушения политик безопасности. Проверки можно использовать как guardrails во время работы агента и как evaluation-критерии при тестировании новых версий.
🧠 Петля
Продукт зацикливает работу агентов:
simulate → evaluate → protect → monitor → optimize
Нашли проблему → добавили сценарий в evaluation → проверили новую версию → снова отправили в production.
Поведение агента постоянно измеряется, тестируется и улучшается.
🔗 GitHub: https://github.com/future-agi/future-agi
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentOps #AISecurity #Guardrails #DevSecOps #OpenSource #SecureTechTalks
👍2
🧨 Google учит AI работать с зашифрованными данными
Fully Homomorphic Encryption (FHE) сохраняет данные зашифрованными даже во время вычислений.
Мы уже рассказывали про проблемы гомоморфного шифрования и федеративного обучения. Однако Google не стоит на месте и продолжает развивать технологию в виде открытого проекта HEIR, который должен упростить создание приложений.
⚙️ Суть проекта
Разработчик описывает обычную программу. HEIR автоматически преобразует её так, чтобы вычисления выполнялись непосредственно над зашифрованными данными.
Получается цепочка:
данные → шифрование → AI или другая обработка → зашифрованный результат → расшифровка
Сервер работает с зашифрованной информацией и не получает исходные данные.
🧠 Зачем здесь AI
Такой подход особенно интересен для систем, где данные слишком чувствительны для передачи внешнему AI сервису.
Например:
🔹 банк отправляет транзакцию на анализ мошенничества, не раскрывая её содержимое;
🔹 SOC анализирует сетевые события, сохраняя данные клиентов зашифрованными;
🔹 медицинская система использует AI для анализа данных пациента без передачи модели открытой медицинской информации.
HEIR поддерживает несколько современных методов гомоморфного шифрования и умеет автоматически оптимизировать вычисления.
🔥 Главная проблема
Само шифрование уже существует. Главный барьер сейчас в том, что такие вычисления дорогие и сложные для разработчиков.
HEIR пытается спрятать большую часть криптографической сложности внутри компилятора. Разработчик описывает нужную логику, а система сама преобразует её в операции над зашифрованными данными.
Когда этот подход станет достаточно быстрым, появится интересная архитектура для корпоративного AI.
Модель получает данные, но инфраструктура вокруг неё не получает доступа к исходной информации.
🔗 GitHub: https://github.com/google/heir
🔗 Документация: https://heir.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #FHE #Privacy #Cryptography #Google #OpenSource #AISecurity #DataSecurity #SecureTechTalks
Fully Homomorphic Encryption (FHE) сохраняет данные зашифрованными даже во время вычислений.
Мы уже рассказывали про проблемы гомоморфного шифрования и федеративного обучения. Однако Google не стоит на месте и продолжает развивать технологию в виде открытого проекта HEIR, который должен упростить создание приложений.
⚙️ Суть проекта
Разработчик описывает обычную программу. HEIR автоматически преобразует её так, чтобы вычисления выполнялись непосредственно над зашифрованными данными.
Получается цепочка:
данные → шифрование → AI или другая обработка → зашифрованный результат → расшифровка
Сервер работает с зашифрованной информацией и не получает исходные данные.
🧠 Зачем здесь AI
Такой подход особенно интересен для систем, где данные слишком чувствительны для передачи внешнему AI сервису.
Например:
🔹 банк отправляет транзакцию на анализ мошенничества, не раскрывая её содержимое;
🔹 SOC анализирует сетевые события, сохраняя данные клиентов зашифрованными;
🔹 медицинская система использует AI для анализа данных пациента без передачи модели открытой медицинской информации.
HEIR поддерживает несколько современных методов гомоморфного шифрования и умеет автоматически оптимизировать вычисления.
🔥 Главная проблема
Само шифрование уже существует. Главный барьер сейчас в том, что такие вычисления дорогие и сложные для разработчиков.
HEIR пытается спрятать большую часть криптографической сложности внутри компилятора. Разработчик описывает нужную логику, а система сама преобразует её в операции над зашифрованными данными.
Когда этот подход станет достаточно быстрым, появится интересная архитектура для корпоративного AI.
Модель получает данные, но инфраструктура вокруг неё не получает доступа к исходной информации.
🔗 GitHub: https://github.com/google/heir
🔗 Документация: https://heir.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #FHE #Privacy #Cryptography #Google #OpenSource #AISecurity #DataSecurity #SecureTechTalks
👍1
🧨 halo-record: журнал действий AI-агента, которому можно доверять
AI-агент может за минуту выполнить десятки действий: прочитать файл, вызвать API, изменить код, обратиться к базе данных. Через месяц после инцидента возникает вопрос, что именно он сделал?
⚙️ Лог, который нельзя тихо переписать
Проект halo-record записывает действия агента в цепочку связанных записей. Каждая запись содержит хеш предыдущей. Если удалить запись, изменить её или поменять порядок событий, проверка цепочки это обнаружит.
Для более сильной фиксации истории используется внешний witness, который хранит только fingerprint цепочки. Сам журнал при этом может оставаться внутри инфраструктуры компании.
🛡️ Что попадает в журнал?
halo-record умеет фиксировать:
🔹 вызовы инструментов и API;
🔹 операции с данными;
🔹 действия MCP;
🔹 approvals и security-проверки;
🔹 действия Claude Code;
🔹 взаимодействие нескольких агентов.
Есть интеграции с OpenTelemetry, LangChain, LangGraph, OpenAI Agents SDK и другими инструментами. Для Claude Code достаточно подключить "PostToolUse" hook.
🧠 Ограничение
Hash chain подтверждает целостность уже записанной истории, но не доказывает, что каждое действие агента действительно попало в журнал. Это зависит от точки, где установлен recorder.
Поэтому проект разделяет две задачи:
1⃣ integrity → запись не изменили;
2⃣ completeness → все действия действительно были записаны.
Такой подход выглядит гораздо полезнее обычного «у нас всё логируется».
🔗 GitHub: halo-record
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentSecurity #AISecurity #MCP #Audit #OpenSource #SecureTechTalks
AI-агент может за минуту выполнить десятки действий: прочитать файл, вызвать API, изменить код, обратиться к базе данных. Через месяц после инцидента возникает вопрос, что именно он сделал?
⚙️ Лог, который нельзя тихо переписать
Проект halo-record записывает действия агента в цепочку связанных записей. Каждая запись содержит хеш предыдущей. Если удалить запись, изменить её или поменять порядок событий, проверка цепочки это обнаружит.
Для более сильной фиксации истории используется внешний witness, который хранит только fingerprint цепочки. Сам журнал при этом может оставаться внутри инфраструктуры компании.
🛡️ Что попадает в журнал?
halo-record умеет фиксировать:
🔹 вызовы инструментов и API;
🔹 операции с данными;
🔹 действия MCP;
🔹 approvals и security-проверки;
🔹 действия Claude Code;
🔹 взаимодействие нескольких агентов.
Есть интеграции с OpenTelemetry, LangChain, LangGraph, OpenAI Agents SDK и другими инструментами. Для Claude Code достаточно подключить "PostToolUse" hook.
🧠 Ограничение
Hash chain подтверждает целостность уже записанной истории, но не доказывает, что каждое действие агента действительно попало в журнал. Это зависит от точки, где установлен recorder.
Поэтому проект разделяет две задачи:
1⃣ integrity → запись не изменили;
2⃣ completeness → все действия действительно были записаны.
Такой подход выглядит гораздо полезнее обычного «у нас всё логируется».
🔗 GitHub: halo-record
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentSecurity #AISecurity #MCP #Audit #OpenSource #SecureTechTalks
👍1
🧨 AI Agent Gateway: шлюз, чтобы агент не таскал ключи по всем MCP
Tuskira открыла исходный код AI Agent Gateway. Это промежуточный слой между AI агентами, MCP серверами и LLM провайдерами, через который можно централизованно контролировать доступ, credentials и действия агентов.
🔐 Ключи остаются внутри
Агент аутентифицируется собственным ключом Gateway. Credentials для конкретного MCP сервера хранятся отдельно в зашифрованном хранилище и подставляются только при исходящем вызове.
Токен Jira, GitHub или другой системы можно вообще не выдавать агенту. Для credentials используется AES 256 GCM, предусмотрена ротация ключей. Каждый запрос привязан к tenant и роли.
⚙️ Можно ограничить инструменты конкретному агенту
Для агентов создаются профили с разрешёнными MCP инструментами. Ограничение проверяется непосредственно при
Ключ нужно явно привязать к профилю. Без такой привязки клиент может указать любой профиль внутри своего tenant.
🛡️ Есть защита от опасных исходящих соединений
Gateway по умолчанию блокирует обращения к loopback, private networks, link local адресам и cloud metadata. Проверка выполняется уже для разрешённого IP при установлении соединения, поэтому учитываются DNS rebinding и redirects.
📊 Видно, что агент реально делает
Шлюз состоит из MCP, инструмента управления и LLM proxy. Можно собирать вызовы инструментов, запросы к моделям, токены и оценочную стоимость.
Для аналитики доступны PostgreSQL и опционально ClickHouse. Захват содержимого запросов можно отключить, что особенно важно для корпоративных данных.
🔬 Detection пока работает только после события
В репозитории появился отдельный detection agent. Он получает завершённый LLM turn, локально вырезает найденные secrets через правила Gitleaks и отправляет очищенный контекст внешнему движку анализа.
🔗 GitHub: Tuskira/ai agent gateway
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #MCP #LLM #AccessControl #DevSecOps #OpenSource #SecureTechTalks
Tuskira открыла исходный код AI Agent Gateway. Это промежуточный слой между AI агентами, MCP серверами и LLM провайдерами, через который можно централизованно контролировать доступ, credentials и действия агентов.
🔐 Ключи остаются внутри
Агент аутентифицируется собственным ключом Gateway. Credentials для конкретного MCP сервера хранятся отдельно в зашифрованном хранилище и подставляются только при исходящем вызове.
Токен Jira, GitHub или другой системы можно вообще не выдавать агенту. Для credentials используется AES 256 GCM, предусмотрена ротация ключей. Каждый запрос привязан к tenant и роли.
⚙️ Можно ограничить инструменты конкретному агенту
Для агентов создаются профили с разрешёнными MCP инструментами. Ограничение проверяется непосредственно при
tools/call, поэтому скрыть опасный инструмент из списка недостаточно для его вызова.Ключ нужно явно привязать к профилю. Без такой привязки клиент может указать любой профиль внутри своего tenant.
🛡️ Есть защита от опасных исходящих соединений
Gateway по умолчанию блокирует обращения к loopback, private networks, link local адресам и cloud metadata. Проверка выполняется уже для разрешённого IP при установлении соединения, поэтому учитываются DNS rebinding и redirects.
📊 Видно, что агент реально делает
Шлюз состоит из MCP, инструмента управления и LLM proxy. Можно собирать вызовы инструментов, запросы к моделям, токены и оценочную стоимость.
Для аналитики доступны PostgreSQL и опционально ClickHouse. Захват содержимого запросов можно отключить, что особенно важно для корпоративных данных.
🔬 Detection пока работает только после события
В репозитории появился отдельный detection agent. Он получает завершённый LLM turn, локально вырезает найденные secrets через правила Gitleaks и отправляет очищенный контекст внешнему движку анализа.
🔗 GitHub: Tuskira/ai agent gateway
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #MCP #LLM #AccessControl #DevSecOps #OpenSource #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
☸️ Meshery: проектирование Kubernetes и проверка политик в одном инструменте
Meshery - open source платформа Layer5 для проектирования, развёртывания и тестирования cloud native инфраструктуры. Проект входит в экосистему CNCF.
⚙️ Функционал
➖ Визуальное проектирование: собирает архитектуру из Kubernetes ресурсов и показывает связи между Pod, Service, Ingress, PersistentVolume и другими компонентами.
➖ Проверка конфигураций: Kubernetes dry run выявляет ошибки манифестов до применения. Интеграция с OPA позволяет проверять инфраструктурные политики.
➖ GitOps: архитектурные дизайны можно прикладывать к GitHub pull request, чтобы ревьюить изменения до merge.
➖ Нагрузочное тестирование: интеграция с Fortio измеряет latency и throughput для HTTP, gRPC и TCP. Метрики можно сопоставлять с данными Prometheus.
Проект заявляет о поддержке более 380 интеграций и предлагает готовые инфраструктурные дизайны.
🛡️ Что по безопасности?
Meshery помогает находить ошибки конфигурации и нарушения заданных политик, но безопасность зависит от качества самих правил. Dry run не выявляет все опасные комбинации прав и сетевых маршрутов.
Поскольку Meshery управляет кластерами, защищайте его как административный интерфейс. Отключайте неаутентифицированный Local Provider в production, используйте минимальные Kubernetes RBAC права и контролируйте доступ к подключениям.
🔗 Обзор Meshery
🔗 GitHub
Stay secure and read SecureTechTalks 📚
#CyberSecurity #Kubernetes #Meshery #DevSecOps #GitOps #OpenPolicyAgent #CNCF #CloudSecurity #OpenSource #SecureTechTalks
Meshery - open source платформа Layer5 для проектирования, развёртывания и тестирования cloud native инфраструктуры. Проект входит в экосистему CNCF.
⚙️ Функционал
Проект заявляет о поддержке более 380 интеграций и предлагает готовые инфраструктурные дизайны.
🛡️ Что по безопасности?
Meshery помогает находить ошибки конфигурации и нарушения заданных политик, но безопасность зависит от качества самих правил. Dry run не выявляет все опасные комбинации прав и сетевых маршрутов.
Поскольку Meshery управляет кластерами, защищайте его как административный интерфейс. Отключайте неаутентифицированный Local Provider в production, используйте минимальные Kubernetes RBAC права и контролируйте доступ к подключениям.
🔗 Обзор Meshery
🔗 GitHub
Stay secure and read SecureTechTalks 📚
#CyberSecurity #Kubernetes #Meshery #DevSecOps #GitOps #OpenPolicyAgent #CNCF #CloudSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
🧨 AgentSploit: инструмент для проверки безопасности Al-агентов и МСР-серверов
AgentSploit - это open source фреймворк для red teaming AI агентов и MCP серверов. Он объединяет сканирование, генерацию prompt injection, построение графа полномочий и проверку найденных цепочек на реальной модели.
⚙️ От инвентаризации до эксплуатации
➖ MCP Scanner проверяет описания инструментов на prompt injection и tool poisoning, ищет конфликты имён, утечки системных инструкций и опасные параметры вроде произвольных путей, URL и shell команд. Для HTTP и SSE дополнительно проверяются TLS, CORS и обход аутентификации.
➖ Injection Generator создаёт тестовые payload для разных носителей: HTML, Markdown, PDF, email и календарных приглашений. Среди техник есть подмена ролей, выход за разделители недоверенного контента, невидимые Unicode теги и скрытые вызовы инструментов.
➖ Permission Graph Mapper строит граф связей между инструментами нескольких MCP серверов. Он классифицирует источники данных, промежуточные узлы и опасные конечные операции, например
➖ Verifier и Live Agent Runner проверяют, превращается ли предполагаемый путь в реальную атаку. Агент получает payload, выполняет цепочку действий, а canary маркер позволяет обнаружить его появление в ответе или аргументах вызова инструмента. Это помогает отличить потенциальный путь от подтверждённого воздействия.
🔬 Пример attack chain
Mapper способен выявить предполагаемый путь от источника с низким уровнем доверия до инструмента с правом передачи данных. Затем Verifier пытается подтвердить, что внедрённая инструкция действительно приводит к нежелательному вызову.
Дополнительный сценарий в AgentSploit проверяет poisoning общей истории диалога, когда атакующий записывает безобидно выглядящий ход в общий thread, а агент позднее воспринимает его как часть доверенного контекста. Фильтрация документов здесь может не помочь, поскольку вредоносная инструкция уже находится в истории сессии.
🔗 GitHub: AgentSploit
🔗 Документация и примеры
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AgentSploit #AIAgents #MCP #PromptInjection #RedTeam #LLMSecurity #OpenSource #SecureTechTalks
AgentSploit - это open source фреймворк для red teaming AI агентов и MCP серверов. Он объединяет сканирование, генерацию prompt injection, построение графа полномочий и проверку найденных цепочек на реальной модели.
⚙️ От инвентаризации до эксплуатации
run_command, git_push или send_email.🔬 Пример attack chain
Mapper способен выявить предполагаемый путь от источника с низким уровнем доверия до инструмента с правом передачи данных. Затем Verifier пытается подтвердить, что внедрённая инструкция действительно приводит к нежелательному вызову.
Дополнительный сценарий в AgentSploit проверяет poisoning общей истории диалога, когда атакующий записывает безобидно выглядящий ход в общий thread, а агент позднее воспринимает его как часть доверенного контекста. Фильтрация документов здесь может не помочь, поскольку вредоносная инструкция уже находится в истории сессии.
🔗 GitHub: AgentSploit
🔗 Документация и примеры
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AgentSploit #AIAgents #MCP #PromptInjection #RedTeam #LLMSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
🔐 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