LLM-приложение может выглядеть рабочим, но оставаться небезопасным: prompt injection, утечки чувствительных данных, supply chain-риски и poisoning-атаки не исчезают только потому, что вы добавили RAG, fine-tuning или аккуратный системный промпт.
7 июля в 20:00 МСК на открытом вебинаре OTUS разберём OWASP Top 10 for LLM Applications как практическую карту угроз для AI-проектов. Поговорим, какие риски входят в актуальный список, как они проявляются в реальных LLM-системах и почему запуск AI-решений без специальных защитных мер может быстро привести к проблемам в продакшене.
Покажем, как проводить threat modeling LLM-приложения с опорой на OWASP-фреймворк: где искать слабые места в архитектуре, какие вопросы задавать до вывода решения в продакшен и почему стандартные архитектурные подходы не заменяют полноценную защиту.
Урок проходит в преддверии старта курса «Безопасность ИИ / MLSecOps». Регистрируйтесь, чтобы разобраться в ключевых угрозах LLM-приложений и понять, как проверять AI-системы на слабые места ещё до продакшена.
👉Регистрируйтесь: https://vk.cc/cZb3jU
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
⚡️ Почему обычный `min(a, b)` в C может вернуть неожиданный результат
В C есть неприятная ловушка: если сравнивать signed и unsigned значения, компилятор может привести оба числа к unsigned.
И тогда отрицательное число внезапно превращается в огромное положительное.
Пример:
#define min(a, b) ((a) < (b) ? (a) : (b))
int x = -1;
unsigned int y = 10;
printf("%u\n", min(x, y));
Интуитивно кажется, что минимум — -1.
Но при сравнении x < y значение -1 приводится к unsigned и становится очень большим числом. В итоге сравнение работает уже не так, как ожидает разработчик.
Именно поэтому в Linux kernel макрос min() устроен хитрее. Он не просто сравнивает два значения, а сначала делает type check:
Она заставляет компилятор проверить, что типы совместимы. Если один аргумент signed, а другой unsigned, такой код может превратиться в ошибку компиляции, а не в тихий баг в рантайме.
Это хороший пример системного C-подхода: лучше сломать сборку сразу, чем получить «правильный» код, который иногда считает неправильно.
В низкоуровневом коде такие мелочи решают очень много. Один неудачный implicit conversion — и проверка размера, индекса или лимита начинает работать против вас.