AI-асистенти для написання коду інтегрують відкриті пакети, бібліотеки та контейнерні образи в корпоративні кодові бази швидше, ніж команди безпеки встигають їх перевіряти. Наслідком цього стає розростання залежностей, що розширює поверхню атаки для компрометації ланцюжка постачання програмного забезпечення. Шкідливі пакети, бібліотеки з помилковими назвами (typosquatting) та скомпрометовані транзитивні залежності потрапляють через єдиний автоматизований конвеєр.
Раніше програмні компоненти відображали свідомі людські рішення, коли інженер обирав бібліотеку, з якою вже працював і міг обґрунтувати її використання під час перевірки. Механізм затвердження, побудований на цьому припущенні, працює за циклами перевірки, виміряними днями. Це означає, що підприємства стикаються з надмірним розривом між швидкістю надходження програмного забезпечення та оперативністю й ретельністю його верифікації.
«Швидкість випереджає управління та контроль», — зазначає головний спеціаліст із інформаційної безпеки Chainguard Квінсі Кастро. «Коли код можна генерувати миттєво, традиційний цикл запиту, перевірки та затвердження стає вузьким місцем. Ніхто не захоче працювати у світі, де робота виконується дуже швидко, а потім усе це блокується застарілим, ручним процесом, керованим людиною».
Це означає, що змінилися дві речі. Агенти вибирають залежності на основі їхньої релевантності до запиту, що може мало стосуватися того, наскільки добре ця залежність підтримується. Водночас програми для citizen developer передають складання програмного забезпечення в руки людей без традиційної підготовки в розробці програмного забезпечення, що ускладнює технічну валідацію.
Чому команди безпеки ніколи повністю не перевіряли залежності з відкритим кодом
Однак, за словами Кастро, штучний інтелект не зруйнував функціональний процес перевірки. За час роботи на чотирьох різних посадах CISO він спостерігав, як команди розробників долали шлях від ідеї до мінімально життєздатного продукту (MVP), і лише потім зверталися до служби безпеки для фінального затвердження — процес, який, на його думку, є нестійким.
«Ідея про те, що невелика команда безпеки може бути спеціалістом у кожному технологічному стеку організації зі списку Fortune 500 і може дати дозвіл чи заборону на випуск продукту, є сміховинною», — пояснює він. «Я сумніваюся, що більшість команд безпеки коли-небудь ефективно перевіряли та валідували програмні компоненти, які використовують розробники. Ось чому ланцюжок постачання програмного забезпечення став такою привабливою ціллю. Якщо раніше ми робили це погано, то додавання швидкості та масштабу агентської розробки лише погіршує ситуацію».
Запобіжники існують сьогодні, тому що організації вже мусили припускати, що індивідуальне судження може або не буде помилковим. Але агентська розробка стирає паузу в процесі розробки, де ці запобіжники традиційно спрацьовували.
Зловмисники націлюються на пакети з відкритим кодом із довгого хвоста
Зловмисники схильні обирати менш відомі проєкти, оскільки популярні приваблюють найбільше розробників, більше контриб’юторів, які перевіряють зміни, та більше автоматизованого контролю, що робить їх дорогими цілями.
«Просунути шкідливе програмне забезпечення у відкритий, публічно видимий репозиторій популярного проєкту з відкритим кодом, ймовірно, не призведе до успіху, якщо вони не будуть надзвичайно непомітними», — каже Кастро. «Тому вони обирають менш підтримувані проєкти, а потім знаходять способи заохотити розробників до цих проєктів, щоб отримати максимальне поширення своєї операції».
Кастро вказує на нещодавню атаку, під час якої було масово створено форки легітимних проєктів, до них було додано шкідливе програмне забезпечення, і вони були розкидані настільки широко, що розробники могли помилково прийняти форк за офіційний репозиторій і завантажити можливості зловмисника у свій CI/CD пайплайн. Але це не означає, що популярні проєкти не є цілями: у березні зловмисники, які захопили GitHub Actions сканера Trivy, примусово завантажили 75 з 76 версійних тегів до комітів, що містили інфостилер. Потім вони використали зібрані секрети для публікації шкідливих npm-пакетів.
Зловмисники також все частіше використовують typosquatting, захоплення облікових записів розробників, отруєні точки розповсюдження та залежності від сторонніх програм. Кастро стверджує, що довіра, яку експлуатують ці методи, ніколи не була виправданою, враховуючи, що будь-хто може писати та публікувати код з відкритим кодом.
«Ви б ніколи не підняли USB-флешку на парковці та не вставили її у свій ноутбук, або не взяли б бутерброд, що лежить на стовпі», — каже він. «Ви не думаєте: „безкоштовний бутерброд, дай-но я його з’їм“. Ви хочете спочатку оглянути його та зрозуміти, свіжий він, безпечний, чому він безкоштовний».
96% CVE містяться поза топ-20 контейнерних образів
Звіт Chainguard «State of Trusted Open Source» за березень 2026 року показав, що 96,2% загальних вразливостей та експлойтів (CVE) містяться поза топ-20 контейнерних образів, а в червневому випуску ця цифра зросла до 97%. Корпоративні програми зміцнення безпеки зосереджуються на невеликій кількості образів, на які припадає решта.
«Концентрація ризику обернена до того, куди спрямована більшість уваги підприємств», — зазначає Кастро. «Організації вкладають багато ресурсів у зміцнення безпеки невеликої кількості відомих, широко використовуваних образів, тоді як фактичний ризик криється в довгому хвості».
Транзитивні залежності створюють сліпі плями в ланцюжку постачання
Завантаження пакета означає успадкування всього, від чого залежать його автори, і того, від чого залежать ці залежності. Видимість зникає на два-три рівні вниз, що робить шкідливий код на такій глибині значно важчим для виявлення.
«У нас були спрацьовування щодо залежності зі шкідливим програмним забезпеченням, і ми виявляли, що вона не є частиною контейнерного образу, або її немає в специфікації матеріалів», — каже Кастро. «Потім ми відмотуємо стрічку назад і бачимо, що це була залежність від транзитивної залежності, яка короткочасно виконувалася під час збірки. Чи це було реально? Так. Чи мав би звичайна людина, яка збирає це, будь-яке уявлення про ризик? Абсолютно ні».
Забезпечення безпечних транзитивних залежностей — це одна з проблем, з якими стикаються DIY-ентузіасти, коли намагаються створити власні системи для забезпечення безпеки ланцюжка постачання програмного забезпечення. Команди, безумовно, можуть це зробити за достатніх інвестицій, але складність масштабування стає очевидною лише тоді, коли вони починають збирати системи, необхідні для виробництва безпечних, надійних пакетів з відкритим кодом.
Сканування вразливостей не може масштабуватися з кодом, згенерованим ШІ
«Робити більше того ж, що традиційно не працювало добре, з набагато вищою швидкістю та масштабом, означає, що ви зазнали невдачі ще до початку», — говорить Кастро. «Компанії вже мають труднощі з виправленням серйозних вразливостей, не кажучи вже про всі середні та високі, ризик яких вони регулярно приймають. Більше сканування та більше виправлень не витримають геометрично більшого обсягу коду, розробленого агентами».
Міжмережеві екрани для розробників і політики, що блокують збірку, мають ту саму обмеженість. Вони перехоплюють проблему на пізньому етапі, близько до інженера та близько до продакшну, перетворюючи помилку джерела на чергу заблокованих запитів на злиття (pull requests).
«Інженерам доводиться мати справу з безліччю невдалих збірок, тоді як вони хочуть випускати продукти, які подобаються людям, а не діагностувати, чому сканер каже, що вони не можуть надіслати свій PR», — каже Кастро.
Безпечні за замовчуванням відкриті вихідні коди та перевірене походження
Якщо сканування та виправлення виходять з ладу в масштабі, альтернатива полягає в тому, щоб запобігти потраплянню вразливостей до сканера, використовуючи компоненти з відкритим кодом, які постачаються перебудованими з атестатами походження, мінімальною поверхнею атаки та безперервною підтримкою. Переважна модель схожа на автомобіль, єдиною функцією безпеки якого є подушки безпеки: корисні в найгіршому сценарії, але не замінюють фари, антиблокувальне гальмо та систему контролю тяги. Перевірені, безпечні за замовчуванням компоненти покликані бути цими запобіжними шарами, зменшуючи навантаження вразливостей ще до того, як спрацює будь-який запобіжник. Але жодна модель запобігання не може покладатися на те, щоб спрямовувати кожну команду до найкраще підтримуваних пакетів. А фінансовий аналітик, який створює внутрішній інструмент у IDE за підтримки ШІ, не має команди SRE або персоналу з безпеки додатків, який би перевіряв його вивід.
«Завжди є якийсь дивний граничний випадок або виняток. Завжди є система, яку не можна належним чином оновити, завжди є додаток, який вимагає чогось незвичайного, що підтримується однією людиною», — каже Кастро. «Ідея про те, що ми можемо спрямувати всіх до найпопулярніших речей, чудова на словах, але дуже складна на практиці. Для мене це свідчить про необхідність переходу до компонентів і систем, які систематично захищені за замовчуванням, замість того, щоб дозволяти людям робити будь-що, а потім намагатися вирішити це безпосередньо перед відправкою у продакшн».
Інформація підготовлена на основі матеріалів: venturebeat.com