🔐 Люди сами сливают свои данные в AI, а OpenAI пытается это исправить

Сегодня речь пойдет о проблеме, о которой все знают, но почти никто не решает.

Пользователи массово вставляют персональные данные в диалоги с LLM ( включая креды и номера карт).

На днях OpenAI выпустила инструмент, который работает до того, как данные “утекут” в модель.

🧠 Что за штука?

Речь про Privacy Filter, отдельную модель для поиска и удаления PII (персональных данных) из текста.

В отличие от классических DLP/regex-фильтров, модель не просто ищет шаблоны вроде “@gmail.com” или “+7…”, а анализирует контекст, понимает, где данные публичные, а где приватные, принимает решение прямо в тексте.

Инструмент работает в один проход и поддерживает длинные документы до 128k токенов.

🔍 По каким атрибутам работает поиск?

Модель покрывает основные категории чувствительных данных: имена, адреса, email, телефоны, URL, даты, финансовые реквизиты и секреты вроде паролей или API-ключей.

💡 Локальный запуск

Модель можно запускать локально, т.е. данные не нужно отправлять в облако. Фильтрация происходит прямо на стороне пользователя, что существенно снижает риск утечек.

Постепенно двигаемся сторону privacy-by-design.

⚠️ Пока не идеально

OpenAI заявляет, что модель не идеальна, а риски лежат на пользователях 😁. Фильтр может ошибаться, иногда пропускать редкие или нестандартные персональные данные, а иногда наоборот, скрывать лишнее. В общем все стандартно для решений обезличивания.

📎 Официальный релиз:
https://openai.com/index/introducing-openai-privacy-filter/

🔗 Ссылка на GitHub: https://github.com/openai/privacy-filter

Stay secure and read SecureTechTalks 📚

#CyberSecurity #AI #Privacy #PII #OpenAI #LLM #DataSecurity #Infosec #SecureTechTalks

🔑 Пароли уходят, но мы всё ещё за них держимся

Давно известно, что пароли слабое звено, но люди продолжают их использовать и, если честно, делают это предсказуемо плохо.

Мы переиспользуем пароли, храним их где попало и спокойно вводим их на фишинговых сайтах (даже зная о рисках). Поведение не меняется годами.

🧠 Технология уже есть

На этом фоне passkeys выглядят как очевидное решение. Они убирают саму идею пароля, вместо него используется пара криптографических ключей, где приватная часть остаётся на устройстве, а вход подтверждается через биометрию или PIN.

Получается, что красть нечего, ведь нет пароля, который можно перехватить, слить или переиспользовать. Фишинг в классическом виде тоже перестаёт работать.

Нюанс: люди уже начинают пользоваться passkeys… и не до конца понимают, что это вообще такое. Для многих это просто «ещё один способ входа», а не принципиально новая модель безопасности.

⚙️ Почему тормозит прогресс

С точки зрения безопасности всё выглядит решённым. Однако сервисы внедряют passkeys неравномерно, пользовательский опыт не везде идеален, а компании не спешат ломать привычные сценарии логина. В итоге пароли остаются просто потому, что “мы так привыкли”. Это тот редкий случай, когда инерция сильнее здравого смысла.

💣 Атаки никуда не денутся

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

🔗 Ссылка на исследование NCSC

Stay secure and read SecureTechTalks 📚

#CyberSecurity #Passkeys #FIDO2 #Authentication #NCSC #Infosec #Phishing #IdentitySecurity #SecureTechTalks

🔐 LLM проверили в условиях, приближённых к SOC

Моделям предложили самостоятельно искать атаки.

28 апреля вышел новый бенчмарк от Simbian, один из первых, где языковые модели тестируют не на знание терминов, а на способность работать как аналитик кибербезопасности.

🧪 Как устроен бенчмарк?

Модели поместили в среду, максимально приближенную к реальной. Они анализировали поток событий (Windows Security, Sysmon), внутри которого были спрятаны цепочки атак. Не отдельные техники, а полноценные сценарии.

При этом модели не знали, есть ли атака в данных и сколько их. Фактически от них требовалось провести расследование: выделить слабые сигналы, проверить гипотезы и принять решение в условиях неопределённости.

Именно это отличает новый бенчмарк от всех предыдущих.

📊 Лидер есть, но нет оптимизма

