SecureTechTalks
303 subscribers
805 photos
1 video
1 file
803 links
Добро пожаловать на канал "SecureTechTalks"! Мы предлагаем вам увлекательное и информативное погружение в мир кибербезопасности. Здесь вы найдете актуальные новости, советы, методы и инсайты по инфобезу.
Download Telegram
🧰 Контроль выполнения 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
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
Please open Telegram to view this post
VIEW IN TELEGRAM
🧪 Продолжаем тестирования AI: взгляд на ASQAV SDK

В какой-то момент стало очевидно: привычные методы тестирования плохо применимы к AI-системам.

Раньше можно было сопоставить вход и ожидаемый результат. Теперь с LLM всё иначе.
Ответы вариативны, поведение зависит от контекста, а в случае агентных систем ещё и от цепочки решений, которая формируется прямо в процессе выполнения.

Не удивительно, что появляется все больше специализированных инструментов. Сегодня разберем еще один из них - ASQAV SDK.

⚙️ Изучаем поведение

ASQAV - open-source SDK для оценки и тестирования AI-приложений. Инструмент прежде всего пригодится там, где используются:

языковые модели
агенты
интеграции с внешними сервисами и данными

Его ключевая особенность в смещение фокуса. Он проверяет не «правильность ответа», а устойчивость системы. То есть, как она реагирует на некорректные, провокационные или откровенно вредоносные входные данные.

🔍 Подход ASQAV

Инструмент позволяет задавать сценарии, которые можно назвать «стрессовыми» для модели:

попытки prompt injection
обход ограничений (jailbreak)
провокации на утечку данных
некорректные или неоднозначные входные данные

Система проходит через сценарии последовательно, а результаты можно воспроизводить и встраивать в CI/CD.

Это приближает тестирование AI к тому, что в классической безопасности называется adversarial-подходом.

⚠️ Важное уточнение

ASQAV не определяет, что считать критичным,
не строит модель угроз и не заменяет архитектурные решения.

Инструмент позволяет регулярно проверять систему на устойчивость, а не полагаться на интуицию.

То есть, без классических инструментов все-таки не обойтись.

🧩 Немного по техничке

ASQAV строится вокруг идеи сценарного тестирования. Разработчик описывает набор кейсов (prompts, контекст, ожидаемые ограничения), после чего SDK прогоняет их через модель и фиксирует отклонения.

Тесты можно параметризовать, комбинировать и запускать пакетно. Этакие unit/integration-тесты для LLM-поведения. Результаты структурируются (оценки, флаги нарушений, логи ответов), что позволяет интегрировать проверки в пайплайны CI/CD и отслеживать деградацию модели со временем.

Инструмент работает на уровне API-взаимодействия с моделью, поэтому легко встраивается в существующую архитектуру без изменения самой LLM.

🔗 Репозиторий:

https://github.com/jagmarques/asqav-sdk

Stay secure and read SecureTechTalks 📚

#кибербезопасность #информационнаябезопасность #AIsecurity #LLM #AgenticAI #PromptInjection #AdversarialTesting #MachineLearning #DevSecOps #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🚨 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
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 больше не «подсказка», а фактически команда;
агент сам ходит по репозиторию и что-то там меняет (поди разберись что);
ошибки не останавливают процесс, а просто запускают новую попытку

💬 Что с этим делать

Игнорировать не получится.
Если такие системы начинают жить в проде,
придётся защищать не только код, но и саму формулировку задач.
Потому что именно там теперь начинается выполнение.

безопасность 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
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
👍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
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
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
1👍1