Оценка по OWASP LLM Top 10: методика, охват и выбор подрядчика на основе доказательств

Что охватывает оценка по OWASP LLM Top 10

Оценка по OWASP LLM Top 10 — это санкционированный анализ безопасности приложения со встроенной большой языковой моделью, построенный вокруг списка рисков OWASP для LLM-приложений. Тех, кто ищет такую услугу, обычно интересуют три практических вопроса. Что именно будет проверено? Как результаты будут доказаны, а не просто заявлены? Как сравнивать подрядчиков, предлагающих оценку безопасности LLM или тестирование на проникновение LLM-приложений? Руководство отвечает на эти вопросы с опорой на открытые проверяемые источники: OWASP Top 10, OWASP Web Security Testing Guide (WSTG), OWASP Application Security Verification Standard (ASVS), NIST SP 800-115, NIST Cybersecurity Framework 2.0, CISA Secure by Design, MITRE CWE Top 25 и документацию MDN по HTTP.

Одно ограничение нужно обозначить сразу. Доказательная база статьи не воспроизводит текст списка OWASP, посвящённого LLM, поэтому мы не пересказываем его категории и нумерацию. Вместо этого рекомендуем, чтобы каждая оценка указывала точную версию используемого списка и привязывала к ней каждую находку. Проект ASVS предупреждает, что идентификаторы требований могут меняться между версиями, и рекомендует ссылки с префиксом версии. Та же дисциплина сохраняет однозначность оценки LLM при пересмотре списка.

На практике LLM-приложение редко сводится к одной модели. Это веб- или API-продукт с HTTP-эндпоинтами, аутентификацией, управлением сессиями, интерфейсом, отображающим ответы модели, и коннекторами к хранилищам данных и инструментам. Оценка, которая проверяет только диалоговое поведение и игнорирует окружающее приложение, оставляет значительную часть реальной поверхности атаки без внимания.

• Интерфейсы модели: промпты, системные инструкции и любой конвейер извлечения или формирования контекста
• Прикладной уровень: HTTP API, аутентификация, сессии, разграничение доступа между пользователями и арендаторами
• Пути вывода: отображение в браузере, нижестоящие сервисы, базы данных и вызовы ОС, получающие вывод модели
• Интеграции: инструменты, плагины и коннекторы, которые может вызывать модель, и данные, к которым они имеют доступ
• Эксплуатация: журналирование, мониторинг, управление изменениями промптов, моделей и коннекторов

По темеЗащита SCADA-систем: угрозы, безопасная оценка защищенности и выбор подрядчика

Методика исследования и доказательная база

Анализ опирается на восемь открытых источников, и каждый используется только в пределах того, что в нём действительно сказано. Числовые значения — количество участников, версии релизов, объём наборов данных — взяты со страниц проектов в опубликованном виде. Они показывают зрелость и масштаб справочных материалов. Это не измерения риска LLM, и читать их так не следует.

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

Стандарты безопасности веб-приложений привлекаются потому, что LLM-приложения работают поверх веб-протоколов. MDN описывает HTTP как клиент-серверный протокол без сохранения состояния, где cookie добавляют состояние в часть взаимодействий. Аутентификацию MDN описывает как способ, которым сервер проверяет личность клиента, чтобы к определённым ресурсам получали доступ только авторизованные пользователи или системы. Именно на этих примитивах держится многое из защиты LLM-продукта, поэтому добросовестная оценка проверяет их вместе с поведением модели.

Почему список Top 10 — отправная точка, а не стандарт тестирования

OWASP называет свой Top 10 стандартным документом повышения осведомлённости для разработчиков и специалистов по безопасности веб-приложений. Он отражает широкий консенсус о наиболее критичных рисках веб-приложений. На странице проекта сказано, что его внедрение — возможно, самый эффективный первый шаг к культуре разработки, ориентированной на безопасный код. Актуальная версия — OWASP Top 10 2025, редакции 2021 и 2017 годов по-прежнему доступны, у проекта указано 199 участников.

