Проверка безопасности
Код, сгенерированный ИИ, может вносить уязвимости безопасности. Некоторые из них — обычные баги, которые пишут и люди; некоторые уникальны для паттернов ИИ.
Проблемы безопасности, специфичные для ИИ
Section titled “Проблемы безопасности, специфичные для ИИ”Уязвимости на основе паттернов
Section titled “Уязвимости на основе паттернов”ИИ обучается на паттернах, включая уязвимые из обучающих данных.
Типичные проблемы:
- SQL/командная инъекция
- Небезопасная десериализация
- Жёстко закодированные учётные данные
- Отсутствующие проверки аутентификации
- Небезопасные значения по умолчанию
Почему: Модели оптимизируют “код, который выглядит правильно”, а не “код, который безопасен”.
Мнимая безопасность
Section titled “Мнимая безопасность”ИИ может неправильно реализовать механизмы безопасности:
- Шифрование со слабыми алгоритмами
- Аутентификация, которая фактически не проверяет
- Проверки авторизации, которые можно обойти
- Проверка ввода без учёта граничных случаев
Код выглядит безопасным, но это не так.
Риски зависимостей
Section titled “Риски зависимостей”ИИ может предлагать пакеты, которые:
- Не существуют (галлюцинация — возможно, это typosquatting)
- Имеют известные уязвимости
- Не поддерживаются
Чек-лист проверки безопасности
Section titled “Чек-лист проверки безопасности”Обработка ввода
Section titled “Обработка ввода”- Все входные данные от пользователей проверены
- Ограничения длины ввода соблюдены
- Пути очищены (без обхода каталогов)
- URL проверены
Аутентификация и авторизация
Section titled “Аутентификация и авторизация”- Аутентификация правильно реализована
- Токены правильно проверены
- Сессии безопасно управляются
- Контроль доступа к чувствительным операциям
- Авторизация проверена на стороне сервера
Защита данных
Section titled “Защита данных”- Чувствительные данные зашифрованы при хранении
- TLS обеспечен
- Секреты не закодированы в исходном коде
- Чувствительные данные не попадают в логи
Предотвращение инъекций
Section titled “Предотвращение инъекций”- Параметризованные запросы к базе данных
- Shell-команды правильно экранированы
- Нет eval() с пользовательским вводом
- Предотвращена инъекция в шаблоны
Зависимости
Section titled “Зависимости”- Все зависимости проверены на существование
- Нет известных уязвимых версий
- Lock-файлы зафиксированы
Проверка по уровню риска
Section titled “Проверка по уровню риска”| Тип кода | Уровень проверки |
|---|---|
| Любое изменение ИИ | Просмотр паттернов, проверка ввода, верификация зависимостей |
| Чувствительный код | Полный чек-лист, ручное тестирование границ |
| Аутентификация/авториз. | Построчный анализ, моделирование угроз, проверка старшим специалистом по безопасности |
Автоматизированные инструменты
Section titled “Автоматизированные инструменты”Статический анализ (SAST): Запускать на всём коде. Не выявит все проблемы ИИ, но обнаружит распространённые уязвимости.
Сканирование зависимостей: Dependabot, Snyk. Проверять существование всех зависимостей перед установкой.
Сканирование секретов: Pre-commit хуки, сканирование репозитория, проверки в CI/CD.
Обучение команды
Section titled “Обучение команды”Специфичное для ИИ:
- Типичные паттерны, которые ИИ неправильно реализует
- Как распознать мнимую безопасность
- Когда нужно быть особенно подозрительным
Общая безопасность:
- OWASP Top 10
- Проблемы, специфичные для языка
- Рекомендации по безопасной разработке
Реагирование на инциденты
Section titled “Реагирование на инциденты”Когда код, сгенерированный ИИ, вызывает проблему безопасности:
- Относиться как к любому инциденту безопасности — не преуменьшать из-за “это ИИ сделал”
- Документировать участие ИИ: Инструмент, промпт, какая проверка проводилась
- Корневая причина: Это специфично для ИИ? Человек бы это заметил?
- Улучшение процесса: Что должно было это выявить раньше?
После инцидента: Обновить чек-листы, поделиться выводами, рассмотреть специфичные для инструмента митигации.
Ресурсы
Section titled “Ресурсы”- Government Agents – Mark Myshatyn, Los Alamos - Вопросы безопасности ИИ-агентов в государственном секторе