В това интервю за Help Net Security д-р Джошин Лий, главен изпълнителен директор на Zentera Systems, обсъжда къде се появяват рисковете във веригата за доставки на изкуствен интелект (AI). Той споделя, че повечето инциденти все още засягат работните процеси на разработчиците и хранилищата с отворен код, докато компрометираните тегла на модели и компрометираните MCP сървъри остават главно в сферата на изследователските демонстрации.

Той обяснява защо сегментирането осигурява по-голямо намаляване на риска за инвестиран долар в сравнение с инструментите за сигурност, кои са недостатъците на самостоятелното хостване на модел и кои практики за изолиране от полупроводниковата индустрия трябва да взаимстват софтуерните екипи. Той също така посочва вярване в сигурността, което оттогава е изоставил.

В момента по-голямата част от активните инциденти във веригата за доставки засягат основните работни процеси на разработчиците и публичните хранилища за пакети с отворен код. Екзотичните повърхности за атака като манипулирани тегла на модели, компрометирани векторни бази данни и компрометирани MCP сървъри са реални структурни заплахи, но днес те съществуват предимно в изследванията за сигурност и демонстрациите по конференции.

Въпреки това, допускането, че тези нововъзникващи вектори ще останат само на теория, е опасно. Нужна е само една открита кампания в реална среда, за да може заплаха от тип доказателство за концепция (PoC) да се превърне в новина от първа страница за една нощ.

Вече виждаме специфични за AI атаки срещу веригата за доставки, насочени директно към разработчиците. Водещ пример е активната кампания „Phantom Raven“. Атакуващите наблюдават как инструментите за генериращ изкуствен интелект халюцинират несъществуващи имена на софтуерни пакети по време на сесии за бързо писане на код (т.нар. „vibe coding“). След това нападателите умишлено регистрират тези халюцинирани имена на пакети в публични хранилища, зареждайки ги със зловреден код. Когато ненаблюдаван скрипт на разработчик или AI агент автоматично изтегли препоръчаната зависимост, той тихо инсталира зловреден софтуер в тръбопровода за изграждане на софтуера (build pipeline).

Следете теглата на моделите и MCP сървърите, но имайте предвид, че в момента атакуващите използват изкуствен интелект, за да експлоатират обикновеното човешко доверие и навиците за управление на софтуерни пакети.

Сегментирането на средата осигурява значително по-голямо намаляване на риска за всеки инвестиран долар. Сегментирането предоставя структурен слой за ограничаване срещу „непознатите непознати“. Няма значение какъв нов AI инструмент стартира разработчикът или каква нова уязвимост използва даден агент. Ако околната мрежа пречи на тази машина или процес да достигне до съседни корпоративни активи, щетите са строго ограничени.

Въпреки това оперативната реалност често налага различен приоритет. Правилното сегментиране на средата изисква съзнателно архитектурно планиране и съгласуване между различните отдели, което отнема време. Ако вашата организация управлява AI-нативен тръбопровод за разработка или е изправена пред непосредствен натиск от одити за съответствие и управление на риска (GRC), ръководството може първо да изиска специализирани инструменти за контрол на AI сесиите и видимост.

Това, което фундаментално би променило отговора ми, е чувствителността на данните. Ако вашата среда борави с изключително чувствителна интелектуална собственост, финансови записи с висока стойност или строго регулирани данни, които никога не трябва да напускат пределите ѝ, трябва да приоритезирате сегментирането на средата на първо място. Не можете да разчитате единствено на инструменти за мониторинг, когато едно изтичане на данни представлява катастрофално нарушение на съответствието.

Самостоятелното хостване на модел е чудесна стъпка за предотвратяване на предаването на данни към външни SaaS доставчици, но е фалшиво успокоение, ако си мислите, че това решава проблема ви със сигурността. Самостоятелното хостване не елиминира риска. Вместо това то просто прехвърля цялата тази оперативна отговорност върху вашия вътрешен екип.

Това схващане се проваля, тъй като хостването на модела локално с нищо не контролира какво локалният AI агент може да прави в мрежата ви или в отворения интернет. Агент, взаимодействащ със самостоятелно хостван модел, все още може да изпълнява зловредни локални команди, да изтегля непроверени външни зависимости или да източва идентификационни данни, ако в неговата среда за изпълнение липсват граници.

Освен това самостоятелното хостване вдига летвата за оперативна поддръжка. Вашият екип вече е изцяло отговорен за отстраняване на уязвимости в инфраструктурата на модела, мониторинг за злоупотреби и извършване на симулации на атаки (red-teaming) – задачи, които иначе търговските облачни доставчици управляват вместо вас. Ако хоствате модел самостоятелно, без да наложите строга локална изолирана среда около агента, излагането на веригата ви за доставки остава идентично с това при използване на публичен API.

Софтуерните компании трябва незабавно да възприемат подхода на полупроводниковата индустрия за анклави на ниво проект и разделяне на камери („chambering“). При проектирането на чипове екипите изолират работните натоварвания на конкретни проекти в софтуерно дефинирани анклави, налагайки строг контрол на изходящия трафик, изрична оторизация и цялостно регистриране на сесиите. Прилагането на същите концепции в софтуерната разработка може да ви помогне да се уверите, че AI агент или разработчик, работещ по Проект А, никога не може да достигне, прегледа или компрометира поверителните хранилища с код на Проект Б.

Това, което софтуерните компании не трябва да копират, е традиционният навик в полупроводниковата индустрия за изграждане на физически разделени хардуерни мрежи без достъп до интернет за всяка група за разработка. Изграждането на отделни физически мрежи за всеки екип или клиентски проект е изключително скъпо, оперативно негъвкаво и напълно излишно за съвременните облачни работни процеси.

Вместо физическо изолиране...