Оценка инструментов безопасности с использованием ИИ
ИИ-системы становятся сложнее и автономнее, поэтому командам безопасности важно понимать, какие агенты используются в компании, с какими инструментами и моделями они работают и как взаимодействуют между собой.
Эффективная защита требует целостной платформы безопасности ИИ, которая объединяет прозрачность, обеспечение соблюдения политик и защиту от угроз во всей агентной экосистеме.
В новом руководстве разбираем пятиэтапную модель безопасности ИИ:
▶️Обнаружение – как получать полную видимость моделей, агентов и данных
▶️ Оценка – как анализировать риски и выявлять уязвимости
▶️ Защита – как контролировать действия ИИ-систем и предотвращать атаки
▶️ Управление – как выстраивать политики, контроль и соответствие требованиям
▶️Измерение – как проверять эффективность защитных механизмов и отслеживать изменения поведения ИИ.
Материал будет полезен директорам по информационной безопасности и командам, которые занимаются внедрением и контролем ИИ-инструментов в компании.
Именно с такой фразы сегодня могут начинаться атаки на ИИ-системы.
Prompt Injection — это атака, при которой злоумышленник внедряет инструкции в пользовательский ввод, email, документ или другой контент так, что LLM начинает игнорировать исходные правила (system prompt/политики безопасности) и выполнять действия, задуманные атакующим: раскрывать конфиденциальные данные, обходить ограничения или генерировать команды для внешних систем.
В OWASP эта проблема входит в список ключевых рисков для GenAI как LLM01:2025 Prompt Injection. Особенно опасны такие атаки для ИИ-агентов, Copilot-систем и RAG-приложений, у которых есть доступ к корпоративным данным и внешним API.
Инъекция может быть прямая, когда инструкция приходит прямо от атакующего, или непрямая, когда инструкция спрятана во внешнем контенте.
Как работает
Пользователь вводит последовательность: «игнорируй прежние инструкции, теперь ты …; выполни …».
Модель переопределяет приоритеты и выдаёт запрещённый контент или «готовые» команды/URL/SQL.
Если есть агент/инструменты, неподтверждённые команды трактуются как действия → утечки/доступ к внутренним ресурсам.
Представьте ИИ-ассистента, который работает с корпоративной почтой и документами. Атакующий может отправить email или разместить файл со скрытыми инструкциями, и когда агент начнет его обрабатывать, модель станет выполнять команды злоумышленника. Обнаружить такие атаки крайне сложно. Даже если вредоносных документов в базе меньше 1%, этого уже может быть достаточно, чтобы нарушить поведение агента. Для злоумышленников подобные неординарные данные становятся “серебряной пулей”, потому что показывают сверхвысокую эффективность. — поделился Михаил Черешнев, ведущий инженер по ИИ и безопасности ГК Swordfish Security.
✅ После ответа модели: не трактовать вывод LLM как команды без валидации, использовать типизированные схемы аргументов, allow-list доменов и операций, HITL для чувствительных действий.
✅ Использовать sandbox и egress-фильтры для tools, вводить квоты, тайм-ауты и бюджеты, применять DLP для ответов, логов и кэшей.
Агентный ИИ: как внедрять автономные цифровые системы безопасно
В ближайшие годы агентные системы будут формировать основу корпоративной автоматизации. И компании, которые сегодня правильно выстраивают фундамент безопасности, смогут внедрять автономные технологии быстрее и гораздо увереннее.
В новом руководстве разбираем:
🎱как меняются цифровые системы с приходом агентного ИИ,
🎱какие уязвимости возникают в цепочках действий и логике принятия решений,
🎱как выстроить безопасную архитектуру для агентных систем,
🎱как компании сейчас проходят путь внедрения агентного ИИ.
Технический долг – это накопленные упрощения, устаревшие решения и несвоевременно устраненные проблемы в ИТ-системах. Это могут быть старые библиотеки, забытые сервисы и другие элементы, которые когда то были временными, но остались в продакшене.
В контексте SAST/DAST/SCA техдолг – это разница между тем, что инструмент нашел, и тем, что AppSec-инженер разобрал, а разработчик исправил. Из-за большого количества срабатываний аппсеки могут потерять реальные уязвимости.
Со временем такой долг делает инфраструктуру и уязвимости в коде сложнее для контроля, замедляет реагирование на инциденты и нахождение в коде уязвимостей, которые можно исправить заранее, а также повышает вероятность того, что проблема возникнет там, где её никто не ожидал.
Как рассчитывается
Технический долг рассчитывается как сумма затрат (времени разработчиков, денег) на исправление дефектов. Он включает оценку сложности рефакторинга, устранения багов, обновления библиотек и архитектурных улучшений.
Почему нужно разбирать технический долг вовремя?
Спросили у инженера по информационной безопасности Swordfish Security Дениса Данилова, который помогает заказчикам разбирать технический долг в реальных проектах:
Очень часто после внедрения инструмента и первого сканирования проекта находится очень много срабатываний, на которые команда не может выделить время. Даже если аппсек разобрал все уязвимости и принёс только актуальные, разработчики сопротивляются и не хотят тратить на это время. В итоге уязвимости накапливаются и одна из них обязательно выливается в инцидент, который разработчики вынуждены чинить уже не планово, а с горящими сроками. Если же каждый спринт разбирать и исправлять хотя бы по одну уязвимость, внедрив это в процесс, разработчики не только сократят существующий техдолг, но и со временем придут к тому, что его появление значительно уменьшится. А появление нового техдолга будет ограничено механизмом Quality Gate.
💡 Советы эксперта:
Регулярно обновляйте зависимости и убирайте устаревшие компоненты.
Контролируйте и закрывайте временные доступы после использования.
Проводите инвентаризацию сервисов и API.
Рассматривайте технический долг как часть модели угроз.
Сегодня поговорим про статический анализ кода (SAST) — одну из самых важных практик анализа безопасности приложений, которая помогает находить уязвимости на ранних этапах разработки.
▶️ Основные проблемы, которые беспокоят разработчиков:
долгие сканирования на крупных кодовых базах;
большое количество ложных срабатываний (False Positive);
недостаточное покрытие технического стека правилами (False Negative).
▶️ Как решать:
выбирайте инструменты, которые отвечают требованиям вашей компании и отрасли;
разработайте набор правил под конкретный проект;
редактируйте встроенные правила в продукте;
для оптимизации времени сканирования проводите быстрые проверки в каждом коммите или мердж реквесте, а долгие уже перед релизом или по расписанию.
▶️ Что лучше выбрать: коммерческий или некоммерческий SAST- сканер?
При выборе инструментов важно учитывать, что коммерческие решения, как правило, предлагают более широкое покрытие языков и технологий, регулярные обновления и глубокий анализ потоков данных. Однако они могут быть требовательны к ресурсам и ограничивать возможности кастомизации.
Некоммерческие решения, напротив, дают больше гибкости за счёт открытого кода и часто работают быстрее, но могут уступать в функциональности, полноте анализа и качестве документации, особенно в сложных сценариях.
Обычно, чтобы определиться с выбором SAST-инструмента, команды проводят пилот: сравнивают решения по функциональности и качеству детекта. Максимальный эффект от решения достигается тогда, когда выстроен процесс тестирования с настройкой правил, метриками и понятными критериями эффективности.
XXE (XML eXternal Entity injection) — это уязвимость, которая позволяет злоумышленнику вмешиваться в процесс обработки XML-данных приложением.
Язык разметки XML (eXtensible Markup Language) — это такой тип документа, в котором вся информация представлена в виде тегов. Для описания структуры документа часто используется DTD (Document Type Definition), который, помимо прочего, позволяет подключать внешние ресурсы.
Чем опасна XXE:
Позволяет читать локальные файлы на сервере (например, /etc/passwd);
Может привести к отказу в обслуживании (например, через атаку «Billion Laughs»);
В некоторых случаях открывает путь к удаленному выполнению кода;
Используется для обхода ограничений и получения чувствительных данных.
В этом видео Анна Данилова (Калугина), инженер по безопасности приложений Swordfish Security, подробно объясняет, как работает XXE-уязвимость. Эксперт разбирает принцип работы XML и DTD, демонстрирует реальный пример эксплуатации через подмену запроса и рассказывает, как предотвратить появление уязвимости.
Перенаправления — это механизм, с помощью которого сервер указывает клиенту (например, веб-браузеру) необходимость перейти на другой URL. Они являются стандартной частью протокола HTTP и используются для управления трафиком между веб-сайтами.
Чем опасно открытое перенаправление:
Позволяет проводить фишинговые атаки;
Используется для эксплуатации уязвимостей браузеров и плагинов;
Способствует распространению вредоносного контента и дезинформации.
➡️ В этом видео Денис Данилов, инженер по безопасности приложений Swordfish Security, рассказывает, как защититься от этой уязвимости. Эксперт объясняет, какие подходы использовать на сервере, чтобы исключить риск, а также показывает реальный пример эксплуатации, когда злоумышленник может обмануть пользователя, даже если сайт выглядит безопасным.
В этом видео инженер по безопасности приложений Swordfish Security Оксана Сурвилло рассказала, какие данные можно и нельзя хранить в куки и как защитить их с помощью флагов Secure, HttpOnly, Domain, Path и SameSite.
Куки — это текстовые файлы, хранящиеся на устройствах пользователей. Они содержат небольшие фрагменты данных, например, идентификатор сессии. С их помощью сайты запоминают информацию о пользователях.
Сегодня украденные куки зачастую дают больше возможностей для хакеров, чем логин и пароль. Например, компрометация сессионного куки позволяет злоумышленнику войти в почту, CRM и облачные хранилища без пароля и дополнительной верификации.
🔒 При неправильной настройке куки также могут стать объектом атак злоумышленников, поэтому важно обеспечить их безопасность.
🔼Также в видео эксперт показывает реальный сценарий эксплуатации уязвимости в куки, в результате которой злоумышленник может получить доступ к аккаунту администратора сайта.
Разработали фреймворк для оценки зрелости безопасности ИИ-систем
Сегодня безопасность систем ИИ становится ключевым фактором, определяющим уровень доверия к ним. Для того чтобы организация смогла справиться с этими вызовами, ей необходимо, в первую очередь, определить текущий уровень зрелости и оценить свои слабые и сильные стороны.
Команда Swordfish Security разработала Swordfish: Secure AI Maturity Model (SAIMM) —фреймворк, который помогает компаниям системно выстраивать безопасность ИИ-решений и снижать риски на всех этапах жизненного цикла разработки.
Мы обобщили опыт внедрения ИИ-систем в корпоративной среде, результаты работы с заказчиками из разных отраслей и текущие международные практики безопасности — от OWASP и NIST до MITRE ATLAS. На основе этого сформирована модель зрелости, охватывающая ключевые аспекты безопасности современных ML- и LLM-систем, включая агентные сценарии.
SAIMM построен на основе пяти базовых доменов в области безопасности ИИ и одного специализированного в области агентных систем. Для каждого домена предусмотрена дорожная карта с действиями, артефактами и техническими мерами.
Домены SAIMM:
1️⃣ Управление и риск-менеджмент Политики, роли, риск-аппетит, процедуры аудита, внутренние стандарты и этические принципы.
2️⃣ Защита данных и конфиденциальность Качество, происхождение, доступы, ПДн и локализация. Надежное обучение моделей и эксплуатация ИИ.
3️⃣ Безопасность модели Устойчивость моделей к атакам любого рода и защита артефактов модели от несанкционированного доступа.
4️⃣ Безопасность цепочек поставок Встроенная безопасность в конвейер разработки ПО. Контроль состава и безопасности всех внешних компонентов: модели, библиотеки, датасеты.
5️⃣ Инфраструктура и операционная безопасность Надежное функционирование системы, устойчивость к сбоям, дрейфу и атакам. Организация реагирования на инциденты.
6️⃣ Безопасность агентных систем Контроль автономного поведения агентов для предотвращения нежелательных действий и рисков.
SAIMM выступает практической картой зрелости безопасности ИИ, позволяющей не просто измерять готовность, но и выстраивать стратегию безопасного внедрения и масштабирования искусственного интеллекта в корпоративной среде.
В этом видео инженер по безопасности приложений Swordfish Security Денис Данилов разбирает уязвимость стандарта передачи данных JSON Web Token (JWT).
Суть уязвимости
JWT состоит из трех частей:
Header — заголовок, где указывается алгоритм подписи (например, HS256),
Payload — полезная нагрузка (данные пользователя, роли и т. д.),
Signature — подпись, которая формируется с помощью секретного ключа.
Проблема возникает, если сервер не проверяет, какой алгоритм указан в заголовке. Если там стоит alg: "None", библиотека может интерпретировать это буквально — и не проверять подпись вовсе.
В результате злоумышленник может:
извлечь JWT токен (например, из cookies),
заменить полезную нагрузку (например, указать "role": "admin"),
подставить alg: "None" в заголовке,
отправить подделанный токен на сервер и получить доступ к чужому аккаунту.
Как научиться находить такие уязвимости?
Такой тип ошибки — не уникален для JWT. Это общий паттерн: разработчик полагается на библиотеку, не разбираясь в деталях. В продакшене такие недочёты дорого обходятся — и бизнесу, и карьере инженера.
Swordfish Security мы регулярно сталкиваемся с подобными уязвимостями в реальных проектах. Опыт показывает: даже базовое понимание архитектуры протоколов и моделей угроз помогает разработчикам предотвращать критичные ошибки ещё на этапе проектирования. Этот кейс, кстати, — часть одного из модулей курса по DevSecOps нашей академии, где мы разбираем типовые уязвимости и подходы к их предотвращению.
