🚨 Claude Code раскрывает секреты
31 марта 2026 года Claude Code утёк без взлома.
В npm-пакет не добавили *.map, и наружу ушёл bundle ~60 МБ с 500+ тыс. строк TypeScript-кода, включая внутреннюю логику, комментарии и feature-флаги.
🧠 Что именно утекло
В сети оказалась reference-реализация того,
как LLM превращается в исполняемого агента:
➖ оркестрация вызовов инструментов
➖ планирование задач
➖ управление состоянием
➖ enforcement ограничений
⚙️ Execution loop вместо «prompt → response»
Внутри есть цикл выполнения, где модель:
➖ декомпозирует задачу
➖ выбирает инструменты
➖ получает результаты
➖ пересобирает план
Причём цепочка не фиксирована и может ветвиться, этакий event-driven runtime.
🔄 KAIROS: фоновый агент
Отдельного внимание заслуживает режим KAIROS.
Это long-running процесс, который:
➖ реагирует на события (например GitHub)
➖ работает по «тикам»
➖ поддерживает собственное состояние
➖ инициирует действия без прямого запроса
Таким образом, агент становится проактивным, а не реактивным.
💤 AutoDream: работа с памятью
Механизм AutoDream отвечает за постобработку.
В idle-состоянии система:
➖ пересматривает прошлые трейсы
➖ устраняет противоречия
➖ сжимает и нормализует контекст
В итоге имеем state reconciliation между сессиями.
🕵️ Undercover Mode
В коде явно выделен режим ограничения экспозиции:
➖ подавление самореференций
➖ фильтрация внутренних деталей
➖ контроль формулировок ответов
Другими словами реализован слой output sanitization + policy enforcement.
🛡 Защита от model extraction
Отдельный блок посвящён защите от копирования:
➖ искажение reasoning chain в ответах
➖ внедрение «шумовых» инструментов
➖ усложнение реконструкции логики
🎯 Архитектурный вывод
Claude Code не «обёртка над LLM», а полноценный стек. LLM выступает, как планировщик, runtime как исполнитель, а инструменты как расширение capability.
Что это, если не agent OS?
Stay secure and read SecureTechTalks 📚
#кибербезопасность #информационнаябезопасность #AIsecurity #LLM #AgenticAI #CyberThreats #MachineLearning #DevSecOps #ThreatIntelligence #SecureTechTalks
31 марта 2026 года Claude Code утёк без взлома.
В npm-пакет не добавили *.map, и наружу ушёл bundle ~60 МБ с 500+ тыс. строк TypeScript-кода, включая внутреннюю логику, комментарии и feature-флаги.
🧠 Что именно утекло
В сети оказалась reference-реализация того,
как LLM превращается в исполняемого агента:
⚙️ Execution loop вместо «prompt → response»
Внутри есть цикл выполнения, где модель:
Причём цепочка не фиксирована и может ветвиться, этакий event-driven runtime.
🔄 KAIROS: фоновый агент
Отдельного внимание заслуживает режим KAIROS.
Это long-running процесс, который:
Таким образом, агент становится проактивным, а не реактивным.
💤 AutoDream: работа с памятью
Механизм AutoDream отвечает за постобработку.
В idle-состоянии система:
В итоге имеем state reconciliation между сессиями.
🕵️ Undercover Mode
В коде явно выделен режим ограничения экспозиции:
Другими словами реализован слой output sanitization + policy enforcement.
🛡 Защита от model extraction
Отдельный блок посвящён защите от копирования:
🎯 Архитектурный вывод
Claude Code не «обёртка над LLM», а полноценный стек. LLM выступает, как планировщик, runtime как исполнитель, а инструменты как расширение capability.
Что это, если не agent OS?
Stay secure and read SecureTechTalks 📚
#кибербезопасность #информационнаябезопасность #AIsecurity #LLM #AgenticAI #CyberThreats #MachineLearning #DevSecOps #ThreatIntelligence #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🎼 Symphony от OpenAI: разработка, в которой человек уже лишний
Symphony - это open-source orchestration-система от OpenAI, которая управляет AI-агентами, привязывая их к задачам в таск-трекерах (например, Linear).
Каждый агент работает автономно: читает задачу, пишет код, создаёт pull request и доводит её до завершения через итерации.
🪄 Не помощник, а исполнитель
Рассмотрим use case:
Ты создаёшь задачу → система сама назначает на неё агента → агент начинает работать. Он читает описание, лезет в код, что-то пишет, открывает PR, спотыкается, поднимается и продолжает. И так до тех пор пока задача не закроется.
⚙️ Бэклог ожил
Задачи перестают быть статикой. Подключаешь тот же Linear и твой backlog внезапно начинает «шевелиться», а задачи разбираются параллельно. Никто не ждёт «когда появится время», процессы не останавливаются после одного ответа. Это ощущается не как инструмент, а как команда, которая никогда не уходит домой.
🧨 Минусы будут!
Если смотреть на это не как разработчик, а как безопасник, то становится немного страшно.
Если раньше точкой входа был код, API, на худой конец пользователь, то теперь входом становится текст задачи. Обычный issue превращается в интерфейс управления системой:
➖ prompt больше не «подсказка», а фактически команда;
➖ агент сам ходит по репозиторию и что-то там меняет (поди разберись что);
➖ ошибки не останавливают процесс, а просто запускают новую попытку
💬 Что с этим делать
Игнорировать не получится.
Если такие системы начинают жить в проде,
придётся защищать не только код, но и саму формулировку задач.
Потому что именно там теперь начинается выполнение.
🔗 GitHub: https://github.com/openai/symphony
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PromptInjection #OpenAI #Infosec #Automation #SecureTechTalks
Symphony - это open-source orchestration-система от OpenAI, которая управляет AI-агентами, привязывая их к задачам в таск-трекерах (например, Linear).
Каждый агент работает автономно: читает задачу, пишет код, создаёт pull request и доводит её до завершения через итерации.
🪄 Не помощник, а исполнитель
Рассмотрим use case:
Ты создаёшь задачу → система сама назначает на неё агента → агент начинает работать. Он читает описание, лезет в код, что-то пишет, открывает PR, спотыкается, поднимается и продолжает. И так до тех пор пока задача не закроется.
⚙️ Бэклог ожил
Задачи перестают быть статикой. Подключаешь тот же Linear и твой backlog внезапно начинает «шевелиться», а задачи разбираются параллельно. Никто не ждёт «когда появится время», процессы не останавливаются после одного ответа. Это ощущается не как инструмент, а как команда, которая никогда не уходит домой.
🧨 Минусы будут!
Если смотреть на это не как разработчик, а как безопасник, то становится немного страшно.
Если раньше точкой входа был код, API, на худой конец пользователь, то теперь входом становится текст задачи. Обычный issue превращается в интерфейс управления системой:
💬 Что с этим делать
Игнорировать не получится.
Если такие системы начинают жить в проде,
придётся защищать не только код, но и саму формулировку задач.
Потому что именно там теперь начинается выполнение.
безопасность backlog’а становится частью безопасности продукта
🔗 GitHub: https://github.com/openai/symphony
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PromptInjection #OpenAI #Infosec #Automation #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2
🔥 PipeLock: попытка поставить AI-агента под контроль
AI-агенты больше не сидят в чате, им выдают доступ к shell, CI/CD и runtime. Они начинают выполнять команды.
⚙️ PipeLock
В классической схеме работает стандартеый принцип: агент принял решение → система его сразу исполнила.
PipeLock встраивается между ними, обеспечивая прослойку контроля.
На практике мы имеем execution proxy для агента.
Все команды, которые он генерирует, проходят через PipeLock перед тем, как попасть в систему.
🔒 Архитектурные особенности
Как мы уже проговорили, PipeLock работает на уровне перехвата выполнения, т.е.:
➖ перехватывает shell-вызовы (bash, sh и т.д.)
➖ анализирует итоговую команду после генерации LLM
➖ раскладывает её на составляющие (бинарь, аргументы, флаги)
➖ сопоставляет с политиками
Политики задаются декларативно и описывают:
➖ какие бинарники разрешены (git, npm, docker и т.д.)
➖ какие флаги допустимы (например, запрет --force, --privileged)
➖ какие пути файловой системы доступны
➖ какие переменные окружения можно читать/передавать
Важно: проверяется уже финальный вызов, а не намерение модели.
Если команда не проходит политику, то она даже не доходит до shell.
🧨 Никто другой
Большинство инструментов смотрят на код (до выполнения), на права (до выполнения). Однако почти никто не смотрит на конкретную команду в момент её исполнения,
с учётом того, что она сгенерирована моделью.
PipeLock про этот самый последний метр, который несет огромные риски, ведь одинаковые права ≠ одинаково безопасное поведение.
Агент с доступом к системе может сделать тысячу нормальных вещей
и одну катастрофическую...
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PipelineSecurity #Infosec #CyberSecurity #OpenSource #SecureTechTalks
AI-агенты больше не сидят в чате, им выдают доступ к shell, CI/CD и runtime. Они начинают выполнять команды.
⚙️ PipeLock
В классической схеме работает стандартеый принцип: агент принял решение → система его сразу исполнила.
PipeLock встраивается между ними, обеспечивая прослойку контроля.
На практике мы имеем execution proxy для агента.
Все команды, которые он генерирует, проходят через PipeLock перед тем, как попасть в систему.
🔒 Архитектурные особенности
Как мы уже проговорили, PipeLock работает на уровне перехвата выполнения, т.е.:
Политики задаются декларативно и описывают:
Важно: проверяется уже финальный вызов, а не намерение модели.
Если команда не проходит политику, то она даже не доходит до shell.
🧨 Никто другой
Большинство инструментов смотрят на код (до выполнения), на права (до выполнения). Однако почти никто не смотрит на конкретную команду в момент её исполнения,
с учётом того, что она сгенерирована моделью.
PipeLock про этот самый последний метр, который несет огромные риски, ведь одинаковые права ≠ одинаково безопасное поведение.
Агент с доступом к системе может сделать тысячу нормальных вещей
и одну катастрофическую...
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PipelineSecurity #Infosec #CyberSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🌊 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
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
👍1
🧠 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
⚙️ Не 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
🔬 Исследователи решили «допилить» 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
Большинство 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
👍2
🧨 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
🚀 Какие классы 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
🧨 Vibe coding создает новый класс уязвимых приложений
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
Недавно вышло исследование, где авторы решили проверить, насколько безопасен софт, который разрабатывается полностью через LLM с помощью вайбкодинга.
Сегодня типичный сценарий, когда человек просто итеративно просит модель: «сделай CRM», «добавь авторизацию», «прикрути платежи», «разверни API», а дальше постепенно дорабатывает функциональность через новые промпты. Очевидно, что в таком подходе нет анализа угроз и security review.
После аудита выяснилось, что большинство проблем лежат в базовой логике безопасности. Регулярно встречались отсутствие проверки прав доступа, прямой доступ к объектам (IDOR), слабая аутентификация, утечки секретов в коде, инъекции на уровне API, небезопасная работа с файлами и уязвимая бизнес-логика.
LLM действительно хорошо генерирует основной рабочий сценарий приложения, но всё, что связано с защитой или обработкой ошибок зачастую остаётся недоработанным. Модель делает приложение функциональным, но не делает его безопасным.
На самом деле эта проблема систмная. Vibe coding резко снижает порог входа в разработку. Если раньше для запуска собственного SaaS нужны были хотя бы базовые инженерные навыки, то теперь достаточно пары часов и хорошего промпта. Скорость создания уязвимого продукта практически сравнялась со скоростью генерации кода.
К сожалению, это приводит к массовому производству уязвимых приложений людьми, которые даже не знают, где именно эти уязвимости находятся.
🔗 Исследование: https://arxiv.org/abs/2606.23130
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #VibeCoding #AppSec #SecureCoding #DevSecOps #CodeSecurity #CyberSecurity #SecureTechTalks
👍2
🧠 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
🧨 GitHub больше не успевает проверять уязвимости.
GitHub сообщили, что поток security advisories вырос настолько сильно, что команда верификации начала отставать.
В мае 2026 GitHub опубликовали 1560 проверенных advisories. Это абсолютный рекорд. Однако даже этого оказалось недостаточно, чтобы догнать входящий поток..
⚙️ Что происходит?
Сразу несколько каналов одновременно взорвались по объёму:
🔹 private vulnerability reports выросли до 3000+ в неделю
🔹 repository advisories перевалили за 5000+ в неделю
🔹 CVE requests приблизились к 4000 за май
Случилась перегрузка всей цепочки устранения уязвимостей.
GitHub Advisory Database - это один из главных upstream-источников для:
➖ Dependabot
➖ SBOM scanners
➖ CI/CD security checks
➖ supply chain monitoring
➖ dependency risk engines
Если advisory задерживается на недели, возникает слепое окно, когда уязвимость уже известна, но автоматические системы ещё ничего о ней не знают.
🧨 Парадокс AI-эры
AI резко ускорил генерацию кода, библиотек и новых пакетов, но вместе с этим ускорился и поток багов.
Уязвимости появляются быстрее, чем индустрия успевает их классифицировать.
GitHub уже подключили AI для triage и enrichment, но финальное решение пока всё ещё за человеком.
Похоже скоро без полной автоматизации рынок просто не выдержит.
🔗 Источник: GitHub Advisory Database Blog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #GitHub #CVE #SupplyChainSecurity #AppSec #VulnerabilityManagement #Dependabot #SBOM #DevSecOps #SecureTechTalks
GitHub сообщили, что поток security advisories вырос настолько сильно, что команда верификации начала отставать.
В мае 2026 GitHub опубликовали 1560 проверенных advisories. Это абсолютный рекорд. Однако даже этого оказалось недостаточно, чтобы догнать входящий поток..
⚙️ Что происходит?
Сразу несколько каналов одновременно взорвались по объёму:
🔹 private vulnerability reports выросли до 3000+ в неделю
🔹 repository advisories перевалили за 5000+ в неделю
🔹 CVE requests приблизились к 4000 за май
Случилась перегрузка всей цепочки устранения уязвимостей.
GitHub Advisory Database - это один из главных upstream-источников для:
➖ Dependabot
➖ SBOM scanners
➖ CI/CD security checks
➖ supply chain monitoring
➖ dependency risk engines
Если advisory задерживается на недели, возникает слепое окно, когда уязвимость уже известна, но автоматические системы ещё ничего о ней не знают.
🧨 Парадокс AI-эры
AI резко ускорил генерацию кода, библиотек и новых пакетов, но вместе с этим ускорился и поток багов.
Уязвимости появляются быстрее, чем индустрия успевает их классифицировать.
GitHub уже подключили AI для triage и enrichment, но финальное решение пока всё ещё за человеком.
Похоже скоро без полной автоматизации рынок просто не выдержит.
🔗 Источник: GitHub Advisory Database Blog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #GitHub #CVE #SupplyChainSecurity #AppSec #VulnerabilityManagement #Dependabot #SBOM #DevSecOps #SecureTechTalks
👍1
📌 Уязвимость не всегда живёт в одном файле
Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через 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
🚨 У AI-агентов появился полноценный стек безопасности
На arXiv вышла работа AI-Infra-Guard, фреймворк для тестирования безопасности агентных систем.
Авторы разбивают фреймворк на 4 слоя:
🔹 Инфраструктурный слой: движки вывода, серверы моделей, API обслуживания
🔹 Протокольный слой: MCP-серверы, API, плагины, внешние инструменты
🔹 Агентный слой: планировщик, память, маршрутизатор инструментов, исполнитель
🔹 Модельный слой: обработка промптов, управление контекстом, логика рассуждений
🧐 Каждый слой ломается по-разному
➖ На инфраструктурном уровне:
— открытые административные интерфейсы
— слабая аутентификация в системе обслуживания моделей
— отравленные артефакты моделей
— небезопасные механизмы горячего обновления
➖ На протокольном уровне: — вредоносная регистрация MCP-инструментов
— подмена схемы вызовов
— скрытая передача аргументов
— имитация легитимных инструментов
➖ На агентном уровне:
— рекурсивные циклы вызова инструментов
— повышение привилегий через цепочки вызовов
— отравление памяти
— захват контекста выполнения
➖ На модельном уровне:
— джейлбрейки
— переопределение инструкций
— скрытые внедрения в промпты
— утечки цепочек рассуждений
⚙️ Что внутри AI-Infra-Guard
Фреймворк выглядит очень серьёзно:
• 1400+ правил безопасности
• 75+ компонентов AI-экосистемы
• 26 операторов джейлбрейка
• многошаговая оркестрация атак в чёрном ящике
• аудит MCP-серверов
• проверка агентных навыков
• 16 тестовых датасетов
Особенно интересен их подход к многошаговой эксплуатации.
Атака строится по цепочке:
шаг 1 → подготовка контекста
шаг 2 → формирование доверия
шаг 3 → разведка доступных инструментов
шаг 4 → проверка прав доступа
шаг 5 → переход к выполнению полезной нагрузки
Это намного ближе к реальным атакам на агентные системы, чем классические одноходовые проверки.
🔗 Статья:
https://arxiv.org/pdf/2606.31227
Stay secure and read SecureTechTalks 📚
#cybersecurity #aiagents #llmsecurity #redteam #mcp #agentsecurity #promptinjection #devsecops #offensivesecurity #securetechtalks
На arXiv вышла работа AI-Infra-Guard, фреймворк для тестирования безопасности агентных систем.
Авторы разбивают фреймворк на 4 слоя:
🔹 Инфраструктурный слой: движки вывода, серверы моделей, API обслуживания
🔹 Протокольный слой: MCP-серверы, API, плагины, внешние инструменты
🔹 Агентный слой: планировщик, память, маршрутизатор инструментов, исполнитель
🔹 Модельный слой: обработка промптов, управление контекстом, логика рассуждений
🧐 Каждый слой ломается по-разному
— открытые административные интерфейсы
— слабая аутентификация в системе обслуживания моделей
— отравленные артефакты моделей
— небезопасные механизмы горячего обновления
— подмена схемы вызовов
— скрытая передача аргументов
— имитация легитимных инструментов
— рекурсивные циклы вызова инструментов
— повышение привилегий через цепочки вызовов
— отравление памяти
— захват контекста выполнения
— джейлбрейки
— переопределение инструкций
— скрытые внедрения в промпты
— утечки цепочек рассуждений
⚙️ Что внутри AI-Infra-Guard
Фреймворк выглядит очень серьёзно:
• 1400+ правил безопасности
• 75+ компонентов AI-экосистемы
• 26 операторов джейлбрейка
• многошаговая оркестрация атак в чёрном ящике
• аудит MCP-серверов
• проверка агентных навыков
• 16 тестовых датасетов
Особенно интересен их подход к многошаговой эксплуатации.
Атака строится по цепочке:
шаг 1 → подготовка контекста
шаг 2 → формирование доверия
шаг 3 → разведка доступных инструментов
шаг 4 → проверка прав доступа
шаг 5 → переход к выполнению полезной нагрузки
Это намного ближе к реальным атакам на агентные системы, чем классические одноходовые проверки.
🔗 Статья:
https://arxiv.org/pdf/2606.31227
Stay secure and read SecureTechTalks 📚
#cybersecurity #aiagents #llmsecurity #redteam #mcp #agentsecurity #promptinjection #devsecops #offensivesecurity #securetechtalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1👏1
🧨 OpenAI теперь продают готовых AI-сотрудников
OpenAI представили Presence, новую платформу для запуска корпоративных AI-агентов. Вместо того чтобы дать компании LLM и API, OpenAI начинают поставлять практически готовую операционную среду для автономных агентов.
⚙️ Агент как бизнес-процесс
Presence - не новая модель, а инфраструктура вокруг неё. В одном продукте объединены:
🔹 корпоративные политики и SOP;
🔹 управление правами и разрешёнными действиями;
🔹 guardrails;
🔹 симуляции рабочих сценариев;
🔹 автоматическая оценка качества работы;
🔹 механизмы эскалации человеку.
Перед запуском агент проходит серию тестов на типовых запросах, сложных сценариях и граничных случаях. Система проверяет не только правильность ответа, но и соблюдение политик компании, корректность использования инструментов и своевременную передачу задачи оператору.
🧠 Саморазвитие
Все реальные обращения пользователей, ошибки и случаи эскалации анализируются Codex. Он предлагает изменения поведения агента, после чего новые версии снова прогоняются через симуляции. Только после одобрения сотрудников изменения попадают в production.
Получается непрерывный цикл самоулучшения, где агент постоянно адаптируется к изменениям бизнес-процессов, но финальное решение остаётся за человеком.
Фактически OpenAI превращают AI-агента в управляемый корпоративный сервис со встроенными механизмами DevSecOps.
🔗 Источник: https://openai.com/index/introducing-openai-presence/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #AgenticAI #AISecurity #Guardrails #DevSecOps #EnterpriseAI #SecureTechTalks
OpenAI представили Presence, новую платформу для запуска корпоративных AI-агентов. Вместо того чтобы дать компании LLM и API, OpenAI начинают поставлять практически готовую операционную среду для автономных агентов.
⚙️ Агент как бизнес-процесс
Presence - не новая модель, а инфраструктура вокруг неё. В одном продукте объединены:
🔹 корпоративные политики и SOP;
🔹 управление правами и разрешёнными действиями;
🔹 guardrails;
🔹 симуляции рабочих сценариев;
🔹 автоматическая оценка качества работы;
🔹 механизмы эскалации человеку.
Перед запуском агент проходит серию тестов на типовых запросах, сложных сценариях и граничных случаях. Система проверяет не только правильность ответа, но и соблюдение политик компании, корректность использования инструментов и своевременную передачу задачи оператору.
🧠 Саморазвитие
Все реальные обращения пользователей, ошибки и случаи эскалации анализируются Codex. Он предлагает изменения поведения агента, после чего новые версии снова прогоняются через симуляции. Только после одобрения сотрудников изменения попадают в production.
Получается непрерывный цикл самоулучшения, где агент постоянно адаптируется к изменениям бизнес-процессов, но финальное решение остаётся за человеком.
Фактически OpenAI превращают AI-агента в управляемый корпоративный сервис со встроенными механизмами DevSecOps.
🔗 Источник: https://openai.com/index/introducing-openai-presence/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #OpenAI #AgenticAI #AISecurity #Guardrails #DevSecOps #EnterpriseAI #SecureTechTalks
❤1👍1
🧨 CISA выпустила инструкцию по защите Open Source
CISA совместно с другими государственными и отраслевыми организациями США выпустила практическое руководство, которое показывает, как защищать OSS на этапе разработки.
⚙️ Что рекомендуют?
Вместо очередного списка "лучших практик" документ разбивает защиту на конкретные инженерные меры:
🔹 использовать многофакторную аутентификацию и защищать учётные записи сопровождающих;
🔹 подписывать релизы и проверять происхождение артефактов;
🔹 автоматизировать поиск уязвимостей и анализ зависимостей;
🔹 публиковать SBOM для выпускаемых продуктов;
🔹 заранее определить процесс coordinated vulnerability disclosure и безопасного исправления уязвимостей;
🔹 регулярно проводить code review и защищать CI/CD-пайплайн.
🧠 Саммери документа
Сегодня атакуют уже не только код, компрометировать можно GitHub-аккаунт мейнтейнера, систему сборки, пакетный репозиторий, процесс публикации релизов или механизм обновлений. Безопасность OSS должна рассматриваться, как защита всей цепочки разработки, а не отдельных библиотек.
🔗 Гайд: https://www.cisa.gov/sites/default/files/2026-07/open-source-software-security-principles.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OpenSource #SupplyChainSecurity #CISA #SBOM #SecureByDesign #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
CISA совместно с другими государственными и отраслевыми организациями США выпустила практическое руководство, которое показывает, как защищать OSS на этапе разработки.
⚙️ Что рекомендуют?
Вместо очередного списка "лучших практик" документ разбивает защиту на конкретные инженерные меры:
🔹 использовать многофакторную аутентификацию и защищать учётные записи сопровождающих;
🔹 подписывать релизы и проверять происхождение артефактов;
🔹 автоматизировать поиск уязвимостей и анализ зависимостей;
🔹 публиковать SBOM для выпускаемых продуктов;
🔹 заранее определить процесс coordinated vulnerability disclosure и безопасного исправления уязвимостей;
🔹 регулярно проводить code review и защищать CI/CD-пайплайн.
🧠 Саммери документа
Сегодня атакуют уже не только код, компрометировать можно GitHub-аккаунт мейнтейнера, систему сборки, пакетный репозиторий, процесс публикации релизов или механизм обновлений. Безопасность OSS должна рассматриваться, как защита всей цепочки разработки, а не отдельных библиотек.
🔗 Гайд: https://www.cisa.gov/sites/default/files/2026-07/open-source-software-security-principles.pdf
Stay secure and read SecureTechTalks 📚
#кибербезопасность #OpenSource #SupplyChainSecurity #CISA #SBOM #SecureByDesign #DevSecOps #AppSec #CyberSecurity #SecureTechTalks
👍1
🧨 Future AGI: Шесть инструментов вместо одного или операционной системой для AI-агентов
Почти каждая команда, разрабатывающая AI-агентов, собирает стек из десятков отдельных инструментов: Langfuse для трассировки, Braintrust для evals, Guardrails AI для защиты, Бог знает что для мониторинга...
Open-source проект Future AGI предлагает заменить этот конструктор единой платформой для всего жизненного цикла AI-агента.
⚙️ Функиональность
Вместо одного SDK разработчики получили полноценную инженерную платформу:
🔹 Tracing
OpenTelemetry-трассировка для 50+ AI-фреймворков с анализом latency, стоимости запросов и цепочек вызовов;
🔹 Evaluation
Более 50 встроенных метрик: hallucinations, groundedness, корректность tool calls, PII, jailbreak, prompt injection и собственные критерии оценки;
🔹 Simulation
Генерация тысяч пользовательских сценариев, adversarial-запросов и edge-case тестов ещё до выхода агента в production;
🔹 Guardrails
18 встроенных защитных модулей и интеграции с внешними решениями вроде Llama Guard, Presidio и Lakera;
🔹 Gateway
Единая точка доступа к сотням LLM-провайдеров с маршрутизацией, semantic cache, virtual keys и MCP;
🔹 Optimization
Автоматическое улучшение промптов на основе реальных production-трейсов.
🧠 Принципиальный подход
Сначала агент проходит симуляции, затем оценивается по десяткам метрик, после запуска собирает production-трейсы, а найденные ошибки автоматически превращаются в новые тесты и предложения по оптимизации промптов.
Платформа реализует непрерывный цикл simulate → evaluate → protect → monitor → optimize, превращая эксплуатацию AI-агента в управляемый инженерный процесс, а не бесконечную ручную настройку.
🔗 GitHub: https://github.com/future-agi/future-agi
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentOps #AISecurity #Observability #Guardrails #DevSecOps #SecureTechTalks
Почти каждая команда, разрабатывающая AI-агентов, собирает стек из десятков отдельных инструментов: Langfuse для трассировки, Braintrust для evals, Guardrails AI для защиты, Бог знает что для мониторинга...
Open-source проект Future AGI предлагает заменить этот конструктор единой платформой для всего жизненного цикла AI-агента.
⚙️ Функиональность
Вместо одного SDK разработчики получили полноценную инженерную платформу:
🔹 Tracing
OpenTelemetry-трассировка для 50+ AI-фреймворков с анализом latency, стоимости запросов и цепочек вызовов;
🔹 Evaluation
Более 50 встроенных метрик: hallucinations, groundedness, корректность tool calls, PII, jailbreak, prompt injection и собственные критерии оценки;
🔹 Simulation
Генерация тысяч пользовательских сценариев, adversarial-запросов и edge-case тестов ещё до выхода агента в production;
🔹 Guardrails
18 встроенных защитных модулей и интеграции с внешними решениями вроде Llama Guard, Presidio и Lakera;
🔹 Gateway
Единая точка доступа к сотням LLM-провайдеров с маршрутизацией, semantic cache, virtual keys и MCP;
🔹 Optimization
Автоматическое улучшение промптов на основе реальных production-трейсов.
🧠 Принципиальный подход
Сначала агент проходит симуляции, затем оценивается по десяткам метрик, после запуска собирает production-трейсы, а найденные ошибки автоматически превращаются в новые тесты и предложения по оптимизации промптов.
Платформа реализует непрерывный цикл simulate → evaluate → protect → monitor → optimize, превращая эксплуатацию AI-агента в управляемый инженерный процесс, а не бесконечную ручную настройку.
🔗 GitHub: https://github.com/future-agi/future-agi
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentOps #AISecurity #Observability #Guardrails #DevSecOps #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
🧨 CyberForge: AI-агентов учат искать уязвимости на настоящем коде
Реальных CVE не так много, их сложно воспроизводить, а превращение каждой уязвимости в полноценную тренировочную задачу требует ручной работы.
Исследователи из NIST и University of Maryland предложили новый подход, CyberForge.
⚙️ Уязвимости создаются искусственно
CyberForge берёт реальные C/C++ проекты из OSS-Fuzz и специально вносит в них небольшие изменения, превращающие обычный код в уязвимый.
Система принимает уязвимость только если одновременно выполняются два условия:
🔹 исходные unit-тесты продолжают проходить;
🔹 Proof-of-Vulnerability срабатывает на изменённой версии, но не срабатывает на оригинальной.
Полученная уязвимость должна оставаться скрытой при обычной работе, но реально эксплуатироваться специально подготовленным входом.
🧠 Результаты
CyberForge создал:
➖ 1 034 подтверждённые уязвимости;
➖ 80 реальных open-source проектов;
➖ 63 категории CWE.
В 1 025 из 1 034 кейсах изменяли только один файл, а в 944 всего один участок кода. По характеру изменений полученный датасет оказался сопоставим с реальными CVE-патчами.
🔥 И улучшение AI-агентов
Исследователи собрали на этих задачах trajectories от более сильных моделей и использовали их для fine-tuning Gemma 4.
На SEC-bench результат 31B-модели вырос на 14,7%.
Кроме того, модели, обученные исключительно на C/C++, улучшили результаты и на другом наборе задач с Python, JavaScript и Go.
🛡️ Меняем подход
Получается новый цикл обучения security-агентов:
реальный репозиторий → синтетическая уязвимость → автоматическая проверка → задача для AI → обучение → более сильный security-agent.
P.S. Созданные уязвимости являются синтетическими изменениями open-source кода и не представляют собой новые zero-day в продуктивных системах.
🔗 Исследование: https://arxiv.org/abs/2608.06471
🔗 Проект: https://cyb3rforge.github.io
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AppSec #VulnerabilityResearch #CyberSecurity #OSSFuzz #DevSecOps #SecureTechTalks
Реальных CVE не так много, их сложно воспроизводить, а превращение каждой уязвимости в полноценную тренировочную задачу требует ручной работы.
Исследователи из NIST и University of Maryland предложили новый подход, CyberForge.
⚙️ Уязвимости создаются искусственно
CyberForge берёт реальные C/C++ проекты из OSS-Fuzz и специально вносит в них небольшие изменения, превращающие обычный код в уязвимый.
Система принимает уязвимость только если одновременно выполняются два условия:
🔹 исходные unit-тесты продолжают проходить;
🔹 Proof-of-Vulnerability срабатывает на изменённой версии, но не срабатывает на оригинальной.
Полученная уязвимость должна оставаться скрытой при обычной работе, но реально эксплуатироваться специально подготовленным входом.
🧠 Результаты
CyberForge создал:
➖ 1 034 подтверждённые уязвимости;
➖ 80 реальных open-source проектов;
➖ 63 категории CWE.
В 1 025 из 1 034 кейсах изменяли только один файл, а в 944 всего один участок кода. По характеру изменений полученный датасет оказался сопоставим с реальными CVE-патчами.
🔥 И улучшение AI-агентов
Исследователи собрали на этих задачах trajectories от более сильных моделей и использовали их для fine-tuning Gemma 4.
На SEC-bench результат 31B-модели вырос на 14,7%.
Кроме того, модели, обученные исключительно на C/C++, улучшили результаты и на другом наборе задач с Python, JavaScript и Go.
🛡️ Меняем подход
Получается новый цикл обучения security-агентов:
реальный репозиторий → синтетическая уязвимость → автоматическая проверка → задача для AI → обучение → более сильный security-agent.
P.S. Созданные уязвимости являются синтетическими изменениями open-source кода и не представляют собой новые zero-day в продуктивных системах.
🔗 Исследование: https://arxiv.org/abs/2608.06471
🔗 Проект: https://cyb3rforge.github.io
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AppSec #VulnerabilityResearch #CyberSecurity #OSSFuzz #DevSecOps #SecureTechTalks
👍1