💰 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 #информационнаябезопасность

🗺 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

🌊 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

🤖 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

🤖 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

⚙️ Не 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

🚨 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

🧨 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

🚀 Какие классы 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

📌 Уязвимость не всегда живёт в одном файле

Когда мы ищем баги в коде, самые опасные цепочки часто размазаны по десяткам файлов. Данные приходят через 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

🧨 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

🧨 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

🧨 Google учит AI работать с зашифрованными данными

Fully Homomorphic Encryption (FHE) сохраняет данные зашифрованными даже во время вычислений.

Мы уже рассказывали про проблемы гомоморфного шифрования и федеративного обучения. Однако Google не стоит на месте и продолжает развивать технологию в виде открытого проекта HEIR, который должен упростить создание  приложений.

⚙️ Суть проекта

Разработчик описывает обычную программу. HEIR автоматически преобразует её так, чтобы вычисления выполнялись непосредственно над зашифрованными данными.

Получается цепочка:
данные → шифрование → AI или другая обработка → зашифрованный результат → расшифровка

Сервер работает с зашифрованной информацией и не получает исходные данные.

🧠 Зачем здесь AI

Такой подход особенно интересен для систем, где данные слишком чувствительны для передачи внешнему AI сервису.
Например:
🔹 банк отправляет транзакцию на анализ мошенничества, не раскрывая её содержимое;
🔹 SOC анализирует сетевые события, сохраняя данные клиентов зашифрованными;
🔹 медицинская система использует AI для анализа данных пациента без передачи модели открытой медицинской информации.

HEIR поддерживает несколько современных методов гомоморфного шифрования и умеет автоматически оптимизировать вычисления.

🔥 Главная проблема

Само шифрование уже существует. Главный барьер сейчас в том, что такие вычисления дорогие и сложные для разработчиков.

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

Когда этот подход станет достаточно быстрым, появится интересная архитектура для корпоративного AI.
Модель получает данные, но инфраструктура вокруг неё не получает доступа к исходной информации.

🔗 GitHub: https://github.com/google/heir

🔗 Документация: https://heir.dev/

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #FHE #Privacy #Cryptography #Google #OpenSource #AISecurity #DataSecurity #SecureTechTalks