🛡 OSS Rebuild от Google: Проверка на подлог в открытом коде
Google представил решение, которое может радикально изменить подход к безопасности open-source-экосистем. OSS Rebuild — инструмент для автоматической верификации целостности пакетов из PyPI, npm и Crates.io.
💥 В чём суть?
Каждый день тысячи разработчиков устанавливают зависимости из публичных репозиториев — с верой в то, что эти пакеты собраны из «чистого» исходного кода. Но что если в опубликованной версии — вредоносная вставка, которую нет в исходниках?
OSS Rebuild позволяет это выявить. Он пересобирает пакеты из оригинального кода и сравнивает результат с тем, что выложено в реестр. Если совпадают — значит всё чисто. Если нет — возможно, кто-то пытался вас взломать.
🧠 OSS Rebuild использует воспроизводимую сборку: идею, что один и тот же код при тех же условиях должен давать идентичный бинарный результат.
1⃣ Он автоматически анализирует, какие параметры сборки нужны для получения того самого пакета.
2⃣ После успешной пересборки создаётся криптографическая аттестация, которую можно хранить, пересматривать и проверять.
3⃣ Все результаты публикуются в открытом хранилище: ты всегда можешь узнать, проверялась ли нужная тебе версия пакета.
🚨 Что получаем?
🔸 Защита от supply-chain атак
Если злоумышленник получил доступ к учётке мейнтейнера, он может выложить «троянский» билд, не трогая исходники. OSS Rebuild заметит такую подмену.
🔸 Масштабируемость
Инструмент уже проверяет тысячи пакетов автоматически, и это можно встроить в CI/CD или использовать как независимую проверку.
🔸 Прозрачность
Всё, что проверено, снабжается понятным отчётом. Инфраструктура полностью открыта — можно использовать в своих разработках.
🔸 Универсальность
Работает с разными экосистемами: npm (JavaScript), PyPI (Python), Crates.io (Rust). В будущем — больше.
🧩 Есть куда расти
Возможность быстро проверить, действительно ли бинарник сделан из нужного исходника, открывает новые горизонты:
- Сборка «белого списка» доверенных пакетов
- Интеграция с безопасной поставкой ПО (SLSA, SBOM)
- Автоматическая валидация зависимостей при билде
- Верификация уязвимостей: уязвим ли действительно установленный код?
📎 Ссылки:
🔗 GitHub: github.com/google/oss-rebuild
📘 Документация: oss-rebuild.dev
🗞 Блог Google: Introducing OSS Rebuild
Stay secure and read SecureTechTalks 📚
#OSSRebuild #SupplyChainSecurity #OpenSource #GoogleSecurity #PyPI #npm #RustLang #DevSecOps #SLSA #CyberSecurity #SecureTechTalks #ReproducibleBuilds #SoftwareIntegrity #OpenSourceTools #TrustButVerify #SecurityInnovation #CI_CD #SecureDevelopment #SecurityTools #GoogleOpenSource #DigitalDefense
Google представил решение, которое может радикально изменить подход к безопасности open-source-экосистем. OSS Rebuild — инструмент для автоматической верификации целостности пакетов из PyPI, npm и Crates.io.
💥 В чём суть?
Каждый день тысячи разработчиков устанавливают зависимости из публичных репозиториев — с верой в то, что эти пакеты собраны из «чистого» исходного кода. Но что если в опубликованной версии — вредоносная вставка, которую нет в исходниках?
OSS Rebuild позволяет это выявить. Он пересобирает пакеты из оригинального кода и сравнивает результат с тем, что выложено в реестр. Если совпадают — значит всё чисто. Если нет — возможно, кто-то пытался вас взломать.
🧠 OSS Rebuild использует воспроизводимую сборку: идею, что один и тот же код при тех же условиях должен давать идентичный бинарный результат.
1⃣ Он автоматически анализирует, какие параметры сборки нужны для получения того самого пакета.
2⃣ После успешной пересборки создаётся криптографическая аттестация, которую можно хранить, пересматривать и проверять.
3⃣ Все результаты публикуются в открытом хранилище: ты всегда можешь узнать, проверялась ли нужная тебе версия пакета.
🚨 Что получаем?
🔸 Защита от supply-chain атак
Если злоумышленник получил доступ к учётке мейнтейнера, он может выложить «троянский» билд, не трогая исходники. OSS Rebuild заметит такую подмену.
🔸 Масштабируемость
Инструмент уже проверяет тысячи пакетов автоматически, и это можно встроить в CI/CD или использовать как независимую проверку.
🔸 Прозрачность
Всё, что проверено, снабжается понятным отчётом. Инфраструктура полностью открыта — можно использовать в своих разработках.
🔸 Универсальность
Работает с разными экосистемами: npm (JavaScript), PyPI (Python), Crates.io (Rust). В будущем — больше.
🧩 Есть куда расти
Возможность быстро проверить, действительно ли бинарник сделан из нужного исходника, открывает новые горизонты:
- Сборка «белого списка» доверенных пакетов
- Интеграция с безопасной поставкой ПО (SLSA, SBOM)
- Автоматическая валидация зависимостей при билде
- Верификация уязвимостей: уязвим ли действительно установленный код?
📎 Ссылки:
🔗 GitHub: github.com/google/oss-rebuild
📘 Документация: oss-rebuild.dev
🗞 Блог Google: Introducing OSS Rebuild
Stay secure and read SecureTechTalks 📚
#OSSRebuild #SupplyChainSecurity #OpenSource #GoogleSecurity #PyPI #npm #RustLang #DevSecOps #SLSA #CyberSecurity #SecureTechTalks #ReproducibleBuilds #SoftwareIntegrity #OpenSourceTools #TrustButVerify #SecurityInnovation #CI_CD #SecureDevelopment #SecurityTools #GoogleOpenSource #DigitalDefense
🤖 LLM и приватность данных: почему исследования ИИ смотрят не туда
Недавнее исследование от Carnegie Mellon University и Northeastern University показало любопытную (и немного тревожную) картину:
большинство научных работ по приватности в ИИ сосредоточено не там, где реально горит 🔥
🧠 Спойлер:учёные посмотрели на 1 322 публикации за последние 9 лет и поняли - 9 из 10 исследователей копают один и тот же узкий участок,
в то время как поле вокруг уже тлеет по периметру.
📚 Что обнаружили?
📊 92% исследований касаются двух тем:
1️⃣ защиты обучающих данных
2️⃣ утечек истории чатов пользователей
💡 Остальные 8% - это всё, что происходит за пределами лаборатории:
🕵️ инференс-атаки
🔌 утечки через агентные системы
🧩 сбор и корреляция данных между сервисами
🗂️ скрытые профили пользователей
Итог: сотни статей о том, как не дать модели запомнить пароль,
но почти ни одной - о том, куда потом улетает ваш разговор с моделью,
если она встроена в корпоративного помощника 🤷♂️
🧩 Приватность ≠ конфиденциальность
Учёные предлагают новую таксономию утечек:
1️⃣ 🧠 Утечки обучающих данных
2️⃣ 💬 Прямая утечка чатов
3️⃣ 🔗 Косвенные утечки через интеграции и плагины
4️⃣ 🧮 Инференс - когда модель «угадывает» ваши данные
5️⃣ 🧱 Агрегация - сбор публичной информации в личные профили
🔎 Ключевая мысль:
данные утекают не потому, что «хакнули базу»,
а потому, что модель слишком хорошо связывает точки 🕸️
🧱 Иллюзия выбора
Контроль чаще всего иллюзия:
❌ формы обратной связи продолжают храниться
❌ данные остаются «для безопасности» или «комплаенса»
❌ удаление можно отменить внутренним регламентом
Иными словами: галочка «не использовать мои данные» может быть просто декоративной...
⚙️ Новое вызовы - агентные системы
Когда LLM превращаются в агентов, которые ходят в базы данных, CRM, Jira или Slack -
начинается настоящий ад!
🕳️ Пользователь не видит, что именно делает агент:
ищет отчёт... или выгружает фрагменты данных из другой системы?
👁️🗨️ Контроль за агентами - почти «чёрный ящик».
И надеяться, что пользователи сами будут следить за этим, наивно.
💡 Приватность должна быть встроена в дизайн, а не прикручена сверху.
🧠 Что же делать?
🧰 5 правил кибер-гигиены для LLM-систем:
1️⃣ Проверяйте LLM-поставщиков.
🔍 Запрашивайте отчёты: где и как хранятся пользовательские данные.
2️⃣ Минимизируйте сбор данных.
🧹 Чем меньше храните - тем меньше сможете потерять.
3️⃣ Аудитируйте агентов.
🧾 Даже внутренних. Логируйте контексты и действия.
4️⃣ Встраивайте приватность в архитектуру.
🧱 Не плагином, а фундаментом.
5️⃣ Обучайте пользователей.
💬 Разговор с ИИ = API-запрос с контекстом, а не безобидный чат.
➡️ ИИ умеет помнить, обобщать и делать выводы -
а значит, ошибок «по невнимательности» больше не бывает.
🔗 Источник: arxive.org
Stay secure and read SecureTechTalks 📚
#cybersecurity #infosec #LLM #AIprivacy #dataprotection #securedevelopment #cyberthreats #securityawareness #machinelearning #SecureTechTalks
Недавнее исследование от Carnegie Mellon University и Northeastern University показало любопытную (и немного тревожную) картину:
большинство научных работ по приватности в ИИ сосредоточено не там, где реально горит 🔥
🧠 Спойлер:
в то время как поле вокруг уже тлеет по периметру.
📚 Что обнаружили?
📊 92% исследований касаются двух тем:
1️⃣ защиты обучающих данных
2️⃣ утечек истории чатов пользователей
💡 Остальные 8% - это всё, что происходит за пределами лаборатории:
🕵️ инференс-атаки
🔌 утечки через агентные системы
🧩 сбор и корреляция данных между сервисами
🗂️ скрытые профили пользователей
Итог: сотни статей о том, как не дать модели запомнить пароль,
но почти ни одной - о том, куда потом улетает ваш разговор с моделью,
если она встроена в корпоративного помощника 🤷♂️
🧩 Приватность ≠ конфиденциальность
Учёные предлагают новую таксономию утечек:
1️⃣ 🧠 Утечки обучающих данных
2️⃣ 💬 Прямая утечка чатов
3️⃣ 🔗 Косвенные утечки через интеграции и плагины
4️⃣ 🧮 Инференс - когда модель «угадывает» ваши данные
5️⃣ 🧱 Агрегация - сбор публичной информации в личные профили
🔎 Ключевая мысль:
данные утекают не потому, что «хакнули базу»,
а потому, что модель слишком хорошо связывает точки 🕸️
🧱 Иллюзия выбора
Контроль чаще всего иллюзия:
❌ формы обратной связи продолжают храниться
❌ данные остаются «для безопасности» или «комплаенса»
❌ удаление можно отменить внутренним регламентом
🧨 Учёные называют это «эрозией приватности под маской выбора».
Иными словами: галочка «не использовать мои данные» может быть просто декоративной...
⚙️ Новое вызовы - агентные системы
Когда LLM превращаются в агентов, которые ходят в базы данных, CRM, Jira или Slack -
начинается настоящий ад!
🕳️ Пользователь не видит, что именно делает агент:
ищет отчёт... или выгружает фрагменты данных из другой системы?
👁️🗨️ Контроль за агентами - почти «чёрный ящик».
И надеяться, что пользователи сами будут следить за этим, наивно.
💡 Приватность должна быть встроена в дизайн, а не прикручена сверху.
🧠 Что же делать?
🧰 5 правил кибер-гигиены для LLM-систем:
1️⃣ Проверяйте LLM-поставщиков.
🔍 Запрашивайте отчёты: где и как хранятся пользовательские данные.
2️⃣ Минимизируйте сбор данных.
🧹 Чем меньше храните - тем меньше сможете потерять.
3️⃣ Аудитируйте агентов.
🧾 Даже внутренних. Логируйте контексты и действия.
4️⃣ Встраивайте приватность в архитектуру.
🧱 Не плагином, а фундаментом.
5️⃣ Обучайте пользователей.
💬 Разговор с ИИ = API-запрос с контекстом, а не безобидный чат.
➡️ ИИ умеет помнить, обобщать и делать выводы -
а значит, ошибок «по невнимательности» больше не бывает.
🔗 Источник: arxive.org
Stay secure and read SecureTechTalks 📚
#cybersecurity #infosec #LLM #AIprivacy #dataprotection #securedevelopment #cyberthreats #securityawareness #machinelearning #SecureTechTalks
1❤1👍1🔥1🤝1
🤖 Proximity - сканер LLM-интерфейсов
AI всё чаще становится частью корпоративных процессов, но вместе с этим растёт зона риска: MCP-интерфейсы (Model Context Protocol), через которые модели взаимодействуют с данными, API и внешними инструментами.
❗ Проблема: никто точно не знает, какие возможности реально доступны модели.
Решение: Proximity от исследователя Thomas Roccia (aka @fr0gger).
🧩 Что делает Proximity
Proximity - это интеллектуальный сканер MCP-сервисов, который:
📡 находит доступные функции и промпты,
🧠 анализирует ответы с помощью LLM-оценки,
⚙️ выявляет скрытые команды, jailbreak-паттерны и утечки контекста,
🧾 формирует отчёты для CI/CD и DevSecOps-пайплайнов.
📘 Документация:
👉 PulseMCP Directory
🕵️ Реальный кейc
Во время аудита корпоративного MCP-сервера инструмент обнаружил функцию internal_eval,
которая позволяла выполнять системные команды прямо через промпт.
📊 Проблема не была задокументирована и не использовалась напрямую,
но могла быть вызвана в обход стандартного API.
Proximity автоматически сгенерировал отчёт с пометкой:
🔒 Смотрим в будущее
Классические сканеры не видят уязвимости уровня промптов.
Они не умеют анализировать контекст, фильтры и доступные “tools”.
Proximity решает эту задачу, превращая LLM-интерфейс из “чёрного ящика”
в прозрачную, управляемую зону безопасности. Данный продукт не просто сканер,
это инструмент, который показывает, как мыслит ваш ИИ и какие возможности ему доступны за пределами документации.
📎 Ссылка: Proximity GitHub Repository
Stay secure and read SecureTechTalks 📚
#LLMSecurity #CyberSecurity #PromptInjection #AIThreats #DevSecOps #AIResearch #OpenSourceSecurity #PentestTools #MCPScanner #SecureDevelopment #SecureTechTalks
AI всё чаще становится частью корпоративных процессов, но вместе с этим растёт зона риска: MCP-интерфейсы (Model Context Protocol), через которые модели взаимодействуют с данными, API и внешними инструментами.
❗ Проблема: никто точно не знает, какие возможности реально доступны модели.
Решение: Proximity от исследователя Thomas Roccia (aka @fr0gger).
🧩 Что делает Proximity
Proximity - это интеллектуальный сканер MCP-сервисов, который:
📡 находит доступные функции и промпты,
🧠 анализирует ответы с помощью LLM-оценки,
⚙️ выявляет скрытые команды, jailbreak-паттерны и утечки контекста,
🧾 формирует отчёты для CI/CD и DevSecOps-пайплайнов.
📘 Документация:
👉 PulseMCP Directory
🕵️ Реальный кейc
Во время аудита корпоративного MCP-сервера инструмент обнаружил функцию internal_eval,
которая позволяла выполнять системные команды прямо через промпт.
📊 Проблема не была задокументирована и не использовалась напрямую,
но могла быть вызвана в обход стандартного API.
Proximity автоматически сгенерировал отчёт с пометкой:
“Риск эскалации привилегий при определённой структуре промпта.”
🔒 Смотрим в будущее
Классические сканеры не видят уязвимости уровня промптов.
Они не умеют анализировать контекст, фильтры и доступные “tools”.
Proximity решает эту задачу, превращая LLM-интерфейс из “чёрного ящика”
в прозрачную, управляемую зону безопасности. Данный продукт не просто сканер,
это инструмент, который показывает, как мыслит ваш ИИ и какие возможности ему доступны за пределами документации.
📎 Ссылка: Proximity GitHub Repository
Stay secure and read SecureTechTalks 📚
#LLMSecurity #CyberSecurity #PromptInjection #AIThreats #DevSecOps #AIResearch #OpenSourceSecurity #PentestTools #MCPScanner #SecureDevelopment #SecureTechTalks