
Стандарт проверки безопасности ИИ (AISVS) направлен на предоставление разработчикам, архитекторам и специалистам по безопасности структурированного контрольного списка для проверки безопасности приложений на основе ИИ.
Эта работа лицензируется в соответствии с лицензией Creative Commons Attribution-ShareAlike 4.0 International.
Стандарт проверки безопасности искусственного интеллекта (AISVS) — это создаваемый сообществом каталог проверяемых требований безопасности для систем на основе ИИ. Он предоставляет разработчикам, архитекторам, инженерам по безопасности и аудиторам структурированную основу для проектирования, создания, тестирования и проверки безопасности ИИ-приложений на протяжении всего их жизненного цикла: от сбора данных и обучения моделей до развертывания, мониторинга и вывода из эксплуатации.
AISVS создан по образцу Стандарта проверки безопасности приложений OWASP (ASVS) и следует той же философии: каждое требование должно быть .
Этот проект основан Джимом Манико. В настоящее время в руководство проекта входят Джим Манико, Отто Сулин, Рико Коменда и Расс Мемисьязиджи.
| Стандарт | Направленность | Связь с AISVS |
|---|---|---|
| OWASP ASVS | Безопасность веб-приложений | AISVS расширяет концепции ASVS на угрозы, специфичные для ИИ |
| OWASP Top 10 for LLMs | Осведомлённость о главных рисках LLM | AISVS предоставляет детальные меры контроля для снижения этих рисков |
| OWASP Top 10 for Agentic Applications | Осведомлённость о главных рисках агентного ИИ | AISVS предоставляет детальные меры контроля для устранения угроз, специфичных для агентных приложений |
| NIST AI RMF | Управление рисками ИИ | AISVS предоставляет тестируемые технические меры контроля, на которые ссылается AI RMF |
| ISO/IEC 42001 | Системы управления ИИ | AISVS дополняет проверкой безопасности на уровне реализации |
Последней стабильной версией является AISVS 1.0, которую можно найти:
| Формат | Ссылка |
|---|---|
| AISVS 1.0 PDF | |
| Markdown (исходный код) | Просмотреть онлайн |
Каждому требованию AISVS присваивается уровень проверки (1, 2 или 3), указывающий на глубину гарантий безопасности:
| Уровень | Описание | Когда использовать |
|---|---|---|
| 1 | Базовые меры контроля, которые должна реализовывать каждая ИИ-система. | Все ИИ-приложения, включая внутренние инструменты и системы с низким уровнем риска. |
| 2 | Стандартные меры контроля для систем, обрабатывающих конфиденциальные данные или принимающих значимые решения. | Промышленные системы, ИИ, ориентированный на клиентов, системы, обрабатывающие персональные данные. |
| 3 | Расширенные меры контроля для сред с высокими требованиями к гарантиям, требующих защиты от сложных атак. | Критическая инфраструктура, ИИ, критичный для безопасности, ценные цели, регулируемые отрасли. |
Организации должны выбирать целевой уровень, исходя из профиля риска своей ИИ-системы. Большинство промышленных систем должны стремиться как минимум к уровню 2.
Для каждого требования стандарта Research Wiki предоставляет контекст внедрения, выходящий за рамки текста требования:
| Столбец | Что он сообщает |
|---|---|
| Устраняемая угроза | Конкретные техники атак, CVE и реальные инциденты, от которых защищает мера контроля |
| Подход к проверке | Конкретные шаги аудита, инструменты и доказательства, которые необходимо собрать |
| Пробелы и примечания | Оценки зрелости инструментов, открытые исследовательские вопросы и особенности внедрения |
Вики охватывает все 191 требование на 60 страницах, включая сводки по ландшафту угроз для каждого раздела, рекомендации по инструментам и ссылки на актуальные стандарты и исследовательскую литературу.
Каждое требование имеет идентификатор в формате C<chapter>.<section>.<requirement>, где каждый элемент — число, например C9.4.3.
C<chapter> соответствует главе, из которой взято требование; например, все требования C9.#.# относятся к главе «Оркестрация и безопасность агентных систем».<section> соответствует разделу внутри главы, в котором находится требование; например, все требования C9.4.# находятся в разделе «Идентификация агентов и оркестратора».<requirement> определяет конкретное требование в рамках главы и раздела; например, C9.4.3, которое по состоянию на версию 1.0 этого стандарта гласит:Убедитесь, что учётные данные идентификации агента ротируются по заданному расписанию.
Поскольку идентификаторы могут меняться между версиями стандарта, другим документам, отчётам или инструментам предпочтительно использовать следующий формат: v<version>-C<chapter>.<section>.<requirement>, где version — это тег версии AISVS. Например: v1.0-C9.4.3.
Примечание: v перед номером версии всегда должно быть строчным.
Если идентификаторы используются без элемента v<version>, следует считать, что они относятся к последней версии содержимого AISVS. По мере роста и изменения стандарта это становится проблематичным, поэтому авторам и разработчикам следует включать элемент версии.
AISVS использует номер версии из двух частей, v<MAJOR>.<MINOR> (например, v1.0, v1.01, v2.0). Основные версии охватывают изменения глав и разделов, минорные версии — добавления, удаления и существенные правки требований в рамках существующей структуры, а исправления (патчи) выпускаются в ветке без отдельной версии. Полная политика описана в RELEASE.md.
Каждый стабильный выпуск AISVS публикуется в виде пронумерованной папки в этом репозитории. После выпуска версии её папка блокируется; вся дальнейшая работа ведётся в новой папке. Это повторяет подход, используемый в OWASP ASVS.
/
├── 1.0/ <- published stable release (locked)
├── 1.01-dev/ <- next minor release (in progress)
Мы приветствуем вклад сообщества. Пожалуйста, откройте issue, чтобы сообщить об ошибках или предложить улучшения. По итогам обсуждения мы можем попросить вас создать pull request.
Чтобы сообщить о проблеме безопасности в самом проекте AISVS, следуйте Политике безопасности.
Весь контент проекта распространяется по лицензии Creative Commons Attribution-ShareAlike 4.0 International.