Осведомлённость и верификация — разные задачи. Проект ASVS заявляет, что его главная цель — нормализовать разброс в охвате и уровне строгости проверок безопасности веб-приложений на рынке с помощью коммерчески применимого открытого стандарта. ASVS также служит основой для тестирования технических мер защиты. Поэтому добросовестная оценка по OWASP LLM Top 10 использует список LLM для структурирования разговора о рисках, а доказательства получает из конкретных требований и тестовых сценариев.

Практический вывод для заказчика прост. Отчёт, где сказано, что все десять категорий «покрыты», но нет тестовых сценариев, доказательств и явных критериев прохождения, — это чек-лист, а не оценка. Относитесь к любому списку в формате Top 10, включая список для LLM, как к карте того, куда смотреть, и спрашивайте, как именно проверялась каждая область.

Привязка оценки к стандартам OWASP, NIST и CISA

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, опубликован в сентябре 2008 года и заменил SP 800-42. Документ помогает организациям планировать и проводить технические проверки безопасности, анализировать результаты и разрабатывать стратегии снижения рисков. Особое внимание в нём уделено преимуществам и ограничениям каждой техники. Хотя он появился раньше LLM-продуктов, он задаёт структуру работ: планирование, выполнение, анализ и устранение.

OWASP WSTG позиционирует себя как ведущий ресурс по тестированию безопасности для разработчиков веб-приложений и специалистов по безопасности. Версия 4.2 — текущий релиз в веб-формате и PDF, версия 5.0 находится в разработке. У проекта 184 участника и 246821 загрузка. В оценке LLM он даёт тестовые сценарии для HTTP- и веб-уровней вокруг модели.

OWASP ASVS 5.0.0 предоставляет проверяемые требования. Документация рекомендует идентификаторы с префиксом версии, например v5.0.0-1.2.5. Списки требований публикуются в форматах CSV, JSON и других, пригодных для программной обработки, что делает прослеживаемость находок практически достижимой. У проекта 141 участник.

На уровне управления NIST CSF 2.0 помогает организациям понимать киберриски и совершенствовать управление ими. NIST собирает комментарии до 15 октября 2026 года к SP 1353 — первоначальному публичному проекту краткого руководства по использованию искусственного интеллекта для анализа и отчётности по CSF. Это показывает, что руководства, связанные с ИИ, ещё формируются. CISA Secure by Design добавляет взгляд с позиции ответственности производителя. Более 200 производителей ПО подписали обязательство CISA и добросовестно стремятся к семи ключевым целям, а CISA приводит материалы по ИИ, например руководство по безопасной разработке ИИ-систем.

• NIST SP 800-115: жизненный цикл работ от планирования до устранения
• Список OWASP для LLM (с указанием версии): таксономия рисков, специфичных для модели
• OWASP WSTG: тестовые сценарии для окружающего веб-приложения и API
• OWASP ASVS: проверяемые требования к мерам защиты со ссылкой на версию
• MITRE CWE: классификация первопричин находок
• NIST CSF 2.0 и CISA Secure by Design: язык управления, ответственности и закупок

Ключевые выводы из доказательной базы

Классические программные слабости остаются в центре внимания. CWE Top 25 2025 года выделяет наиболее серьёзные и распространённые слабости, стоящие за 39080 записями CVE в наборе данных этого года. MITRE отмечает, что такие слабости, как внедрение команд, привлекают внимание злоумышленников. Кроме того, MITRE опубликовала список Top 10 KEV Weaknesses и ещё 15 слабостей, оказавшихся на границе попадания в Top 25. Везде, где функция LLM передаёт вывод модели в операционную систему, базу данных или браузер, эти известные классы слабостей применимы. В ASVS есть требование защиты от внедрения команд ОС, а оповещения CISA Secure by Design посвящены устранению межсайтового скриптинга, внедрения команд ОС и обхода каталогов.