Лучший результат показала Claude Opus 4.6: около 46% обнаруженных атак. При этом доля срабатываний от общего потока событий составила лишь ~4–5%, что подчёркивает слабую чувствительность в реальном шуме.

Модели среднего уровня, включая GPT-4o, демонстрировали нестабильность: они могли корректно выявлять отдельные техники, но регулярно теряли целые цепочки атак.

Наихудшие результаты показали компактные модели вроде GPT-4o mini, порядка 1–2% обнаружения, что практически эквивалентно слепому поиску.

Разница между моделями значительная, но огорчает другое: ни одна из них не достигает уровня, пригодного для реальной автономной защиты.

⚠️ Преждевременное завершение анализа

Особенно любопытно поведение моделей, которое сложно выявить в классических тестах. Часть из них самостоятельно прекращала анализ, решив, что данных уже достаточно для вывода (при этом атаки в логах могли продолжаться).

Когда система не только не сигнализирует о проблеме, но и уверенно сообщает, что всё в порядке, то думаешь на кой она вообще нужна?

🤯 Почему модели не справляются

Атака - это задача с чётким критерием успеха, а защита про поиск неизвестного в потоке шума без гарантии, что сигнал вообще присутствует.

LLM, обученные на задачах с “правильным ответом”, в такой среде теряют устойчивость. Им не хватает ни механизмов самопроверки, ни способности поддерживать длительное расследование.

🔗 Ссылка на бенчмарк

Stay secure and read SecureTechTalks 📚

#кибербезопасность #LLM #SOC #ThreatHunting #AIsecurity #MITREATTACK #BlueTeam #CyberDefense #InfoSec #SecureTechTalks

🧬 Код как отпечаток пальца: уязвимости начинают искать по стилю

Мы воспринимаем уязвимости, как локальный сбой. Где-то не проверили вход, где-то неверно обработали условие, где-то допустили лишний доступ. В такой логике ошибка - это случайность, которую можно найти и исправить.

Однако ошибки почти никогда не бывают случайными. Они воспроизводятся. Причём не потому, что разработчик копирует код, а потому что он воспроизводит собственный способ мышления. У каждого есть устойчивые паттерны, например, как упрощать проверки или как обходиться с исключениями. Эти решения повторяются, а вместе с ними повторяются и уязвимости.

⚙️ Стиль становится сигналом

Code stylometry - подход, который смотрит на код не как на программу, а как на поведение автора. Модель работает на уровне структуры, она анализирует абстрактные синтаксические деревья, последовательности токенов, частоту и комбинации конструкций.

Код превращается в набор признаков, из которых можно восстановить «почерк» разработчика. Этот почерк оказывается достаточно устойчивым, чтобы его можно было распознать и связать с вероятностью ошибок.

Речь идет не о поиске конкретной уязвимости, а склонности к ней.

🧪 От поиска к предсказанию

Модель сначала извлекает стилевые признаки, затем сопоставляет их с обученными зависимостями и на выходе даёт оценку: насколько вероятно, что в этом коде есть уязвимости.

Технически за этим стоят обычные ML-пайплайны, обучение на размеченных данных, где известны уязвимости. 

Впервые объектом анализа становится не сам код, но и стиль его написания как фактор риска.

🧨 Почему это работает?

Причина в том, что разработчик не пишет код «с нуля» каждый раз. Он воспроизводит себя. Одни и те же способы обработки ошибок, одни и те же допущения кочуют из файла в файл. Если в одном месте это привело к уязвимости, в другом вероятность резко возрастает.

Модель, в отличие от человека, не ищет логическое объяснение. Она фиксирует статистическую закономерность.

🕵️‍♂️ Код рассказывает о человеке

Если стиль можно распознать и оценить, значит, можно сравнивать не только фрагменты кода, но и их авторов. Код начинает работать как отпечаток пальца. Через него проявляются привычки, уровень аккуратности, склонность к риску.

В прикладном смысле это означает, что анализ может сместиться. Не от кода к уязвимости, а от разработчика к зонам повышенного риска. В большом проекте это даёт возможность приоритизировать аудит, фокусироваться не на всём сразу, а на том, где вероятность ошибки статистически выше.

🔗 Подробнее с подходом можно ознакомиться в исследовании.

