🧠 CISO Assistant: open-source инструмент для тех, кто управляет ИБ, а не просто тушит пожары
В кибербезопасности есть странный перекос, мы отлично умеем искать уязвимости, формировать алерты и писать отчёты об инцидентах. Но как только разговор заходит о рисках, приоритетах и реальном состоянии ИБ-программы, всё внезапно возвращается к Excel и презентациям.
CISO Assistant - это попытка улучшить именно эту часть ИБ через системное управление рисками, контролем и требованиями.
Проект развивается как open-source Community Edition и ориентирован прежде всего на CISO, security-менеджеров и GRC-специалистов. То есть на тех, кто отвечает не только за технику, но и за целостную картину безопасности.
💡 В чём идея
Ключевая идея продукта банальна, но редко реализуется на практике:
👉 Риски, требования и контроль должны быть связаны между собой.
В жизни мы обычно видим обратную картину:
📁 ISO живёт в одном файле,
📊 риски в другом,
📝 аудит в третьем,
🛡сценарии реагирования «где-то еще».
По факту все это должно быть обьединено в логической цепочке:
⚠️ риск → 📜 требования → 🛡 контроли → 📈 статус и доказательства.
Именно вокруг этой логики и построена платформа.
⚙️ Что на практике?
CISO Assistant - это веб-приложение с чёткой моделью данных.
Фреймворки вроде ISO/IEC 27001, NIST CSF или CIS Controls представлены, как «живые» объекты.
Их можно:
✏️ адаптировать под свою организацию,
➖ отключать нерелевантные требования,
👀 сразу видеть, что реально внедрено, а что существует только формально.
Риски здесь тоже не абстрактные. Для каждого риска можно описать источник угрозы, связать его с активами, оценить вероятность и влияние, а главное, привязать конкретные контроли.
📊 В результате становится видно, какие риски реально снижаются, какие приняты осознанно, а какие просто зависли без владельца.
Контроль - отдельная сильная сторона: полноценный объект со статусом внедрения, ответственным, историей изменений и доказательствами. Такой подход заметно упрощает внутренние аудиты и самооценку.
⏳ А нужно ли это все?
Современные руководители ИБ управляют сложными системами. CISO Assistant помогает навести порядок: связать требования, риски и реальные меры в одну понятную картину, которую можно объяснить не только ИБ-специалисту, но и бизнесу.
Да, «AI-магии» здесь нет, и кнопки «сделай безопасно» тоже.
Зато есть прозрачность, контроль и возможность доработки под собственные процессы.
🧨 Пара слов в конце
Данный продукт - это редкий пример open-source инструмента, который работает не на уровне алертов, а на уровне смыслов.
Он не ловит атаки, не заменяет SOC, не реагирует на инциденты.
При этом он помогает: понять, где вы действительно защищены, какие риски реальны, а где безопасность существует только в отчётах.
🔗 GitHub:
https://github.com/intuitem/ciso-assistant-community
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CISO #GRC #RiskManagement #CyberSecurity #Infosec #ISO27001 #SecurityManagement #OpenSource
В кибербезопасности есть странный перекос, мы отлично умеем искать уязвимости, формировать алерты и писать отчёты об инцидентах. Но как только разговор заходит о рисках, приоритетах и реальном состоянии ИБ-программы, всё внезапно возвращается к Excel и презентациям.
CISO Assistant - это попытка улучшить именно эту часть ИБ через системное управление рисками, контролем и требованиями.
Проект развивается как open-source Community Edition и ориентирован прежде всего на CISO, security-менеджеров и GRC-специалистов. То есть на тех, кто отвечает не только за технику, но и за целостную картину безопасности.
💡 В чём идея
Ключевая идея продукта банальна, но редко реализуется на практике:
👉 Риски, требования и контроль должны быть связаны между собой.
В жизни мы обычно видим обратную картину:
📁 ISO живёт в одном файле,
📊 риски в другом,
📝 аудит в третьем,
🛡сценарии реагирования «где-то еще».
По факту все это должно быть обьединено в логической цепочке:
⚠️ риск → 📜 требования → 🛡 контроли → 📈 статус и доказательства.
Именно вокруг этой логики и построена платформа.
⚙️ Что на практике?
CISO Assistant - это веб-приложение с чёткой моделью данных.
Фреймворки вроде ISO/IEC 27001, NIST CSF или CIS Controls представлены, как «живые» объекты.
Их можно:
✏️ адаптировать под свою организацию,
➖ отключать нерелевантные требования,
👀 сразу видеть, что реально внедрено, а что существует только формально.
Риски здесь тоже не абстрактные. Для каждого риска можно описать источник угрозы, связать его с активами, оценить вероятность и влияние, а главное, привязать конкретные контроли.
📊 В результате становится видно, какие риски реально снижаются, какие приняты осознанно, а какие просто зависли без владельца.
Контроль - отдельная сильная сторона: полноценный объект со статусом внедрения, ответственным, историей изменений и доказательствами. Такой подход заметно упрощает внутренние аудиты и самооценку.
⏳ А нужно ли это все?
Современные руководители ИБ управляют сложными системами. CISO Assistant помогает навести порядок: связать требования, риски и реальные меры в одну понятную картину, которую можно объяснить не только ИБ-специалисту, но и бизнесу.
Да, «AI-магии» здесь нет, и кнопки «сделай безопасно» тоже.
Зато есть прозрачность, контроль и возможность доработки под собственные процессы.
🧨 Пара слов в конце
Данный продукт - это редкий пример open-source инструмента, который работает не на уровне алертов, а на уровне смыслов.
Он не ловит атаки, не заменяет SOC, не реагирует на инциденты.
При этом он помогает: понять, где вы действительно защищены, какие риски реальны, а где безопасность существует только в отчётах.
🔗 GitHub:
https://github.com/intuitem/ciso-assistant-community
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #CISO #GRC #RiskManagement #CyberSecurity #Infosec #ISO27001 #SecurityManagement #OpenSource
❤1
🛡️ Corgea: AI фиксит уязвимости
Помните, как мы обсуждали VulnHuntr, AI-агента для поиска уязвимостей в коде?
Сегодня поговорим о логичном продолжении этой эволюции: инструменте, который берёт на себя самую нелюбимую часть работы security-инженера по созданию патчей.
Проблема: современные SAST-сканеры генерируют тонны алертов. Зачастую 80% из них false positives. На разбор остаётся 20% реальных проблем, и на каждую у разработчиков уходит в среднем 3-4 часа.
Результат: бэклог растёт, релизы затягиваются, критические уязвимости остаются в production.
Corgea предлагает другой подход.
🔧 Архитектура
Архитектура решения построена вокруг трёх компонентов:
1⃣ Интеграция с существующими инструментами
Corgea подключается к Semgrep, Snyk, CodeQL, Checkmarx, Fortify, берёт их отчёты и начинает работу там, где традиционные сканеры заканчивают.
2⃣ AI-фильтрация false positives
Проприетарные модели анализируют контекст: тип уязвимости, путь кода, data flow, бизнес-логику, сниженая шум на 60-80%. То, что раньше требовало ручного review, теперь отсеивается автоматически.
3⃣ Автоматическая генерация исправлений
Ключевая фича: для подтверждённых уязвимостей Corgea генерирует готовые патчи, конкретный diff, который можно применить одним кликом в VS Code или через GitHub Actions.
🚀 Практическое применение
AI-сканер работает в двух режимах:
➖ CI/CD интеграция: сканирование каждого PR, автоматические комментарии с предложенными фиксами
➖ CLI: локальный запуск для pre-commit проверок
Поддерживаемые языки: Python, Go, JavaScript, TypeScript, Java, C/C++, C#, PHP, Ruby, Kotlin.
Retriever - отдельный open-source инструмент от той же команды решает смежную проблему: безопасный обмен секретами. 100% клиентская сторона, Web Crypto API, никаких серверов.
🔗 Ссылка на GitHub: https://github.com/Corgea
Stay secure and read SecureTechTalks 📚
#corgea #sast #devsecops #ai #cybersecurity #appsec #vulnerabilitymanagement #automatedremediation #llmsecurity #opensource
Помните, как мы обсуждали VulnHuntr, AI-агента для поиска уязвимостей в коде?
Сегодня поговорим о логичном продолжении этой эволюции: инструменте, который берёт на себя самую нелюбимую часть работы security-инженера по созданию патчей.
Проблема: современные SAST-сканеры генерируют тонны алертов. Зачастую 80% из них false positives. На разбор остаётся 20% реальных проблем, и на каждую у разработчиков уходит в среднем 3-4 часа.
Результат: бэклог растёт, релизы затягиваются, критические уязвимости остаются в production.
Corgea предлагает другой подход.
🔧 Архитектура
Архитектура решения построена вокруг трёх компонентов:
1⃣ Интеграция с существующими инструментами
Corgea подключается к Semgrep, Snyk, CodeQL, Checkmarx, Fortify, берёт их отчёты и начинает работу там, где традиционные сканеры заканчивают.
2⃣ AI-фильтрация false positives
Проприетарные модели анализируют контекст: тип уязвимости, путь кода, data flow, бизнес-логику, сниженая шум на 60-80%. То, что раньше требовало ручного review, теперь отсеивается автоматически.
3⃣ Автоматическая генерация исправлений
Ключевая фича: для подтверждённых уязвимостей Corgea генерирует готовые патчи, конкретный diff, который можно применить одним кликом в VS Code или через GitHub Actions.
🚀 Практическое применение
AI-сканер работает в двух режимах:
Поддерживаемые языки: Python, Go, JavaScript, TypeScript, Java, C/C++, C#, PHP, Ruby, Kotlin.
Retriever - отдельный open-source инструмент от той же команды решает смежную проблему: безопасный обмен секретами. 100% клиентская сторона, Web Crypto API, никаких серверов.
🔗 Ссылка на GitHub: https://github.com/Corgea
Stay secure and read SecureTechTalks 📚
#corgea #sast #devsecops #ai #cybersecurity #appsec #vulnerabilitymanagement #automatedremediation #llmsecurity #opensource
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🟢 Uptime Kuma: контроль доступности без лишней боли
Сервисы «падают» всегда неожиданно, но когда вы узнаёте об этом от клиента, то это уже управленческий провал.
🚨 Что за инструмент?
Uptime Kuma - это self-hosted система мониторинга аптайма. По сути, аналог SaaS-решений вроде UptimeRobot или Pingdom, только без передачи данных третьим лицам.
Вы сами разворачиваете инструмент в Docker или на сервере и можете контролировать:
🌐 доступность сайтов
🔐 API-эндпоинты
🖥 TCP/HTTP(S) сервисы
🗄 базы данных
📡 DNS, MQTT, Steam-серверы и многое другое
⚙️ Что умеет Uptime Kuma
🔹 HTTP(S), TCP, Ping, DNS, gRPC, MQTT
🔹 Проверка SSL-сертификатов и срока их действия
🔹 Настраиваемые интервалы проверок
🔹 Статус-страницы для клиентов
🔹 Поддержка 2FA
🔹 Уведомления в Telegram, Slack, Discord, Email и др.
🔹 Работа через Docker, Интерфейс интуитивный.
🔎 Плюсы и ограничения
Плюсы:
➖ Open source
➖ Быстрое развёртывание
➖ Гибкие алерты
➖ Нет передачи чувствительных данных третьим лицам
Ограничения:
➖ Это не SIEM
➖ Нет продвинутой корреляции событий
➖ Требует собственной инфраструктуры
Правда и задача у него другая, быть простым, понятным и надёжным инструментом контроля доступности.
Репозиторий: https://github.com/louislam/uptime-kuma
Stay secure and read SecureTechTalks 📚
#CyberSecurity #UptimeKuma #Monitoring #OpenSource #DevSecOps #BlueTeam #SOC #InfrastructureSecurity #SelfHosted #SecureTechTalks
Сервисы «падают» всегда неожиданно, но когда вы узнаёте об этом от клиента, то это уже управленческий провал.
🚨 Что за инструмент?
Uptime Kuma - это self-hosted система мониторинга аптайма. По сути, аналог SaaS-решений вроде UptimeRobot или Pingdom, только без передачи данных третьим лицам.
Вы сами разворачиваете инструмент в Docker или на сервере и можете контролировать:
🌐 доступность сайтов
🔐 API-эндпоинты
🖥 TCP/HTTP(S) сервисы
🗄 базы данных
📡 DNS, MQTT, Steam-серверы и многое другое
⚙️ Что умеет Uptime Kuma
🔹 HTTP(S), TCP, Ping, DNS, gRPC, MQTT
🔹 Проверка SSL-сертификатов и срока их действия
🔹 Настраиваемые интервалы проверок
🔹 Статус-страницы для клиентов
🔹 Поддержка 2FA
🔹 Уведомления в Telegram, Slack, Discord, Email и др.
🔹 Работа через Docker, Интерфейс интуитивный.
🔎 Плюсы и ограничения
Плюсы:
Ограничения:
Правда и задача у него другая, быть простым, понятным и надёжным инструментом контроля доступности.
Репозиторий: https://github.com/louislam/uptime-kuma
Stay secure and read SecureTechTalks 📚
#CyberSecurity #UptimeKuma #Monitoring #OpenSource #DevSecOps #BlueTeam #SOC #InfrastructureSecurity #SelfHosted #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
💰 OpenSource безопасность получила $12.5 млн
Linux Foundation привлекла $12.5 млн на развитие безопасности open source-проектов. Деньги пойдут на усиление инициатив по защите цепочек поставок, аудит кода и развитие инструментов безопасности.
Звучит как хорошая новость.
Но есть нюанс😁 .
🧠 Open source сегодня это фундамент множества IT-систем.
Но при этом:
🔹 большинство проектов поддерживаются маленькими командами
🔹 аудит проводится нерегулярно
🔹 безопасность часто держится на энтузиазме
В результате уязвимости могут жить годами и масштаб их воздействия огромен.
⚠️ Почему проблема не решается просто деньгами
$12.5 млн это много для отдельной команды, но критически мало для экосистемы из миллионов пакетов.
Проблема не только в финансировании, но и в самой модели. Мы строим критическую инфраструктуру на компонентах,
у которых нет гарантированного уровня безопасности. А новый уровень риска атак на supply chain становится нормой.
Компрометация одного популярного пакета
может автоматически затронуть тысячи компаний.
И чем больше автоматизации (CI/CD, AI-агенты),
тем быстрее распространяется эффект.
🛠 При этом индустрия постепенно смещается к:
✔️ обязательным security-аудитам
✔️ SBOM и прозрачности зависимостей
✔️ верификации пакетов и provenance
✔️ ответственности за open source-компоненты
Но это только начало...
Stay secure and read SecureTechTalks 📚
#кибербезопасность #opensource #supplychain #DevSecOps #SBOM #LinuxFoundation #security #SecureTechTalks #AppSec #информационнаябезопасность
Linux Foundation привлекла $12.5 млн на развитие безопасности open source-проектов. Деньги пойдут на усиление инициатив по защите цепочек поставок, аудит кода и развитие инструментов безопасности.
Звучит как хорошая новость.
🧠 Open source сегодня это фундамент множества IT-систем.
Но при этом:
🔹 большинство проектов поддерживаются маленькими командами
🔹 аудит проводится нерегулярно
🔹 безопасность часто держится на энтузиазме
В результате уязвимости могут жить годами и масштаб их воздействия огромен.
⚠️ Почему проблема не решается просто деньгами
$12.5 млн это много для отдельной команды, но критически мало для экосистемы из миллионов пакетов.
Проблема не только в финансировании, но и в самой модели. Мы строим критическую инфраструктуру на компонентах,
у которых нет гарантированного уровня безопасности. А новый уровень риска атак на supply chain становится нормой.
Компрометация одного популярного пакета
может автоматически затронуть тысячи компаний.
И чем больше автоматизации (CI/CD, AI-агенты),
тем быстрее распространяется эффект.
🛠 При этом индустрия постепенно смещается к:
✔️ обязательным security-аудитам
✔️ SBOM и прозрачности зависимостей
✔️ верификации пакетов и provenance
✔️ ответственности за open source-компоненты
Но это только начало...
Stay secure and read SecureTechTalks 📚
#кибербезопасность #opensource #supplychain #DevSecOps #SBOM #LinuxFoundation #security #SecureTechTalks #AppSec #информационнаябезопасность
👍1
🧰 Контроль выполнения AI-агентов на уровне runtime
Microsoft выпустили Agent Governance Toolkit.
С ростом использования AI-агентов проблема смещается
с качества ответов на контроль выполняемых действий. Если агент вызывает API, инициирует бизнес-операции или управляет инфраструктурой, то он становится полноценным участником системы. Следовательно должен являться объектом контроля.
Agent Governance Toolkit от Microsoft добавляет runtime-уровень управления поведением агентов.
⚙️ Архитектурная роль
Toolkit не участвует в генерации решений.
Он встраивается в execution layer и работает как промежуточный слой:
Agent → Governance Layer → External Systems
Этот слой:
➖ перехватывает действия агента
➖ валидирует их относительно политик
➖ логирует контекст выполнения
🔍 Ключевые компоненты
1⃣ Action Interception
Каждое действие агента (вызов функции, API, tool execution) перехватывается до выполнения.
2⃣ Policy Engine
Правила задаются явно и проверяются в runtime (allow/deny, условные ограничения, контекстные проверки)
3⃣ Execution Trace
Формируется цепочка: context → decision → action → result
Такой подход даёт воспроизводимость и возможность проводить аудит.
4⃣ Observability Hooks
Интеграция с логированием и monitoring-системами
🧠 Чем это отличается от классического IAM
IAM отвечает на вопрос:
“кто имеет доступ?”, агент же может действовать в рамках делегированных прав, однако его поведение не детерминировано.
Контроль смещается к ответу на вопрос “что он делает прямо сейчас?”
Это ближе к runtime security и behavioral analysis.
🕵️ Модель угроз
Toolkit частично закрывает следующие сценарии:
➖ prompt injection → попытка инициировать нежелательные действия
➖ over-privileged agent → избыточные полномочия
➖ unintended tool usage → некорректный выбор инструментов
➖ action chaining → нежелательные последовательности действий
⚠️ Ограничения
➖ политики описываются вручную (нет зрелого DSL/автоматизации)
➖ нет встроенного анализа сложных атак
➖ эффективность зависит от глубины интеграции
🔗 Ссылка: https://github.com/microsoft/agent-governance-toolkit
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #агенты #инфобез #Microsoft #opensource #security #AIagents #devsecops
Microsoft выпустили Agent Governance Toolkit.
С ростом использования AI-агентов проблема смещается
с качества ответов на контроль выполняемых действий. Если агент вызывает API, инициирует бизнес-операции или управляет инфраструктурой, то он становится полноценным участником системы. Следовательно должен являться объектом контроля.
Agent Governance Toolkit от Microsoft добавляет runtime-уровень управления поведением агентов.
⚙️ Архитектурная роль
Toolkit не участвует в генерации решений.
Он встраивается в execution layer и работает как промежуточный слой:
Agent → Governance Layer → External Systems
Этот слой:
🔍 Ключевые компоненты
1⃣ Action Interception
Каждое действие агента (вызов функции, API, tool execution) перехватывается до выполнения.
2⃣ Policy Engine
Правила задаются явно и проверяются в runtime (allow/deny, условные ограничения, контекстные проверки)
3⃣ Execution Trace
Формируется цепочка: context → decision → action → result
Такой подход даёт воспроизводимость и возможность проводить аудит.
4⃣ Observability Hooks
Интеграция с логированием и monitoring-системами
🧠 Чем это отличается от классического IAM
IAM отвечает на вопрос:
“кто имеет доступ?”, агент же может действовать в рамках делегированных прав, однако его поведение не детерминировано.
Контроль смещается к ответу на вопрос “что он делает прямо сейчас?”
Это ближе к runtime security и behavioral analysis.
🕵️ Модель угроз
Toolkit частично закрывает следующие сценарии:
⚠️ Ограничения
🔗 Ссылка: https://github.com/microsoft/agent-governance-toolkit
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #агенты #инфобез #Microsoft #opensource #security #AIagents #devsecops
Please open Telegram to view this post
VIEW IN TELEGRAM
🚨 Claude Code утёк на GitHub и стал вектором атаки
После утечки инструмента Claude Code в открытый доступ на GitHub начали быстро появляться его копии и форки. Некоторые из них оказались модифицированы с добавленным вредоносным кодом.
Выглядело всё вполне обычно: репозиторий с приввчным названием и рабочий код. Пользователи скачивали такие версии как легитимный инструмент, но вместе с этим устанавливали malware.
Вредоносная логика встраивалась прямо в проект и срабатывала при установке или запуске. Она могла догружать дополнительные компоненты, открывать удалённый доступ, перехватывать данные и выполнять команды на машине жертвы.
Атака строится на доверии к инструменту и платформе распространения, но по сути, это стандартная supply chain атака:
➖ точка входа в виде среды разработки,
➖ канал распространения GitHub,
➖ в качестве триггера обычное действие «скачать и попробовать».
Последствия стандартные для такого класса атак. Компрометация рабочих машин, утечка токенов и доступов, риск дальнейшего проникновения в инфраструктуру.
Хорошее напоминание, что доверять нельзя никому 😱
Stay secure and read SecureTechTalks 📚
#кибербезопасность #infosec #cybersecurity #malware #supplychain #github #devsecops #opensource #hacking #securetechtalks
После утечки инструмента Claude Code в открытый доступ на GitHub начали быстро появляться его копии и форки. Некоторые из них оказались модифицированы с добавленным вредоносным кодом.
Выглядело всё вполне обычно: репозиторий с приввчным названием и рабочий код. Пользователи скачивали такие версии как легитимный инструмент, но вместе с этим устанавливали malware.
Вредоносная логика встраивалась прямо в проект и срабатывала при установке или запуске. Она могла догружать дополнительные компоненты, открывать удалённый доступ, перехватывать данные и выполнять команды на машине жертвы.
Атака строится на доверии к инструменту и платформе распространения, но по сути, это стандартная supply chain атака:
Последствия стандартные для такого класса атак. Компрометация рабочих машин, утечка токенов и доступов, риск дальнейшего проникновения в инфраструктуру.
Хорошее напоминание, что доверять нельзя никому 😱
Stay secure and read SecureTechTalks 📚
#кибербезопасность #infosec #cybersecurity #malware #supplychain #github #devsecops #opensource #hacking #securetechtalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🤖 PentAGI: мультиагентная команда пентестеров
PentAGI (Penetration Testing Artificial General Intelligence) - open-source платформа, которая превращает LLM-модели в команду виртуальных специалистов по кибербезопасности. Проект позволяет автоматизировать задачи тестирования на проникновение без необходимости вручную запускать десятки инструментов.
Основные фичи:
🤖 Полная автономность
PentAGI сам определяет шаги тестирования: от разведки и сканирования до эксплуатации уязвимостей и генерации отчётов. AI-агенты планируют атаки, анализируют результаты и адаптируют стратегию на лету.
🏖 Песочница безопасности
Все операции выполняются в изолированных Docker-контейнерах. Даже если агент «сойдёт с ума» будет ущерб ограничен виртуальной средой.
👥 Команда специалистов
Система использует делегирование задач между специализированными агентами:
🔍 Researcher исследует цель и собирает разведданные
💻 Developer пишет эксплойты и скрипты
⚔️ Executor выполняет атаки в изолированной среде
🧠 Adviser контролирует качество и предлагает альтернативные стратегии
20+ профессиональных инструментов. Встроенный арсенал включает nmap, Metasploit, sqlmap и другие инструменты, которые агенты используют как своими руками.
👩🎓 Память и обучение
PentAGI запоминает успешные подходы и накапливает знания через граф знаний на Neo4j (Graphiti). Каждый новый тест система проводит умнее предыдущего.
🧠 Гибкость LLM-провайдеров
Поддерживается 10+ поставщиков моделей: OpenAI, Anthropic, Google Gemini, AWS Bedrock, DeepSeek, GLM, Kimi, Qwen, Ollama (локальный запуск) и даже LiteLLM-прокси. Можно использовать облачные API или развернуть всё локально на своём железе.
🏗️ Архитектура
Система построена на микросервисной архитектуре:
➖ React + TypeScript фронтенд
➖ Go + GraphQL бэкенд с REST API
➖ PostgreSQL + pgvector для векторного поиска
➖ Neo4j для графа знаний
➖ Grafana/Prometheus/Jaeger/Loki для мониторинга
➖ Langfuse для аналитики LLM-операций
Всё это упаковано в Docker Compose и разворачивается одной командой.
🔗 Ссылка на GitHub: vxcontrol/pentagi
PentAGI попытка создать настоящего «цифрового пентестера», который думает, планирует и учится.
Вопрос в том, готовы ли вы доверить ИИ настолько серьёзные задачи?
Да - 👍 Нет - 😱
Stay secure and read SecureTechTalks 📚
#PentAGI #AI #PenetrationTesting #CyberSecurity #AutonomousAgents #RedTeam #OpenSource #SecureTechTalks
PentAGI (Penetration Testing Artificial General Intelligence) - open-source платформа, которая превращает LLM-модели в команду виртуальных специалистов по кибербезопасности. Проект позволяет автоматизировать задачи тестирования на проникновение без необходимости вручную запускать десятки инструментов.
Основные фичи:
🤖 Полная автономность
PentAGI сам определяет шаги тестирования: от разведки и сканирования до эксплуатации уязвимостей и генерации отчётов. AI-агенты планируют атаки, анализируют результаты и адаптируют стратегию на лету.
Все операции выполняются в изолированных Docker-контейнерах. Даже если агент «сойдёт с ума» будет ущерб ограничен виртуальной средой.
Система использует делегирование задач между специализированными агентами:
🔍 Researcher исследует цель и собирает разведданные
💻 Developer пишет эксплойты и скрипты
⚔️ Executor выполняет атаки в изолированной среде
🧠 Adviser контролирует качество и предлагает альтернативные стратегии
20+ профессиональных инструментов. Встроенный арсенал включает nmap, Metasploit, sqlmap и другие инструменты, которые агенты используют как своими руками.
PentAGI запоминает успешные подходы и накапливает знания через граф знаний на Neo4j (Graphiti). Каждый новый тест система проводит умнее предыдущего.
🧠 Гибкость LLM-провайдеров
Поддерживается 10+ поставщиков моделей: OpenAI, Anthropic, Google Gemini, AWS Bedrock, DeepSeek, GLM, Kimi, Qwen, Ollama (локальный запуск) и даже LiteLLM-прокси. Можно использовать облачные API или развернуть всё локально на своём железе.
🏗️ Архитектура
Система построена на микросервисной архитектуре:
Всё это упаковано в Docker Compose и разворачивается одной командой.
🔗 Ссылка на GitHub: vxcontrol/pentagi
PentAGI попытка создать настоящего «цифрового пентестера», который думает, планирует и учится.
Вопрос в том, готовы ли вы доверить ИИ настолько серьёзные задачи?
Да - 👍 Нет - 😱
Stay secure and read SecureTechTalks 📚
#PentAGI #AI #PenetrationTesting #CyberSecurity #AutonomousAgents #RedTeam #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12😱1
🔥 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
🗺 AIMap: инструмент, который показывает, где на самом деле начинается AI-атака
С появлением LLM архитектура перестает быть очевидной.
Раньше можно было нарисовать схему: тут фронт, вот API, здесь база и примерно понять, где проходит граница систем.
В AI-приложениях граница распадается. Один запрос к модели может привести к вызову внешнего инструмента, обращению к API, извлечению данных из хранилища или генерации нового действия.
Зачастую часть связей не фиксируется явно, она возникает на уровне prompt’ов, конфигураций агентов и оркестрации.
В какой-то момент становится трудно ответить на базовый вопрос:
что именно у нас вообще доступно для атаки?
⚙️ AIMap
AIMap проходит по AI-приложению и строит карту взаимодействий, граф, где узлы - это модели, сервисы, инструменты и источники данных, а рёбра - реальные связи между ними.
Инструмент собирает информацию из разных слоёв: описаний агентов, подключённых инструментов, доступных endpoints, путей, по которым данные могут проходить в процессе выполнения.
На выходе получается рабочая модель системы, в которой видно, как она ведёт себя в реальности.
🧪 Разберем инструмент чуть подробнее
AIMap выполняет следующие задачи:
1⃣ обнаруживает компоненты:
- какие LLM используются,
- какие у них интерфейсы,
- какие плагины или инструменты подключены.
2⃣ извлекает информацию о доступных действиях:
- какие функции может вызвать агент,
- к каким API у него есть доступ,
- какие источники данных подключены.
3⃣ строится фактический граф зависимостей. Если модель может вызвать инструмент, который в свою очередь ходит во внешний сервис, это становится частью цепочки. Если пользовательский ввод может повлиять на выбор инструмента, то это тоже фиксируется.
Таким образом формируется execution graph, который отражает возможные пути прохождения запроса через систему.
🧨 Поверхность атаки
Именно на этом графе начинают проявляться вещи, которые сложно увидеть иначе.
Во-первых, становятся видны неочевидные транзитивные связи. Например, модель напрямую не имеет доступа к чувствительным данным, но через цепочку вызовов этот доступ появляется.
Во-вторых, выявляются точки, где пользовательский ввод может влиять на поведение системы. Это потенциальные зоны для prompt injection и управления агентом.
В-третьих, всплывают «забытые» интеграции, инструменты или endpoints, которые формально существуют, но не учитываются в модели угроз.
🔗 GitHub: https://github.com/BishopFox/aimap
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AttackSurface #ThreatModeling #Infosec #CyberSecurity #AIrisks #OpenSource #SecureTechTalks
С появлением LLM архитектура перестает быть очевидной.
Раньше можно было нарисовать схему: тут фронт, вот API, здесь база и примерно понять, где проходит граница систем.
В AI-приложениях граница распадается. Один запрос к модели может привести к вызову внешнего инструмента, обращению к API, извлечению данных из хранилища или генерации нового действия.
Зачастую часть связей не фиксируется явно, она возникает на уровне prompt’ов, конфигураций агентов и оркестрации.
В какой-то момент становится трудно ответить на базовый вопрос:
что именно у нас вообще доступно для атаки?
⚙️ AIMap
AIMap проходит по AI-приложению и строит карту взаимодействий, граф, где узлы - это модели, сервисы, инструменты и источники данных, а рёбра - реальные связи между ними.
Инструмент собирает информацию из разных слоёв: описаний агентов, подключённых инструментов, доступных endpoints, путей, по которым данные могут проходить в процессе выполнения.
На выходе получается рабочая модель системы, в которой видно, как она ведёт себя в реальности.
🧪 Разберем инструмент чуть подробнее
AIMap выполняет следующие задачи:
1⃣ обнаруживает компоненты:
- какие LLM используются,
- какие у них интерфейсы,
- какие плагины или инструменты подключены.
2⃣ извлекает информацию о доступных действиях:
- какие функции может вызвать агент,
- к каким API у него есть доступ,
- какие источники данных подключены.
3⃣ строится фактический граф зависимостей. Если модель может вызвать инструмент, который в свою очередь ходит во внешний сервис, это становится частью цепочки. Если пользовательский ввод может повлиять на выбор инструмента, то это тоже фиксируется.
Таким образом формируется execution graph, который отражает возможные пути прохождения запроса через систему.
🧨 Поверхность атаки
Именно на этом графе начинают проявляться вещи, которые сложно увидеть иначе.
Во-первых, становятся видны неочевидные транзитивные связи. Например, модель напрямую не имеет доступа к чувствительным данным, но через цепочку вызовов этот доступ появляется.
Во-вторых, выявляются точки, где пользовательский ввод может влиять на поведение системы. Это потенциальные зоны для prompt injection и управления агентом.
В-третьих, всплывают «забытые» интеграции, инструменты или endpoints, которые формально существуют, но не учитываются в модели угроз.
🔗 GitHub: https://github.com/BishopFox/aimap
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AttackSurface #ThreatModeling #Infosec #CyberSecurity #AIrisks #OpenSource #SecureTechTalks
👍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
🤖 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