От Джони Ривера, ръководител на продуктовия отдел в ActiveState

По време на разговорите ни на изложението Black Hat миналата седмица, един въпрос възникваше в почти всяка дискусия, която нашият екип проведе с ръководителите на AppSec, платформените инженери и CISO: Кой всъщност проверява кода на изкуствения интелект (ИИ)?

Приемането на ИИ инструменти за програмиране от разработчиците не се забавя. Ползите за продуктивността са реални, а софтуерът с отворен код остава гръбнакът на съвременните корпоративни приложения. Но тъй като ИИ асистентите за кодиране автоматично довършват предложенията за зависимости от трети страни за милисекунди, екипите за корпоративна сигурност и поддръжниците на проекти с отворен код са изправени пред общо оперативно предизвизвикателство: генерирането на код напълно изпревари наследения преглед при внедряване.

Когато непроверена или халюцинирана зависимост влезе в кодовата база с машинна скорост, сканирането за анализ на софтуерния състав (SCA) след комит (post-commit) трудно успява да поддържа темпото.

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

Механиката на „slopsquatting“ и машинното внедряване

Големите езикови модели (LLM) препоръчват софтуерни библиотеки въз основа на статистическа вероятност и исторически модели на код, а не на база проверка на регистъра на пакетите в реално време.

Когато даден модел предложи име на пакет, което не съществува в PyPI или npm, това създава уязвимост във веригата за доставки, известна като „slopsquatting“ (или експлоатация на халюцинации на пакети от ИИ).

Мащабът на този вектор на уязвимост беше подчертан в проучване на USENIX Security, анализиращо шестнадесет популярни модела за генериране на код върху над 500 000 кодови проби:

  • Измерим процент от предложените от ИИ имена на пакети не съществуват в публичните регистри.
  • От предложените зависимости, които съответстват на реални пакети, почти половината съдържат известни CVE уязвимости или остарели версии.

Атакуващите редовно наблюдават изходните модели на публичните LLM и кодовите хранилища на разработчиците, за да идентифицират тези халюцинирани имена на пакети. След като ги идентифицира, даден киберпрестъпник регистрира фиктивното име в PyPI или npm, качва злонамерен код и чака автоматизираните среди за разработка или CI/CD системи за компилация да го изтеглят.

Този вектор се наблюдава активно при реални атаки. В началото на 2026 г. изследователи по сигурността проследиха едно халюцинирано име на npm пакет (react-codeshift), произлизащо от 47 генерирани от ИИ умения на агенти в един комит.

Халюцинацията се разпространи органично чрез разклонения (forks) в над 230 хранилища, преди инженер да забележи, че човек никога не го е избирал изрично.

Проблемът не беше в злонамерено намерение от страна на разработчика, а по-скоро в пълната липса на контрол при внедряването.

Спрете халюцинациите на пакети от ИИ, преди да стигнат до вашата компилация

ИИ асистентите за кодиране генерират софтуер с машинна скорост, но непроверените зависимости излагат вашия конвейер на slopsquatting и атаки срещу веригата за доставки.

Задвижван от сигурно хранилище от чисти компоненти, компилирани от изходния код, ActiveState позволява на организациите да докажат произхода на софтуера и да осигурят удостоверяване на ниво компилация, като същевременно елиминират векторите на slopsquatting още на стъпката на приемане.

Увеличеното триене при прегледа на отворения код

Предизвикателството с приемането в рамките на предприятието влияе пряко върху по-широката екосистема с отворен код. Същите ИИ асистенти, които генерират предложения за непроверени зависимости в корпоративните мрежи, генерират и автоматизирани заявки за сливане (pull requests), изпращани към хранилища, поддържани от общността.

Този обем от автоматизирани приноси оказва безпрецедентен натиск върху хората поддръжници:

  • Противоречиви политики за ИИ: Големи проекти, включително Kubernetes, ядрото на Linux, LLVM и Godot, публикуваха различни политики относно приносите, подпомагани от ИИ. Докато някои забраняват изцяло генерирания от ИИ код, други го разрешават само ако човек поеме пълна отговорност за всеки добавен ред.
  • По-висока плътност на дефектите: Преглед на CodeRabbit на 470 заявки за сливане с отворен код установи, че приносите, съавторствани от ИИ, съдържат 70% повече дефекти в сравнение с кода, написан от хора, въпреки че на пръв поглед изглеждат чисти.

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

Скорост срещу проверка: Пропастта в управлението

Последните телеметрични данни от Applicat на Kusari...