P.S. интересно будет составить список паттернов для каждой LLM.

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #CodeSecurity #VulnerabilityDetection #Infosec #CyberSecurity #StaticAnalysis #AIrisks #SecureTechTalks

🗺 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

🦊 Mozilla подключили Claude к поиску уязвимостей в Firefox.

В Mozilla решили проверить, можно ли использовать Claude как часть реального vulnerability research pipeline для Firefox.


⚙️ Анализ поведения

Firefox активно включились в тестирование Claude Mythos по программе Preview.

Разработчики давали модели широкие задачи: анализировать execution flow, искать подозрительные переходы состояний, изучать edge-case поведение API и проверять, как разные компоненты Firefox взаимодействуют между собой.

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

🧪 Как выглядел workflow

Технически процесс оказался довольно занудным. Исследователь задавал область анализа, например, конкретный subsystem или API. Дальше модель разбирала код, строила reasoning вокруг возможных attack paths и пыталась определить, где нарушение инвариантов или некорректная обработка состояния может привести к security issue.

После этого человек вручную проверял гипотезы и валидировал, существует ли проблема в реальности.

Ключевое отличие от обычного static analysis здесь в том, что Claude не искал заранее известные паттерны уязвимостей.
Модель пыталась анализировать поведение кода на уровне логики:
🔹 как данные проходят через subsystem
🔹 где возникают неожиданные комбинации условий
🔹 какие execution paths выглядят недостаточно защищёнными

🔍 Сильная сторона

Модель не всегда находила уязвимость напрямую, но регулярно выводила исследователей в правильные участки codebase. Особенно хорошо это работало в сценариях, где проблема возникала не из-за одной ошибки, а из-за сложного взаимодействия нескольких компонентов или редких edge-case состояний.

🧨 А потом пришли галлюцинации

Ограничения проявились почти сразу. Claude довольно легко терял архитектурный контекст в больших subsystem’ах Firefox, иногда придумывал execution paths, которых не существовало, и регулярно «галлюцинировал» свойства API.

В некоторых случаях модель строила убедительное reasoning вокруг сценариев, которые технически были невозможны из-за ограничений runtime или внутренней логики браузера.
В таком контексте автономный AI bug hunting пока крайне рискованная идея.

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #Firefox #Claude #BugBounty #AppSec #VulnerabilityResearch #Infosec #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

🎭 Deepfake-детекторы начинают проигрывать.

Большинство систем deepfake detection работают, как поиск статистических аномалий. Модели анализируют:
🔹 микродвижения лица
🔹 артефакты compression
🔹 inconsistencies в освещении
🔹 частотные особенности изображения
🔹 temporal anomalies между кадрами

Другими словами, detector пытается найти признаки того, что контент был синтетически сгенерирован.
Однако современные генеративные модели начинают производить данные, статистически близкие к реальным.

⚙️ Гонка вооружений

Deepfake-generation и deepfake-detection давно превратились в adversarial cycle. Детектор учится находить паттерн, а
генератор учится этот паттерн скрывать. С каждой новой итерацией качество синтетического контента становится выше, а количество detectable artifacts уменьшается.

Исследователи отдельно отмечают: многие современные detector’ы начинают резко терять accuracy на новых generation-моделях, для которых они изначально не обучались.

Особенно плохо системы работают при:
🔹 повторном сжатии видео
🔹 изменении resolution
🔹 post-processing
🔹 screen recording
🔹 смешанных pipeline генерации

Иногда достаточно обычного TikTok-style re-encoding, чтобы detection quality заметно деградировал.

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

Детекторы всё сильнее зависят от конкретных особенностей pipeline, система часто учится распознавать не «фейк», а следы конкретной модели или конкретного способа генерации. Как только pipeline меняется, detection начинает рассыпаться.

🧨 Индустрия теряет точку опоры

Похоже, deepfake detection постепенно смещается из категории «технически решаемой задачи» в область вероятностного анализа, где речь идёт уже не о точном определении фейка, а об оценке уровня доверия к контенту.

🔗 Статья: https://arxiv.org/pdf/2605.09007

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #Deepfake #LLM #CyberSecurity #FraudDetection #SocialEngineering #Infosec #AIrisks #SecureTechTalks

📏💣 LLM можно взломать просто продолжая диалог