Отображение вывода — это задача веб-безопасности. MDN поясняет, что Content Security Policy позволяет администраторам определять, какие ресурсы клиент может загружать для страницы. CSP помогает обнаруживать и смягчать ряд атак, включая межсайтовый скриптинг и внедрение данных. CORS позволяет разработчикам управлять реакцией сайта на межсайтовые запросы. Если чат-интерфейс выводит ответы модели в браузере, эти механизмы входят в охват.

Прослеживаемость — главный признак качества. Идентификаторы в развивающихся стандартах могут меняться. Находки со ссылкой на конкретную версию списка LLM, версионированное требование ASVS и идентификатор CWE остаются понятными и после пересмотра источников. Отчёты с неверсионированными названиями категорий быстро устаревают.

Безопасные настройки по умолчанию важны не меньше, чем усиленная конфигурация. CISA указывает, что продукты должны быть безопасны «из коробки», а многофакторная аутентификация, журналирование и единый вход должны предоставляться без доплаты. Безопасность, по словам CISA, должна быть ключевым бизнес-требованием, а не технической функцией. Поэтому оценка LLM-продукта должна проверять настройки по умолчанию, а не только лучшую конфигурацию, подготовленную к тесту.

Ландшафт стандартов меняется. WSTG 5.0 в разработке, список CWE обновляется ежегодно, а руководство NIST по применению ИИ в рамках CSF открыто для комментариев. Организациям стоит планировать периодическую переоценку и фиксировать, какие версии источников использовались в каждой оценке.

Как спроектировать санкционированный план тестирования по OWASP LLM Top 10

Сначала — разрешение. До начала любых проверок получите письменное разрешение владельца системы, где перечислены системы, среды, учётные записи, временные окна, правила обращения с данными и условия остановки. NIST SP 800-115 рассматривает тестирование как плановую деятельность с определёнными процессами и процедурами. Ничто в этой статье не даёт и не подразумевает разрешения на тестирование какой-либо системы. Тестирование сторонних поставщиков моделей или облачных сервисов требует соблюдения их условий и, при необходимости, явного согласия.

Стройте план по уровням, и у каждого уровня должен быть свой источник. Риски, специфичные для модели, берутся из указанной версии списка OWASP для LLM. Тестовые сценарии для приложения и API — из WSTG. Проверка мер защиты опирается на ASVS, а первопричины классифицируются по CWE. Такая структура устраняет частый пробел: диалоговое тестирование проведено тщательно, а аутентификация, авторизация и обработка вывода остались непроверенными.

Отдавайте предпочтение неразрушающим методам в тестовой среде с репрезентативными, но не конфиденциальными данными. Заранее договоритесь, как поступать с интеграциями, имеющими побочные эффекты, например с отправкой сообщений или записью данных. Обычные варианты — песочницы или заглушки, чтобы тестирование не могло причинить реального вреда.

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

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

По темеПроверка веб-приложения на уязвимости: объём, метод и доказательства, которые выдерживают проверку

Компромиссы: глубина, воспроизводимость и стоимость

Ручные и автоматизированные методы дополняют друг друга. NIST SP 800-115 подчёркивает, что у каждой технической методики есть преимущества и ограничения, и даёт рекомендации по их применению. Автоматические проверки хорошо масштабируются и легко повторяются от релиза к релизу. Экспертное ручное тестирование лучше выстраивает цепочки проблем между моделью, приложением и интеграциями. Обоснованный план указывает, какая методика покрывает какой риск.

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

Широта и строгость тянут в разные стороны. Охват всех категорий списка Top 10 даёт широту, а верификация в духе ASVS повышает уровень строгости. Команды с ограниченным бюджетом могут сосредоточить строгую проверку на путях, где вывод модели достигает чувствительных систем, и принять более лёгкий охват в остальном — при условии, что отчёт прямо это оговаривает.

Результаты разовой проверки устаревают. В руководстве CISA по безопасному развёртыванию ПО подчёркивается роль надёжного тестирования и измерений в процессе выпуска. Для LLM-продуктов разумным поводом для точечной повторной проверки служат изменения моделей, промптов, источников извлечения или коннекторов.

