Безопасна ли система, разработанная с ИИ: что нужно проверить перед запуском

На этот вопрос нельзя ответить однозначно. Современные ИИ-модели способны генерировать качественный код, но не гарантируют отсутствие уязвимостей.

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

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

Дополнительный риск возникает при использовании ИИ-агентов, которые самостоятельно запускают команды, устанавливают пакеты и изменяют файлы проекта. Чем шире их доступ к инфраструктуре, тем серьёзнее возможные последствия ошибки — утечки данных, срыв сделок, потеря клиентов, иски за нарушение закона о персональных данных.

1. Проверяем качество кода и архитектуры

Аудит кода (code review) помогает выявить ошибки в реализации и проверить, соответствует ли код требованиям безопасности и бизнес-логике.

В первую очередь нужно проверить:

• авторизацию и разграничение прав;
• обработку пользовательского ввода и загрузку файлов;
• работу с базой данных и внешними API;
• хранение и передачу конфиденциальной информации;
• логику финансовых операций и расчётов.

Например, недостаточно убедиться, что менеджер вошёл в CRM. Нужно проверить, что он не может получить чужие данные, изменив идентификатор заказа в запросе.

При этом code review не заменяет комплексный аудит безопасности. Для критичных систем дополнительно могут потребоваться анализ архитектуры, моделирование угроз и проверка конфигурации инфраструктуры.

2. Выполняем автоматическую проверку AI-кода

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

• SAST (Static Application Security Testing) анализирует исходный код без запуска приложения. Он помогает выявлять потенциально небезопасные конструкции и ошибки обработки данных.
• DAST (Dynamic Application Security Testing) проверяет работающее приложение, отправляя запросы и анализируя его реакцию.

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

3. Проверяем сторонние библиотеки и зависимости

ИИ может предложить пакет с известными уязвимостями, давно не обновляющуюся библиотеку или несуществующий компонент. В последнем случае злоумышленник может зарегистрировать вредоносный пакет под предложенным названием.

Поэтому сканирование зависимостей — обязательный этап подготовки системы к запуску.

Проверяем:

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

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

4. Проверяем управление секретами

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

Управление секретами предполагает, что такие данные хранятся отдельно от исходного кода и доступны только тем компонентам, которым необходимы.

Поэтому перед запуском мы проверяем:

• нет ли секретов в коде и истории репозитория;
• используются ли защищенные хранилища или подходящие механизмы управления секретами;
• ограничены ли права каждого ключа;
• можно ли быстро отозвать и заменить скомпрометированные данные;
• какие файлы и фрагменты проекта передаются внешнему ИИ-сервису.

Если секрет попал в репозиторий, недостаточно удалить его из текущего файла: необходимо отозвать или заменить его и проверить историю изменений.

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

5. Тестируем сценарии атак

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

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

• попытки получить чужие данные через изменение идентификатора записи;
• некорректные и специально сформированные запросы;
• попытки входа без необходимых прав;
• загрузку файлов неподдерживаемого формата;
• доступ к служебным функциям через незапланированные маршруты.

Для систем с конфиденциальными данными или финансовыми операциями может потребоваться тестирование на проникновение.

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

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

6. Проверяем готовность к эксплуатации

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

Перед запуском мы уточняем:

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

Если ИИ изменял настройки CI/CD, контейнеров или инфраструктуры, их также нужно проверить.

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

Безопасность не может сводиться к одной проверке перед релизом. Ведь если искать уязвимости только перед запуском, исправления могут потребовать изменения архитектуры, повторного тестирования и переноса сроков внедрения.

Поэтому мы включаем меры безопасности в процесс разработки с самого начала.

1. Запускаем SAST и сканирование зависимостей при изменении кода.
2. Проверяем секреты и настройки доступа до публикации изменений.
3. Проводим code review перед слиянием изменений в основную ветку.
4. Тестируем критичные сценарии до подключения реальных пользователей и данных.
5. Ограничиваем доступ ИИ-агентов к секретам и инфраструктуре.
6. Назначаем ответственных за устранение уязвимостей и сопровождение системы.

Также мы используем рекомендации OWASP — организации, развивающей открытые практики и инструменты для обеспечения безопасности ПО. В частности, руководство Secure Coding with AI описывает риски использования ИИ в разработке, включая небезопасные зависимости, утечку конфиденциальных данных, чрезмерные полномочия агентов и недостаточную проверку сгенерированного кода. Рекомендации OWASP AI дополняют общие практики защиты, но не заменяют проверку конкретной системы.

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

• Проведены проверка кода и code review.
• Выполнены SAST и подходящие проверки с помощью DAST.
• Проверены зависимости и известные уязвимости.
• Секреты удалены из кода и хранятся безопасно.
• Проверены права доступа и сценарии атак.
• Настройки сервера, базы данных и инфраструктуры проверены.
• Резервное копирование и восстановление протестированы.
• Настроены мониторинг и реагирование на инциденты.
• Назначены ответственные за безопасность и сопровождение.

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

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