Рискове за сигурността на ИИ: Какво трябва да знаят екипите на DevSecOps, за да защитят ИИ системите
Рисковете за сигурността на изкуствения интелект вече не се ограничават до поведението на модела или поверителността на данните. Днес те влияят и на начина, по който се пише, преглежда, изгражда и доставя софтуер. С навлизането на инструменти за кодиране с изкуствен интелект, агентни системи с изкуствен интелект и работни процеси, задвижвани от изкуствен интелект. SDLC, екипите на DevSecOps са изправени пред нов вид риск: по-бърз код, по-бърза автоматизация и по-бързо допускане на грешки.
Това обаче не означава, че екипите трябва да забавят внедряването на ИИ. Вместо това, те се нуждаят от контроли за сигурност, които съответстват на скоростта на разработката, подпомагана от ИИ. В това ръководство обясняваме най-важните рискове за сигурността, свързани с ИИ, как те се проявяват в реални инженерни работни процеси и как екипите могат да намалят експозицията в код, зависимости, тайни, pipelineи агенти.
За по-широк преглед на това как изкуственият интелект променя пейзажа на заплахите, вижте нашето ръководство за Киберсигурност с изкуствен интелект.
Какви са рисковете за сигурността, свързани с изкуствения интелект?
Рисковете за сигурността на ИИ са слабости, заплахи или режими на отказ, които се появяват, когато изкуственият интелект се проектира, обучава, интегрира или използва в реални системи. Тези рискове могат да засегнат модели, данни, подкани, API, код, pipelineи инструментите, които ги свързват.
- Ръководство на NCSC относно изкуствения интелект и киберсигурността обяснява, че киберсигурността е основно изискване за безопасни и надеждни системи с изкуствен интелект. По подобен начин NIST AI Рамка за управление на риска предоставя на организациите структура за управление на риска, свързан с изкуствения интелект, чрез управление, измерване и практически контрол.
За екипите по DevSecOps проблемът е по-специфичен. Изкуственият интелект вече е част от веригата за доставка на софтуер. Той пише код, предлага зависимости, генерира конфигурация, извиква API и понякога действа автономно. В резултат на това рисковете за сигурността, свързани с изкуствения интелект, трябва да се обработват вътре в... SDLC, не само на моделния слой.
Защо рисковете за сигурността, свързани с изкуствения интелект, са различни сега
Традиционните рискове за киберсигурността обикновено идват от код, написан от хора, уязвими пакети, слаби идентификационни данни или неправилно конфигурирана инфраструктура. Тези рискове все още съществуват. Изкуственият интелект обаче променя колко бързо се появяват и колко трудно се откриват.
Генерираният от изкуствен интелект код може да изглежда правилен, но все пак да не преминава проверки за оторизация. Асистент по кодиране с изкуствен интелект може да предложи уязвим пакет. Агентски работен процес може да извика грешен инструмент, да осъществи достъп до грешен файл или да разкрие секретна информация в лог. Освен това, системите с изкуствен интелект често зависят от контекст, подкани, конектори и външни инструменти, което създава повече места, където сигурността може да се провали.
- OWASP Топ 10 за кандидатстване за LLM подчертава рискове като бързо инжектиране, разкриване на чувствителна информация, проблеми с веригата за доставки и прекомерна свобода на действие. Тези категории са полезни, защото свързват поведението на ИИ с реални проблеми със сигурността на приложенията.
С други думи, рисковете за сигурността на ИИ не са само за модела. Те са за цялата система около модела.
Основни рискове за сигурността на изкуствения интелект за екипите по DevSecOps
По-долу са изброени рисковете, които са най-важни, когато изкуственият интелект се използва в разработката, AppSec и... CI/CD работни потоци.
1. Уязвимости в код, генериран от изкуствен интелект
Инструментите за кодиране с изкуствен интелект могат да генерират код, който работи, но не е безопасен. Например, те могат да създават SQL заявки без правилна параметризация, да пропускат валидирането на входа или да внедряват слаба логика за удостоверяване.
Това се случва, защото много системи с изкуствен интелект генерират вероятни модели на код въз основа на данни за обучение. Вероятният код обаче не винаги е сигурен код. На практика моделът може да възпроизвежда несигурни примери, тъй като те са често срещани в публичните хранилища.
Типични примери са:
- SQL инжекция
- Скриптове на различни сайтове
- Липсващи проверки за оторизация
- Слабо управление на сесиите
- Небезопасна десериализация
- Липсва CSRF защита
Следователно, генерираният от изкуствен интелект код трябва да се третира като ненадежден, докато не премине проверката. SAST, проверки на правилата и преглед.
Предложение за вътрешна връзка: свържете този раздел с публикацията си на AI SAST.
2. Рискове, свързани с веригата на доставки и зависимостта
Инструментите с изкуствен интелект не само генерират код. Те също така предлагат пакети, версии, скриптове и команди за инсталиране. Това създава директен път от препоръките на изкуствен интелект до риска за веригата за доставки на софтуер.
Например, инструмент с изкуствен интелект може да предложи:
- Остарял пакет
- Печатно грешна зависимост
- Халюцинирано име на пакет
- Пакет със съмнителни инсталационни скриптове
- Библиотека, която е уязвима, но все още широко използвана
Освен това, нападателите могат да експлоатират това поведение, като регистрират имена на пакети, които инструментите с изкуствен интелект вероятно ще измислят. Този риск често се нарича „slopsquatting“ (небрежно представяне). Той превръща халюцинацията на модела в атака срещу веригата за доставки на пакети.
За да се намали този риск, екипите трябва SCA, откриване на зловреден софтуер, прилагане на политики за зависимости и анализ на достъпността. Те също трябва да използват сигнали за експлоатационност, като например ЕПС и активна експлоатационна разузнавателна информация от CISКаталог на известни експлоатирани уязвимости.
3. Разкриване на тайни в работните процеси с изкуствен интелект
Разкриването на тайни е един от най-практичните рискове за сигурността на ИИ. Разработчиците често поставят контекст в инструментите на ИИ. Този контекст може да включва API ключове, токени, идентификационни данни, URL адреси или вътрешна конфигурация.
Освен това, генерираният от изкуствен интелект код може да включва заместители, които изглеждат истински или, още по-лошо, да копират тайни обратно в изходните файлове, pipeline скриптове или лог файлове. След като тайните влязат в историята на Git или CI/CD трупи, те могат да останат годни за експлоатация дълго след първоначалното commit.
Често срещани точки на експозиция включват:
- История на бързите отговори
- Генериран код
- отивам commits
- CI/CD трупи
- IaC файлове
- Изображения на контейнери
- Споделени работни пространства
Поради тази причина екипите трябва да комбинират сканиране на ниво IDE, pre-commit проверки, сканиране на историята на хранилището, CI/CD сканиране на лог файлове и автоматично отменяне.
Предложение за вътрешна връзка: свържете този раздел с вашия продукт за сигурност на секретни данни или свързано съдържание.
4. Злоупотреба с AI агенти и инструменти
Agentic AI въвежда нов слой риск, защото агентите не само предлагат действия. Те могат да предприемат действия.
Агент с изкуствен интелект може да изпълнява команди от shell, да редактира файлове, да извиква API, да отваря pull requests, модифицират работни процеси в непрекъснатата интелигентност или взаимодействат с облачни услуги. Въпреки че това създава огромни печалби от производителността, то също така увеличава радиуса на взривяване на грешките.
Основните рискове включват:
- Небезопасно изпълнение на обвивката
- API ключове с прекалено много разрешения
- Неоторизирани промени в кода
- Неправилна конфигурация на MCP или API конектор
- Извиквания на инструменти извън одобрения обхват
- Достъп до средата извън изискванията на задачата
Категорията Топ 10 на OWASP LLM за прекомерна свобода на действие е особено важна тук. Ако даден агент има твърде голям достъп, лоша инструкция, незабавно внедряване или компрометиран инструмент могат да се превърнат в истинско събитие, свързано със сигурността.
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 проверки за сигурност и откриване на аномалии. |
| Runtime | Бързо инжектиране или изтичане на данни | Външният вход кара работния процес с изкуствен интелект да разкрива чувствителен контекст. | Бърз контрол, ограничения на достъпа и наблюдение. |
Рискове за сигурността, свързани с изкуствения интелект, спрямо традиционните рискове за киберсигурност
Традиционната киберсигурност все още е от значение. Изкуственият интелект обаче добавя нови модели на поведение, които изискват различни контроли.
| Район | Традиционен риск за киберсигурността | Риск за сигурността на изкуствения интелект |
|---|---|---|
| код | Уязвимости, написани от човек. | Генерирани от изкуствен интелект несигурни модели с по-висока скорост. |
| Зависимостите | Известни уязвими пакети. | Халюцинирани, злонамерени или опасни пакети, предложени от изкуствен интелект. |
| Тайните | Случайно получени идентификационни данни commitразработено от разработчиците. | Тайни, копирани в подкани, генериран код или регистрационни файлове. |
| Инструменти | Ръчна злоупотреба с инструменти за разработчици. | Автономни агенти, злоупотребяващи с инструменти или API. |
| Pipelines | Неправилно конфигуриран CI/CD работни потоци. | Промени в работния процес, генерирани от агенти, или опасна автоматизация. |
Примери за рискове за сигурността, свързани с изкуствен интелект в реалния свят
Рискът за сигурността на ИИ не е теоретичен. Няколко публични рамки и изследователски усилия сега проследяват тези проблеми по-формално.
- Хранилище за рискове, свързани с изкуствен интелект, на MIT каталогизира повече от 1,700 риска, свързани с изкуствен интелект, по различни причини и области. Междувременно OWASP предоставя практически категории за рискове, свързани с приложенията на LLM, включително незабавно внедряване, разкриване на чувствителна информация, уязвимости във веригата за доставки и прекомерна свобода на действие.
За екипите по DevSecOps, най-подходящите примери често се появяват в областта на доставката на софтуер:
- Инструменти с изкуствен интелект, предполагащи уязвим код
- Агенти с изкуствен интелект, променящи файлове на работния процес
- Генерирани от изкуствен интелект зависимости, въвеждащи експозиция на веригата за доставки
- Тайни, изтичащи чрез подкани, лог файлове или commits
- Работни процеси на агенти, извикващи инструменти извън одобрения обхват
Накратко, рисковете за сигурността на ИИ стават много по-сериозни, когато системите с ИИ могат да докосват код, идентификационни данни, пакети, 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 AI Рамка за управление на риска помага на организациите да картографират, измерват, управляват и управляват рисковете, свързани с изкуствения интелект. Полезен е за програми за лидерство, съответствие и управление на риска.
- OWASP Топ 10 за кандидатстване за LLM е по-практичен за екипите на AppSec, защото се свързва директно с технически рискове, като например бързо инжектиране, излагане на чувствителни данни, уязвимости във веригата за доставки и прекомерна свобода на действие.
- Ръководство за изкуствен интелект и киберсигурност на NCSC е полезно за лидери по сигурността, които трябва да разберат как изкуственият интелект променя организационния киберриск.
Заедно тези ресурси показват една ясна точка: сигурността на ИИ трябва да се управлява от хора, процеси, системи и работни процеси за доставка на софтуер.
Контролен списък: Как да намалим рисковете за сигурността, свързани с изкуствения интелект
Използвайте този контролен списък като практическа отправна точка.
| Контролна зона | Какво да правя | Защо има значение |
|---|---|---|
| Код, генериран от AI | бягане SAST в IDE, PR и CI/CD pipeline. | Предотвратява достигането на несигурен код до продуктивна среда. |
| Зависимостите | употреба SCA, откриване на зловреден софтуер, EPSS и достъпност. | Блокира рискови пакети, предложени от изкуствен интелект. |
| Тайните | Сканиране commits, логове, история, IaCи контейнери. | Намалява излагането на идентификационни данни и злоупотребата с тях. |
| CI/CD | Налагане pipeline guardrails и политически портали. | Спира опасни компилации и внедрявания. |
| Агентски инструменти | Следете извикванията на инструменти, достъпа до API и промените в работния процес. | Ограничава прекомерната свобода на действие и неочакваното поведение. |
| Управление на риска | употреба ASPM да се съпоставят откритията между слоевете. | Помага на екипите да се съсредоточат върху реалния бизнес риск. |
Ключови храни за вкъщи
- Рисковете за сигурността на ИИ вече засягат кода, зависимостите, тайните, pipelineи агенти.
- Традиционните инструменти на AppSec все още са необходими, но те трябва да се изпълняват по-рано и с повече контекст.
- Кодът, генериран от изкуствен интелект, трябва да се третира като ненадежден, докато не бъде валидиран.
- Необходими са работните процеси на AI агенти guardrails, разрешения и наблюдаемост.
- Екипите DevSecOps се нуждаят от унифицирана видимост в целия SDLC за ефективно управление на риска, свързан с изкуствения интелект.
ЧЗВ: Рискове за сигурността на ИИ
Какви са рисковете за сигурността на ИИ?
Рисковете за сигурността на ИИ са заплахи или слабости, които се появяват, когато системите с ИИ се изграждат, интегрират или използват. Те могат да засегнат модели, данни, подкани, код, зависимости, API и pipelines.
Кои са най-големите рискове за сигурността, свързани с изкуствения интелект, за екипите на DevSecOps?
Най-големите рискове включват несигурен код, генериран от изкуствен интелект, уязвими зависимости, разкриване на тайни, бързо инжектиране, прекомерни разрешения на агенти и опасни... CI/CD автоматизация.
Защо рисковете за сигурността, свързани с изкуствения интелект, се различават от традиционните рискове за киберсигурност?
Системите с изкуствен интелект могат да генерират код, да предлагат зависимости, да извикват инструменти и да действат автономно. В резултат на това рисковете се появяват по-бързо и на повече слоеве от SDLC.
Как екипите могат да намалят рисковете за сигурността на ИИ?
Екипите могат да намалят риска чрез сканиране на генериран от изкуствен интелект код, валидиране на зависимости, откриване на тайни, прилагане на... CI/CD guardrails, наблюдение на поведението на агентите и съпоставяне на резултатите чрез ASPM.
Безопасен ли е генерираният от изкуствен интелект код?
Генерираният от изкуствен интелект код не е безопасен по подразбиране. Той трябва да бъде прегледан, сканиран, тестван и валидиран, преди да достигне до производствена среда.
Заключителни мисли: Рисковете за сигурност, свързани с изкуствения интелект, са необходими SDLC-Контрол на нивото
Изкуственият интелект променя скоростта и формата на софтуерния риск. Той помага на екипите да изграждат по-бързо, но също така въвежда нови начини за навлизане на несигурен код, разкрити тайни, опасни зависимости и рискова автоматизация във веригата за доставка.
Следователно, сигурността на ИИ не може да се управлява само с моделно управление или документи с политики. Тя се нуждае от практически контрол вътре в SDLCобратна връзка от IDE, SAST, SCA, откриване на тайни, CI/CD guardrails, откриване на аномалии и ASPM-нивова корелация.
Екипите, които управляват добре рисковете за сигурността, свързани с изкуствения интелект, няма да бъдат тези, които ще блокират внедряването на изкуствения интелект. Те ще бъдат тези, които ще изградят правилния защитен слой около него.
