Ризики безпеки ШІ: що повинні знати команди DevSecOps для захисту систем ШІ
Ризики безпеки штучного інтелекту більше не обмежуються поведінкою моделі чи конфіденційністю даних. Сьогодні вони також впливають на те, як пишеться, перевіряється, створюється та постачається програмне забезпечення. Оскільки інструменти кодування на основі штучного інтелекту, агентні системи штучного інтелекту та робочі процеси на базі штучного інтелекту входять у SDLCКоманди DevSecOps стикаються з новим видом ризику: швидший код, швидша автоматизація та швидші помилки.
Однак це не означає, що команди повинні уповільнювати впровадження ШІ. Натомість їм потрібні засоби контролю безпеки, що відповідають швидкості розробки за допомогою ШІ. У цьому посібнику ми пояснюємо найважливіші ризики безпеки, пов'язані зі ШІ, як вони проявляються в реальних інженерних робочих процесах і як команди можуть зменшити ризики, пов'язані з кодом, залежностями, секретами, pipelineта агенти.
Для ширшого огляду того, як штучний інтелект змінює ландшафт загроз, див. наш посібник Кібербезпека зі штучним інтелектом.
Які ризики безпеки пов'язані з ШІ?
Ризики безпеки ШІ – це слабкі місця, загрози або режими збоїв, які виникають під час проектування, навчання, інтеграції або використання штучного інтелекту в реальних системах. Ці ризики можуть впливати на моделі, дані, підказки, API, код, pipelineта інструменти, що їх пов'язують.
Команда Керівництво NCSC щодо штучного інтелекту та кібербезпеки пояснює, що кібербезпека є основною вимогою для безпечних та надійних систем штучного інтелекту. Аналогічно, NIST AI Risk Management Framework надає організаціям структуру для управління ризиками, пов'язаними зі штучним інтелектом, за допомогою управління, вимірювання та практичного контролю.
Для команд DevSecOps проблема є більш специфічною. Штучний інтелект тепер є частиною ланцюжка поставок програмного забезпечення. Він пише код, пропонує залежності, генерує конфігурацію, викликає API та іноді діє автономно. Як результат, ризики безпеки, пов'язані з ШІ, мають оброблятися всередині... SDLC, не лише на шарі моделі.
Чому ризики безпеки штучного інтелекту зараз відрізняються
Традиційні ризики кібербезпеки зазвичай виникають через написаний людиною код, вразливі пакети, слабкі облікові дані або неправильно налаштовану інфраструктуру. Ці ризики все ще існують. Однак штучний інтелект змінює швидкість їх появи та складність їх виявлення.
Код, згенерований штучним інтелектом, може виглядати правильно, але все одно не проходить перевірку авторизації. Помічник кодування зі штучним інтелектом може запропонувати вразливий пакет. Агентський робочий процес може викликати неправильний інструмент, отримати доступ до неправильного файлу або розкрити секрет у журналі. Крім того, системи штучного інтелекту часто залежать від контексту, підказок, конекторів та зовнішніх інструментів, що створює більше місць, де безпека може дати збій.
Команда OWASP Топ-10 для заявок на ступінь магістра права (LLM) висвітлює такі ризики, як швидке введення інформації, розкриття конфіденційної інформації, проблеми з ланцюгом поставок та надмірна свобода дій. Ці категорії корисні, оскільки вони пов'язують поведінку ШІ з реальними проблемами безпеки додатків.
Іншими словами, ризики безпеки ШІ стосуються не лише моделі. Вони стосуються всієї системи навколо моделі.
Основні ризики безпеки штучного інтелекту для команд DevSecOps
Нижче наведено ризики, які є найбільш важливими, коли штучний інтелект використовується в розробці, AppSec та CI/CD робочі процеси.
1. Вразливості коду, згенерованого штучним інтелектом
Інструменти штучного інтелекту можуть генерувати код, який працює, але є небезпечним. Наприклад, вони можуть створювати SQL-запити без належної параметризації, пропускати перевірку вхідних даних або реалізовувати слабку логіку автентифікації.
Це відбувається тому, що багато систем штучного інтелекту генерують ймовірні шаблони коду на основі навчальних даних. Однак ймовірний код не завжди є безпечним кодом. На практиці модель може відтворювати небезпечні приклади, оскільки вони є поширеними в публічних репозиторіях.
Загальні приклади включають:
- SQL injection
- Перехресні сценарії
- Відсутні перевірки авторизації
- Слабка обробка сеансів
- Небезпечна десеріалізація
- Відсутній захист CSRF
Таким чином, код, згенерований штучним інтелектом, слід вважати ненадійним, доки він не пройде перевірку. SAST, перевірки політики та огляд.
Пропозиція внутрішнього посилання: підключіть цей розділ до вашої публікації на AI SAST.
2. Ризики ланцюга поставок та залежності
Інструменти штучного інтелекту не лише генерують код. Вони також пропонують пакети, версії, скрипти та команди встановлення. Це створює прямий шлях від рекомендацій ШІ до ризиків у ланцюжку постачання програмного забезпечення.
Наприклад, інструмент штучного інтелекту може запропонувати:
- Застарілий пакет
- Залежність з помилкою
- Галюцинована назва пакета
- Пакет із підозрілими скриптами встановлення
- Бібліотека, яка є вразливою, але все ще широко використовується
Більше того, зловмисники можуть використовувати цю поведінку, реєструючи назви пакетів, які інструменти штучного інтелекту, ймовірно, винайдуть. Цей ризик часто називають недбалим використанням (slopsquatting). Він перетворює галюцинацію моделі на атаку на ланцюжок поставок пакетів.
Щоб зменшити цей ризик, командам потрібно SCA, виявлення шкідливого програмного забезпечення, застосування політики залежностей та аналіз досяжності. Вони також повинні використовувати сигнали експлойта, такі як EPSS та активну експлуатаційну розвідку від CISКаталог відомих вразливостей, що використовувалися для експлуатації.
3. Розкриття секретів у робочих процесах штучного інтелекту
Розкриття секретів є одним із найпрактичніших ризиків безпеки для ШІ. Розробники часто вставляють контекст в інструменти ШІ. Цей контекст може включати ключі API, токени, облікові дані, URL-адреси або внутрішню конфігурацію.
Крім того, код, згенерований штучним інтелектом, може містити заповнювачі, які виглядають справжніми, або, що ще гірше, копіювати секрети назад у вихідні файли, pipeline скрипти або журнали. Після того, як секрети потрапляють до історії Git або CI/CD журнали, вони можуть залишатися придатними для використання ще довго після початкового commit.
Звичайні точки впливу включають:
- Підказка щодо історії хвороби
- Згенерований код
- Git commits
- CI/CD logs
- IaC файли
- Зображення контейнерів
- Спільні робочі місця
З цієї причини командам слід поєднувати сканування на рівні IDE, pre-commit перевірки, сканування історії репозиторію, CI/CD сканування журналів та автоматичне скасування.
Пропозиція внутрішнього посилання: підключіть цей розділ до вашого продукту для захисту секретів або пов’язаного контенту.
4. Неправильне використання агентів та інструментів штучного інтелекту
Агентський ШІ вводить новий рівень ризику, оскільки агенти не лише пропонують дії. Вони можуть і самі їх виконувати.
Агент штучного інтелекту може виконувати команди оболонки, редагувати файли, викликати API, відкривати pull requests, змінювати робочі процеси неперервної інтеграції або взаємодіяти з хмарними сервісами. Хоча це створює величезне підвищення продуктивності, це також збільшує радіус вибуху помилок.
Основні ризики включають:
- Небезпечне виконання оболонки
- Ключі API з надмірними правами доступу
- Несанкціоновані зміни коду
- Неправильна конфігурація MCP або API-конектора
- Виклики інструментів поза межами затвердженої області застосування
- Доступ до середовища, що перевищує вимоги завдання
Категорія OWASP LLM Top 10 за надмірну свободу дій є особливо актуальною тут. Якщо агент має забагато прав доступу, неправильна інструкція, швидке введення даних або скомпрометований інструмент можуть перетворитися на справжню подію безпеки.
5. CI/CD та Pipeline Ризики
Код, згенерований штучним інтелектом, зрештою досягає pipelineУ цей момент ризик переміщується з вихідного коду на збірки, артефакти, секрети, залежності та робочі процеси розгортання.
Наприклад, зміна за допомогою штучного інтелекту може:
- Додати небезпечний крок збірки
- Змінення робочого процесу дій GitHub
- Завантажити шкідливий пакет під час встановлення
- Друк секретів у журналах збірки
- Вимкнення елемента керування безпекою
- Зміна логіки розгортання
Отже, 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 перевірки безпеки та виявлення аномалій. |
| Час виконання | Швидке введення або витік даних | Зовнішні дані призводять до того, що робочий процес штучного інтелекту розкриває конфіденційний контекст. | Оперативний контроль, обмеження доступу та моніторинг. |
Ризики безпеки, пов'язані зі штучним інтелектом, проти традиційних ризиків кібербезпеки
Традиційна кібербезпека все ще має значення. Однак штучний інтелект додає нові моделі поведінки, які вимагають інших елементів контролю.
| Область | Традиційний ризик кібербезпеки | Ризик безпеки ШІ |
|---|---|---|
| код | Вразливості, написані людиною. | Незахищені шаблони, згенеровані штучним інтелектом, на вищій швидкості. |
| Залежності | Відомі вразливі пакети. | Галюциновані, шкідливі або небезпечні пакети, запропоновані штучним інтелектом. |
| Секрети | Випадково отримано облікові дані commitрозроблено розробниками. | Секрети, скопійовані в підказки, згенерований код або журнали. |
| Інструменти | Ручне неправомірне використання інструментів розробника. | Автономні агенти зловживають інструментами або API. |
| Pipelines | Неправильно налаштовано CI/CD робочі процеси. | Зміни в робочому процесі, згенеровані агентом, або небезпечна автоматизація. |
Приклади ризиків безпеки штучного інтелекту в реальному світі
Ризик безпеки штучного інтелекту не є теоретичним. Кілька публічних фреймворків та дослідницьких зусиль зараз відстежують ці питання більш формально.
Команда Репозиторій ризиків штучного інтелекту MIT каталогізує понад 1,700 ризиків, пов'язаних зі штучним інтелектом, з різних причин та областей. Тим часом OWASP надає практичні категорії для ризиків застосування LLM, включаючи оперативне впровадження, розкриття конфіденційної інформації, вразливості ланцюга поставок та надмірну свободу дій.
Для команд DevSecOps найрелевантніші приклади часто зустрічаються у сфері розробки програмного забезпечення:
- Інструменти штучного інтелекту, що підказують вразливий код
- Агенти ШІ, що змінюють файли робочого процесу
- Залежності, згенеровані штучним інтелектом, що впроваджують вплив ланцюга поставок
- Витік секретів через підказки, журнали або commits
- Робочі процеси агентів викликають інструменти поза межами затвердженої області застосування
Коротше кажучи, ризики безпеки для штучного інтелекту стають набагато серйознішими, коли системи штучного інтелекту можуть торкатися коду, облікових даних, пакетів, pipelineабо інфраструктура.
Як пом'якшити ризики безпеки, пов'язані зі штучним інтелектом, на практиці
Найкращий спосіб зменшити ризики безпеки, пов'язані зі штучним інтелектом, — це розглядати розробку за допомогою штучного інтелекту як частину SDLCЦе означає раннє сканування, часту перевірку та дотримання правил там, де розробники фактично працюють.
1. Відскануйте код, згенерований штучним інтелектом, у середовищі розробки (IDE).
Розробники повинні отримувати відгуки щодо безпеки під час написання або прийняття коду, згенерованого штучним інтелектом. Це зменшує перемикання контексту та допомагає виправляти проблеми до того, як вони потраплять до Git.
Використання:
- SAST в інтегрованому середовищі розробки
- Вбудовані пояснення вразливостей
- Пропозиції щодо безпечного виправлення
- Усунення наслідків з урахуванням політики
Це особливо важливо для помічників з кодування на основі штучного інтелекту, де небезпечні пропозиції можуть швидко потрапити до кодової бази.
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 AI Risk Management Framework допомагає організаціям відображати, вимірювати, керувати та контролювати ризики, пов'язані зі штучним інтелектом. Це корисно для програм керівництва, відповідності вимогам та управління ризиками.
Команда OWASP Топ-10 для заявок на ступінь магістра права (LLM) є більш практичним для команд AppSec, оскільки він безпосередньо відображає технічні ризики, такі як оперативне введення даних, викриття конфіденційних даних, вразливості ланцюга поставок та надмірна свобода дій.
Команда Керівництво NCSC щодо штучного інтелекту та кібербезпеки корисний для керівників служб безпеки, яким потрібно зрозуміти, як штучний інтелект змінює кіберризики організації.
Разом ці ресурси чітко демонструють одну думку: безпеку штучного інтелекту необхідно керувати з урахуванням потреб людей, процесів, систем та робочих процесів розробки програмного забезпечення.
Контрольний список: Як зменшити ризики безпеки, пов'язані зі штучним інтелектом
Використовуйте цей контрольний список як практичну відправну точку.
| Зона управління | Що робити | Чому це має значення |
|---|---|---|
| Код, створений ШІ | прогін SAST в IDE, PR та CI/CD pipeline. | Запобігає потраплянню незахищеного коду у продакшн. |
| Залежності | Скористайтеся кнопкою SCA, виявлення шкідливого програмного забезпечення, EPSS та досяжність. | Блокує ризиковані пакети, запропоновані штучним інтелектом. |
| Секрети | сканування commits, журнали, історія, IaC, та контейнери. | Зменшує розкриття облікових даних та їх неправомірне використання. |
| CI/CD | забезпечувати дотримання pipeline guardrails та політичні ворота. | Зупиняє небезпечні збірки та розгортання. |
| Інструменти агентів | Відстежуйте виклики інструментів, доступ до API та зміни в робочому процесі. | Обмежує надмірну свободу дій та неочікувану поведінку. |
| Управління ризиками | Скористайтеся кнопкою ASPM співвіднести результати між шарами. | Допомагає командам зосередитися на реальних бізнес-ризиках. |
Ключові винесення
- Ризики безпеки ШІ тепер впливають на код, залежності, секрети, pipelineта агенти.
- Традиційні інструменти AppSec все ще потрібні, але вони повинні запускатися раніше та з більшим контекстом.
- Код, згенерований штучним інтелектом, слід вважати ненадійним до його перевірки.
- Необхідність робочих процесів агентів ШІ guardrails, дозволи та спостережуваність.
- Командам DevSecOps потрібна єдина прозорість у всьому SDLC ефективно керувати ризиками, пов'язаними зі штучним інтелектом.
Найчастіші запитання: Ризики безпеки, пов'язані зі штучним інтелектом
Які ризики безпеки існують для ШІ?
Ризики безпеки ШІ – це загрози або слабкі місця, що виникають під час створення, інтеграції або використання систем ШІ. Вони можуть впливати на моделі, дані, підказки, код, залежності, API та pipelines.
Які найбільші ризики безпеки ШІ для команд DevSecOps?
Найбільші ризики включають небезпечний код, згенерований штучним інтелектом, вразливі залежності, розкриття секретів, швидке впровадження, надмірні дозволи агентів та небезпечні CI/CD автоматизація.
Чому ризики безпеки, пов'язані зі штучним інтелектом, відрізняються від традиційних ризиків кібербезпеки?
Системи штучного інтелекту можуть генерувати код, пропонувати залежності, викликати інструменти та діяти автономно. В результаті ризики проявляються швидше та на більшій кількості рівнів. SDLC.
Як команди можуть зменшити ризики безпеки ШІ?
Команди можуть зменшити ризики, скануючи код, згенерований штучним інтелектом, перевіряючи залежності, виявляючи секрети, забезпечуючи дотримання CI/CD guardrails, моніторинг поведінки агентів та співвіднесення результатів через ASPM.
Чи безпечний код, згенерований штучним інтелектом?
Код, згенерований штучним інтелектом, не є безпечним за замовчуванням. Його слід перевірити, відсканувати, протестувати та перевірити, перш ніж він потрапить у виробництво.
Заключні думки: Ризики безпеки ШІ потребують SDLC-Контролі рівня
Штучний інтелект змінює швидкість та форму програмних ризиків. Він допомагає командам швидше будувати, але також відкриває нові шляхи для небезпечного коду, розкритих секретів, небезпечних залежностей та ризикованої автоматизації, що потрапляють у ланцюжок доставки.
Таким чином, безпеку штучного інтелекту не можна вирішити лише за допомогою моделей управління або документів політики. Вона потребує практичних заходів контролю всередині SDLCзворотний зв'язок IDE, SAST, SCA, виявлення секретів, CI/CD guardrails, виявлення аномалій та ASPM-рівнева кореляція.
Команди, які добре керують ризиками безпеки, пов'язаними зі штучним інтелектом, не будуть тими, хто блокуватиме впровадження ШІ. Вони будуть тими, хто створить навколо нього правильний рівень безпеки.
