Риски безопасности ИИ: что должны знать команды DevSecOps для защиты систем ИИ.
Риски безопасности ИИ больше не ограничиваются поведением моделей или конфиденциальностью данных. Сегодня они также влияют на то, как пишется, проверяется, создается и распространяется программное обеспечение. По мере того, как инструменты кодирования ИИ, агентные системы ИИ и рабочие процессы на основе ИИ входят в сферу применения... SDLCКоманды DevSecOps сталкиваются с новым видом риска: более быстрый код, более быстрая автоматизация и более частые ошибки.
Однако это не означает, что командам следует замедлять внедрение ИИ. Напротив, им необходимы средства контроля безопасности, соответствующие скорости разработки с использованием ИИ. В этом руководстве мы объясняем наиболее важные риски безопасности, связанные с ИИ, как они проявляются в реальных рабочих процессах инженеров и как команды могут снизить риски для кода, зависимостей, секретов и т. д. pipelineи агентов.
Для более полного обзора того, как ИИ меняет ландшафт угроз, ознакомьтесь с нашим руководством по... Кибербезопасность ИИ.
Что представляют собой риски безопасности ИИ?
Риски безопасности ИИ — это уязвимости, угрозы или сбои, которые возникают при проектировании, обучении, интеграции или использовании искусственного интеллекта в реальных системах. Эти риски могут затрагивать модели, данные, подсказки, API, код и т.д. pipelineи инструменты, которые их объединяют.
Рекомендации NCSC по искусственному интеллекту и кибербезопасности поясняется, что кибербезопасность является ключевым требованием для безопасных и надежных систем искусственного интеллекта. Аналогичным образом, Структура управления рисками искусственного интеллекта NIST предоставляет организациям структуру для управления рисками, связанными с ИИ, посредством управления, измерения и практического контроля.
Для команд DevSecOps проблема более специфична. Искусственный интеллект теперь является частью цепочки разработки программного обеспечения. Он пишет код, предлагает зависимости, генерирует конфигурацию, вызывает API и иногда действует автономно. В результате риски безопасности, связанные с ИИ, должны обрабатываться внутри системы. SDLCне только на уровне модели.
Почему риски безопасности ИИ сейчас отличаются?
Традиционные риски кибербезопасности обычно связаны с написанным человеком кодом, уязвимыми программными пакетами, слабыми учетными данными или неправильно настроенной инфраструктурой. Эти риски по-прежнему существуют. Однако искусственный интеллект меняет скорость их появления и сложность обнаружения.
Сгенерированный ИИ код может выглядеть корректно, но при этом не проходить проверки авторизации. ИИ-помощник в программировании может предложить уязвимый пакет. Агентный рабочий процесс может вызвать не тот инструмент, получить доступ к неправильному файлу или раскрыть секретную информацию в журнале. Кроме того, системы ИИ часто зависят от контекста, подсказок, коннекторов и внешних инструментов, что создает больше мест, где может возникнуть проблема с безопасностью.
OWASP Top 10 для поступления на магистерскую программу. В нем освещаются такие риски, как быстрое внедрение вредоносного кода, раскрытие конфиденциальной информации, проблемы с цепочкой поставок и чрезмерная свобода действий. Эти категории полезны, поскольку они связывают поведение ИИ с реальными проблемами безопасности приложений.
Иными словами, риски безопасности ИИ касаются не только самой модели. Они затрагивают всю систему, окружающую эту модель.
Основные риски безопасности ИИ для команд DevSecOps
Ниже перечислены риски, наиболее значимые при использовании ИИ в разработке, безопасности приложений и т. д. CI/CD рабочих процессов.
1. Уязвимости в коде, сгенерированном ИИ.
Инструменты для разработки программного обеспечения на основе ИИ могут генерировать код, который работает, но небезопасен. Например, они могут создавать SQL-запросы без надлежащей параметризации, пропускать проверку входных данных или реализовывать слабую логику аутентификации.
Это происходит потому, что многие системы искусственного интеллекта генерируют вероятные шаблоны кода на основе обучающих данных. Однако вероятный код не всегда является безопасным. На практике модель может воспроизводить небезопасные примеры, поскольку они часто встречаются в общедоступных репозиториях.
Общие примеры включают в себя:
- SQL-инъекция
- Межсайтовый скриптинг
- Отсутствуют проверки авторизации.
- Некорректная обработка сессий
- Небезопасная десериализация
- Отсутствует защита от CSRF-атак.
Следовательно, сгенерированный ИИ код следует считать ненадежным до тех пор, пока он не пройдет проверку. SASTПроверка и анализ политики.
Предложение по внутренней ссылке: свяжите этот раздел с вашей публикацией на AI SAST.
2. Риски, связанные с цепочкой поставок и зависимостью от поставщиков.
Инструменты искусственного интеллекта не только генерируют код. Они также предлагают пакеты, версии, скрипты и команды установки. Это создает прямую связь между рекомендациями ИИ и рисками в цепочке поставок программного обеспечения.
Например, инструмент искусственного интеллекта может предложить следующее:
- Устаревшая упаковка
- Зависимость, написанная с помощью опечатки.
- Галлюцинаторное название пакета
- Пакет с подозрительными скриптами установки.
- Библиотека, которая уязвима, но все еще широко используется.
Более того, злоумышленники могут использовать это поведение, регистрируя имена пакетов, которые, скорее всего, будут придуманы инструментами искусственного интеллекта. Этот риск часто называют «слопсквоттингом». Он превращает иллюзию модели в атаку на цепочку поставок пакетов.
Чтобы снизить этот риск, командам необходимо SCAобнаружение вредоносного ПО, обеспечение соблюдения политики зависимостей и анализ достижимости. Также следует использовать сигналы уязвимости, такие как ЭПСС и активную эксплуатацию разведывательной информации, полученной от CISКаталог известных эксплуатируемых уязвимостей.
3. Раскрытие секретов в рабочих процессах ИИ.
Раскрытие секретной информации — один из наиболее реальных рисков безопасности ИИ. Разработчики часто вставляют контекст в инструменты ИИ. Этот контекст может включать ключи API, токены, учетные данные, URL-адреса или внутреннюю конфигурацию.
Кроме того, сгенерированный ИИ код может содержать заполнители, которые выглядят как настоящие, или, что еще хуже, копировать секреты обратно в исходные файлы. pipeline скрипты или журналы. Как только секреты попадают в историю Git или CI/CD даже после первоначального вскрытия архивов, они могут оставаться уязвимыми для эксплуатации ещё долгое время. commit.
К числу распространенных точек воздействия относятся:
- История подсказок
- Сгенерированный код
- идти commits
- CI/CD бревна
- IaC файлов
- Образы контейнеров
- Общие рабочие области
По этой причине командам следует объединить сканирование на уровне IDE. pre-commit проверки, сканирование истории репозитория, CI/CD Сканирование журналов и автоматическое аннулирование.
Предложение по внутренней ссылке: свяжите этот раздел с вашим продуктом для обеспечения безопасности секретов или соответствующим контентом.
4. Неправильное использование агентов и инструментов ИИ.
Агентический ИИ Это создает новый уровень риска, поскольку агенты не только предлагают действия. Они могут сами совершать эти действия.
Агент с искусственным интеллектом может выполнять команды оболочки, редактировать файлы, вызывать API, открывать pull requestsИзменять рабочие процессы CI или взаимодействовать с облачными сервисами. Хотя это значительно повышает производительность, это также увеличивает радиус поражения ошибками.
Ключевые риски включают в себя:
- Небезопасное выполнение командной оболочки
- Ключи API с избыточными правами доступа
- Несанкционированные изменения кода
- Неправильная настройка коннектора MCP или API.
- Использование инструментов выходит за рамки утвержденной области применения.
- Доступ к окружающей среде, выходящий за рамки требований задачи.
Категория OWASP LLM Top 10, касающаяся чрезмерного доступа, особенно актуальна в данном случае. Если у агента слишком много прав доступа, неверная инструкция, внедрение вредоносного кода или скомпрометированный инструмент могут привести к серьезной угрозе безопасности.
5. CI/CD и Pipeline Риски
Сгенерированный ИИ код в конечном итоге достигает pipelineНа этом этапе риски перемещаются из исходного кода в сборки, артефакты, секреты, зависимости и рабочие процессы развертывания.
Например, изменения, внесенные с помощью ИИ, могут:
- Добавить небезопасный этап сборки
- Изменение рабочего процесса GitHub Actions
- Загрузка вредоносного пакета во время установки.
- Запись секретных данных в журналы сборки
- Отключить элемент управления безопасностью
- Изменение логики развертывания
Следовательно, CI/CD Безопасность становится важнейшим фактором внедрения ИИ. Pipeline guardrails Необходимо блокировать небезопасные шаблоны до того, как они попадут в производство. Для получения более подробной информации см. наши материалы по этой теме. CI/CD безопасность и software supply chain security.
6. Утечка данных и внедрение подсказок.
Внедрение подсказок — одна из наиболее известных угроз безопасности ИИ, но её часто неправильно понимают. Это проблема не только чат-ботов. Она может повлиять на любой рабочий процесс ИИ, который принимает внешние входные данные, а затем использует эти данные для управления действиями.
Например, описание вредоносной программы, файл README, заявка в службу поддержки или страница документации по зависимостям могут содержать скрытые инструкции. Если агент ИИ прочтет этот контент и последует его указаниям, злоумышленник может повлиять на вызовы инструментов, изменения кода или доступ к данным.
Утечка данных может происходить схожим образом. Модель может раскрывать конфиденциальную информацию, обобщать закрытые файлы или отправлять конфиденциальные данные во внешние сервисы. Поэтому системам ИИ необходимы оперативная фильтрация, контроль выходных данных, ограничения на использование инструментов и четкие границы доступа к данным.
Риски безопасности ИИ в различных областях SDLC
Риски безопасности ИИ возникают на разных этапах жизненного цикла программного обеспечения. Ключевым моментом является обеспечение безопасности на каждом этапе, а не только конечного приложения.
| SDLC Этап | Риски безопасности ИИ | Пример | Рекомендуемый контроль |
|---|---|---|---|
| IDE | Небезопасный код, сгенерированный ИИ. | Искусственный интеллект, используемый в качестве помощника в программировании, предлагает небезопасную логику аутентификации. | Торговая аналитика в режиме реального времени с полной прозрачностью SAST и безопасную обратную связь по коду. |
| Commit | Секреты раскрытия | Токен появляется в сгенерированном коде или commit историю. | Раскрытие секретов, pre-commit проверки и автоматическое аннулирование. |
| Pull Request | обход политики | Сгенерированный код изменяет правила контроля доступа без проверки. | PR guardrails и обеспечение соблюдения политики. |
| Построить | Злонамеренная зависимость | Пакет, предложенный искусственным интеллектом, включает в себя подозрительное поведение при установке. | SCAобнаружение вредоносных программ и проверка политики зависимостей. |
| CI/CD | Pipeline манипуляция | Агент вносит изменения в файлы рабочих процессов или сценарии развертывания. | CI/CD Проверки безопасности и обнаружение аномалий. |
| Время выполнения | Немедленное внедрение или утечка данных | Внешние входные данные приводят к тому, что рабочий процесс ИИ раскрывает конфиденциальную информацию. | Оперативный контроль, ограничение доступа и мониторинг. |
Риски безопасности ИИ против традиционных рисков кибербезопасности
Традиционные методы кибербезопасности по-прежнему актуальны. Однако искусственный интеллект добавляет новые модели поведения, требующие иного контроля.
| Район | Традиционные риски кибербезопасности | Риски безопасности ИИ |
|---|---|---|
| Code | Уязвимости, созданные людьми. | Искусственный интеллект генерирует небезопасные шаблоны с большей скоростью. |
| Зависимости | Известные уязвимые пакеты. | Галлюцинаторные, вредоносные или небезопасные пакеты, предлагаемые искусственным интеллектом. |
| Секреты | Учетные данные были случайно потеряны. commitсоздано разработчиками. | Секреты, скопированные в подсказки, сгенерированный код или журналы. |
| Инструменты | Неправильное использование инструментов разработчика вручную. | Неправильное использование инструментов или API автономными агентами. |
| Pipelines | Misconfigured CI/CD рабочих процессов. | Изменения в рабочем процессе, инициированные агентом, или небезопасная автоматизация. |
Примеры реальных рисков безопасности ИИ
Риски безопасности ИИ — это не теория. В настоящее время существует ряд общедоступных концепций и исследовательских проектов, которые более формально отслеживают эти вопросы.
Репозиторий рисков ИИ MIT OWASP каталогизирует более 1,700 рисков, связанных с ИИ, по различным причинам и областям. В то же время OWASP предоставляет практические категории для рисков применения LLM, включая быстрое внедрение угроз, раскрытие конфиденциальной информации, уязвимости цепочки поставок и чрезмерное вмешательство.
Для команд DevSecOps наиболее показательные примеры часто встречаются в процессе разработки программного обеспечения:
- Инструменты искусственного интеллекта указывают на уязвимый код.
- Агенты ИИ изменяют файлы рабочих процессов
- Зависимости, генерируемые ИИ, приводят к уязвимости цепочки поставок.
- Секреты, утекающие через подсказки, журналы или commits
- Вызов инструментов в рамках рабочих процессов Agentic, выходящих за рамки утвержденной области применения.
Короче говоря, риски безопасности ИИ становятся гораздо серьезнее, когда системы ИИ могут взаимодействовать с кодом, учетными данными, пакетами и т.д. pipelineили инфраструктура.
Как на практике снизить риски безопасности ИИ.
Лучший способ снизить риски безопасности, связанные с ИИ, — рассматривать разработку с использованием ИИ как часть процесса SDLCЭто означает раннее сканирование, частую проверку и обеспечение соблюдения правил там, где разработчики фактически работают.
1. Сканируйте сгенерированный ИИ код в IDE.
Разработчики должны видеть обратную связь по безопасности во время написания или принятия кода, сгенерированного ИИ. Это уменьшает переключение контекста и помогает исправлять проблемы до того, как они попадут в Git.
Использование:
- SAST в IDE
- Встроенные пояснения к уязвимостям
- Предложения по безопасному исправлению
- Исправление ошибок с учетом политики
Это особенно важно для программистов-ассистентов на основе ИИ, где небезопасные подсказки могут быстро попасть в кодовую базу.
2. Проверьте зависимости перед сборкой.
Предложенные ИИ зависимости необходимо проверять перед их установкой или распространением. Поэтому командам следует обеспечивать контроль зависимостей на всех этапах разработки. CI/CD.
Использование:
- SCA
- Обнаружение вредоносного ПО
- обнаружение тайпсквоттинга
- Оценка EPSS
- Анализ достижимости
- Блокировка на основе политики
Это помогает расставить приоритеты для пакетов, представляющих реальный риск, а не просто теоретическую угрозу.
3. Автоматическое обнаружение и аннулирование секретов.
Сканирование секретов должно охватывать не только исходный код. Рабочие процессы с использованием ИИ могут раскрыть учетные данные во многих местах.
Использование:
- Pre-commit сканирование
- Сканирование истории репозитория
- Pipeline сканирование журнала
- IaC сканирование
- Сканирование изображения контейнера
- Автоматическая отмена
В результате команды сокращают время между заражением и локализацией инфекции.
4. Обеспечить соблюдение Guardrails in CI/CD
Guardrails Необходимо решить, достаточно ли безопасно вносить изменения, чтобы их продолжать. Составление отчетов полезно, но блокирование необходимо при критических рисках.
Guardrails должен охватывать:
- Новые критические уязвимости
- Секреты
- Вредоносные зависимости
- Незакрепленные или ненадежные пакеты
- Небезопасные изменения рабочего процесса
- Отсутствующий SBOMs
- Нарушения политики
Кроме того, командам следует начинать с режима только для составления отчетов по мере необходимости, а затем переходить к блокировке по мере роста уверенности.
5. Мониторинг поведения агентских инструментов.
Агентным системам искусственного интеллекта необходима наблюдаемость. Если агент может редактировать файлы, запускать сборки или вызывать API, командам необходимо знать, что он сделал, когда он это сделал и было ли это действие ожидаемым.
Монитор:
- Вызовы инструментов
- Изменения в файле рабочего процесса
- Активность записи в репозиторий
- Направления сети
- Секретный доступ
- Pull request создание
- Pipeline триггеры
Без такой прозрачности трудно доверять автономии агента.
В каких случаях Xygeni помогает снизить риски безопасности ИИ?
Xygeni фокусируется на обеспечении безопасности разработки с использованием ИИ на протяжении всей цепочки доставки программного обеспечения. Вместо того чтобы рассматривать риски, связанные с ИИ, как отдельную категорию, компания объединяет код, зависимости, секреты и т.д. pipelineа также в контексте бизнеса.
Например:
- SAST помогает выявлять небезопасный код, сгенерированный ИИ, на ранней стадии.
- SCA Проверяет зависимости и обнаруживает вредоносные пакеты.
- Секреты безопасности Обнаруживает скрытые учетные данные в различных репозиториях и pipelines.
- CI/CD Безопасность. обеспечивает соблюдение правил до того, как будут внесены небезопасные изменения.
- Обнаружение аномалий Выявляет необычное поведение в процессах разработки и доставки.
- ASPM объединяет полученные данные в единое представление о рисках, чтобы команды могли расставить приоритеты.
Это важно, потому что риски безопасности ИИ по своей природе являются межслойными. Уязвимая зависимость, открытый токен и небезопасное изменение рабочего процесса могут выглядеть как отдельные проблемы в точечных инструментах. Однако вместе они могут представлять собой гораздо более масштабный путь атаки.
Ключевые принципы управления рисками в области безопасности ИИ.
Существует несколько методологий, помогающих командам структурировать свою работу.
Структура управления рисками искусственного интеллекта NIST Помогает организациям составлять карты, измерять, управлять и контролировать риски, связанные с ИИ. Полезен для программ управления, соблюдения нормативных требований и управления рисками.
OWASP Top 10 для поступления на магистерскую программу. Этот подход более практичен для команд, занимающихся безопасностью приложений, поскольку он напрямую связан с техническими рисками, такими как быстрое внедрение вредоносного кода, утечка конфиденциальных данных, уязвимости цепочки поставок и чрезмерная свобода действий.
Рекомендации NCSC по искусственному интеллекту и кибербезопасности Это полезно для руководителей служб безопасности, которым необходимо понять, как ИИ меняет киберриски в организации.
В совокупности эти ресурсы ясно показывают один момент: безопасность ИИ должна обеспечиваться на всех уровнях — от людей и процессов до систем и рабочих процессов разработки программного обеспечения.
Контрольный список: Как снизить риски безопасности ИИ
Используйте этот контрольный список в качестве практической отправной точки.
| Зона управления | Что делать | Почему это имеет значение |
|---|---|---|
| Код, сгенерированный ИИ | Run SAST в IDE, PR и CI/CD pipeline. | Предотвращает попадание небезопасного кода в рабочую среду. |
| Зависимости | Используйте SCAобнаружение вредоносных программ, EPSS и доступность. | Блокирует рискованные пакеты, предложенные искусственным интеллектом. |
| Секреты | Сканировать commitс, журналы, история, IaCи контейнеры. | Снижает риск утечки и неправомерного использования учетных данных. |
| CI/CD | обеспечивать соблюдение pipeline guardrails и политические барьеры. | Предотвращает небезопасные сборки и развертывания. |
| Агентские инструменты | Отслеживайте вызовы инструментов, доступ к API и изменения в рабочих процессах. | Ограничивает чрезмерную самостоятельность и неожиданное поведение. |
| Управление рисками | Используйте ASPM сопоставить результаты, полученные на разных уровнях. | Помогает командам сосредоточиться на реальных бизнес-рисках. |
Основные выводы
- Риски безопасности ИИ теперь затрагивают код, зависимости, секреты. pipelineи агентов.
- Традиционные инструменты обеспечения безопасности приложений по-прежнему необходимы, но они должны запускаться раньше и с учетом большего контекста.
- Сгенерированный ИИ код следует считать ненадежным до тех пор, пока он не пройдет проверку.
- Рабочие процессы агентов ИИ требуют guardrailsразрешения и возможность наблюдения.
- Командам DevSecOps необходима единая система мониторинга на всех уровнях. SDLC эффективно управлять рисками, связанными с ИИ.
Часто задаваемые вопросы: Риски безопасности ИИ
Какие существуют риски для безопасности ИИ?
Риски безопасности ИИ — это угрозы или уязвимости, которые возникают при создании, интеграции или использовании систем ИИ. Они могут затрагивать модели, данные, подсказки, код, зависимости, API и т. д. pipelines.
Какие самые серьезные риски безопасности ИИ представляют для команд DevSecOps?
К числу основных рисков относятся небезопасный код, сгенерированный ИИ, уязвимые зависимости, раскрытие секретной информации, внедрение вредоносного кода, избыточные права доступа агентов и небезопасные методы. CI/CD автоматизации.
Почему риски безопасности, связанные с ИИ, отличаются от традиционных рисков кибербезопасности?
Системы искусственного интеллекта способны генерировать код, предлагать зависимости, вызывать инструменты и действовать автономно. В результате риски проявляются быстрее и на большем количестве уровней. SDLC.
Как команды могут снизить риски безопасности, связанные с ИИ?
Команды могут снизить риски, сканируя сгенерированный ИИ код, проверяя зависимости, выявляя секреты и обеспечивая соблюдение правил. CI/CD guardrailsмониторинг поведения агентов и сопоставление полученных результатов посредством ASPM.
Безопасен ли код, сгенерированный искусственным интеллектом?
Сгенерированный ИИ код по умолчанию небезопасен. Его следует проверять, сканировать, тестировать и подтверждать работоспособность, прежде чем он попадет в производство.
Заключительные мысли: Риски безопасности ИИ требуют SDLC-Регуляторы уровня
Искусственный интеллект меняет скорость и характер рисков в программном обеспечении. Он помогает командам разрабатывать продукты быстрее, но также открывает новые возможности для проникновения в цепочку поставок небезопасного кода, раскрытых секретов, небезопасных зависимостей и рискованной автоматизации.
Следовательно, безопасность ИИ не может обеспечиваться только с помощью управления моделями или политических документов. Необходимы практические меры контроля внутри системы. SDLCОбратная связь от IDE, SAST, SCA, обнаружение секретов, CI/CD guardrails, обнаружение аномалий и ASPMкорреляция уровня.
Команды, которые хорошо управляют рисками безопасности ИИ, не будут препятствовать его внедрению. Они будут теми, кто создаст надлежащий уровень защиты вокруг него.