В мае вышла работа MetaBackdoor, где исследователи из Microsoft и Institute of Science Tokyo описывают новый тип backdoor-атак на LLM.
Главная идея исследования использовать в качестве trigger не содержимое prompt, а позицию токенов в контексте.

достиг определённой позиции в sequence → переключил поведение модели

Авторы называют это meta-trigger, потому что он связан не с текстом, а с метасвойствами последовательности.

Например:
📚 контекст превысил определённую длину
📍 токены оказались в нужном positional range
🔢 sequence crossed threshold

Trigger может возникать естественным образом, без участия атакующего.

💬 пользователь просто общается с AI
🧠 память агента накапливается
📈 context window становится длиннее
И в какой-то момент backdoor активируется сам.

🧬 Особенности моделей

Технически атака использует фундаментальную особенность Transformer-архитектуры, positional encoding. Для модели все токены это просто embedding-вектора.

Без механизма позиции фразы для модели были бы почти одинаковыми. Представьте перепутать «root granted admin» и «admin granted root».

Поэтому модели используют positional embeddings. В современных моделях чаще всего это:
🔹 RoPE (Rotary Positional Embedding)
🔹 ALiBi
🔹 Absolute positional encodings

В исследовании авторы показывают, что именно позиционная чувствительность модели может использоваться как скрытый канал управления поведением.

Во время fine-tuning в модель внедряется backdoor objective: если токен находится после определённой позиции → изменить response policy

Trigger не обязан быть точным числом. Бэкдор может срабатывать в диапазоне позиций, например после N тысяч токенов, что делает его значительно более устойчивым к случайным изменениям prompt.
Это особенно важно для production-agent systems, где длина контекста постоянно плавает.

🎭 Что можно сделать после активации

Авторы тестировали разные payload-сценарии.
Среди них:

🧾 System prompt leakage: модель начинает раскрывать скрытые инструкции.

🛠️ Tool misuse: агент начинает выполнять неожиданные tool calls.

📤 Context leakage: утечка памяти и истории общения.

🧠 Policy switching: изменение alignment и response behavior.

Похоже, эпоха «проверим prompt и успокоимся» начинает заканчиваться 👀

📄 MetaBackdoor: Exploiting Positional Encoding as a Backdoor Attack Surface in LLMs

Stay secure and read SecureTechTalks 📚

#CyberSecurity #AI #LLMSecurity #AISecurity #PromptInjection #GenAI #MachineLearning #ThreatModeling #AIAgents #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

Сейчас идёт обновление OWASP Top 10 for LLM Applications, и в сообществе предложили несколько новых кандидатов для добавления и замены пунктов, потерявших актуальность. Наиболее интересными показались четыре проблемы:

Inference-Time Side-Channel Disclosure — атаки на инфраструктуру инференса, при которых наблюдатель за шифрованным сетевым трафиком может с высокой точностью угадывать тематику запросов. Смотрите статью от Microsoft Whisper Leak.

Уязвимости MCP tools: скрытые вредоносные инструкции в description инструмента, tool squatting, rug pull, когда сервер меняет поведение через какое-то время после авторизации. К слову, в OWASP есть аж два документа, где детально расписаны проблемы MCP: Cheat Sheet и Guide for Using Third-Party MCP.

Persistent Memory Poisoning — можно сказать, это замена старому LLM04 (Data and Model Poisoning) про отравления датасетов обучения. За последние пару лет мы не видим кейсов таких отравлений (это не значит, что их нет, конечно), но видим много атак в runtime на межсессионную память. EchoLeak, SpAIware, кейс с Gemini есть в ссылках к этому кандидату.

И Model Misalignment, который заслуживает внимания с развитием reasoning моделей и их широкими возможностями. Пункт о том, что поведение модели расходится с исходной задачей пользователя. Сюда относятся работы про alignment faking, sleeper agents и тп. Текущее описание кандидата требует доработки и даже есть кандидат-дубликат Model Scheming and Deceptive Alignment, но, надеюсь, он всё равно войдёт в итоговый апдейт.

Кстати, до конца дня 18 мая вы можете тоже поддержать выбор новых кандидатов и помочь рабочей группе OWASP оценить, какие из старых пунктов можно исключить, если проголосуете в форме. После голосования из 10 новых кандидатов останется половина, и итоговый выбор Top 10 будет сформирован в июне.

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