Эксплуатационные последствия после оценки

Находки должны питать жизненный цикл разработки, а не только очередь заявок. MITRE отмечает, что понимание типовых первопричин даёт обратную связь в SDLC и архитектурное планирование вендоров и помогает устранять целые классы дефектов. Меньше уязвимостей на этапе разработки — меньше проблем после развёртывания. Группировка находок по первопричинам CWE делает такую обратную связь применимой на практике.

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

У остаточного риска должен быть владелец. CISA призывает закрепить ответственность за безопасность продукта на уровне руководства, а NIST CSF 2.0 даёт общий словарь для описания результатов управления киберрисками. Привязка принятых рисков к результатам CSF позволяет руководству отслеживать их вместе с остальной программой безопасности.

Рекомендации по закупке: как выбрать подрядчика для оценки безопасности LLM

Выбирайте подрядчика только после того, как определите, что именно должна доказать оценка. Руководство CISA Secure by Demand создано для того, чтобы любой заказчик ПО мог использовать его в переговорах о закупке со сторонними реселлерами или поставщиками услуг. Тот же подход применим при заказе оценки по OWASP LLM Top 10 или тестирования на проникновение LLM-приложения.

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

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

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

• К какой именно версии списка OWASP для LLM будут привязаны находки?
• Будут ли у находок также версионированные идентификаторы ASVS и идентификаторы CWE?
• Какие области WSTG покрывают окружающее приложение и API?
• Как документируются разрешение, правила проведения работ и условия остановки?
• Как во время тестирования обрабатываются интеграции с побочными эффектами и конфиденциальные данные?
• Как фиксируется воспроизводимость находок, связанных с поведением модели?
• Включена ли повторная проверка и каковы её критерии приёмки?
• Можете ли вы предоставить обезличенный пример отчёта с форматом доказательств?

Схема принятия решений для оценки по OWASP LLM Top 10

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

Облегчённая проверка с упором на широту подходит для ранних прототипов и внутренних инструментов с ограниченным доступом к данным. Более глубокая оценка со ссылками на требования оправдана, когда вывод модели может попасть в вызовы ОС, базы данных, браузеры других пользователей или внешние инструменты. Именно на этих путях становятся достижимыми известные классы слабостей из CWE Top 25.

• 1. Цель: базовый уровень осведомлённости, проверка перед выпуском или проверка соответствия политике либо набору требований, которую NIST SP 800-115 называет допустимой целью тестирования
• 2. Инвентаризация: интерфейсы модели, прикладной уровень, пути вывода, интеграции и доступ к данным
• 3. Глубина: широкий охват списка LLM или строгая проверка по ASVS на высокорисковых путях
• 4. Разрешение: подписанный охват, правила проведения работ и правила обращения с данными
• 5. Подрядчик: ответы на закупочные вопросы, пример отчёта, условия повторной проверки
• 6. Выполнение: многоуровневый план тестирования с версионированными ссылками и доказательствами по каждой находке
• 7. Устранение: исправления, сгруппированные по первопричинам CWE и переданные в SDLC
• 8. Управление: остаточный риск, привязанный к результатам NIST CSF 2.0, с владельцем на уровне руководства и поводами для переоценки

Заключение: как сделать оценку по OWASP LLM Top 10 полезной

Оценка по OWASP LLM Top 10 приносит пользу, когда список LLM служит картой рисков, а каждый вывод подкреплён проверяемыми доказательствами. Использованные источники указывают в одном направлении. NIST SP 800-115 задаёт структуру, WSTG даёт тестовые сценарии, ASVS — версионированные требования, CWE — классификацию первопричин, MDN — веб-механизмы защиты вокруг вывода модели. NIST CSF 2.0 и CISA Secure by Design отвечают за управление и закупки.

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

По темеКомпоненты тестирования на проникновение: полный технический обзор