
Зловмисники все частіше спрямовують свої атаки на системи, які створюють і розповсюджують програмний код, а не на самі програми. Конвеєри CI/CD, репозиторії пакунків (зокрема npm та PyPI), робочі процеси GitHub Actions та інструменти для ШІ-агентів тепер пов’язані між собою, привертаючи увагу, яка раніше була спрямована на виробниче програмне забезпечення. Щотижня стаються випадки захоплення популярних пакетів з відкритим кодом, і один такий компроміс може вразити десятки тисяч організацій нижче за ланцюжком постачання.
Атаки на ланцюжок постачання програмного забезпечення почали прискорюватися на початку 2026 року, зазначає Квінсі Кастро, головний директор з інформаційної безпеки (CISO) компанії Chainguard.
«Раніше атаки на ланцюжок постачання вважалися рідкісними та екзотичними, зазвичай дуже навмисними та методичними, і захисники розглядали їх переважно як техніку державних суб’єктів для проникнення у важкодоступні місця», — каже Кастро. «Те, що ми бачили цього року, — це мотивовані прибутком зловмисники, які усвідомили, що розробка програмного забезпечення є найслабшим місцем організацій. Оскільки ми стали краще захищати традиційні кінцеві точки та хмарні середовища, ми природно витіснили зловмисників у набагато менш захищену сферу».
Атаки на ланцюжок постачання програмного забезпечення нагадують кампанії «watering hole» попереднього десятиліття, коли зловмисники компрометували вебсайти, щоб експлуатувати неуважних відвідувачів. Ця динаміка «один до багатьох» також грає на користь зловмисникам в атаках на ланцюжок постачання: компрометація одного проєкту з відкритим кодом дає зловмисникам потенційну можливість скомпрометувати кожен проєкт, що його встановлює, знижуючи граничну вартість кожного додаткового жертви майже до нуля, одночасно дозволяючи оператору обирати, які скомпрометовані середовища переслідувати.
Конвеєри CI/CD та сервери збирання не захищені
Конвеєри розробки працюють за розкладом, і перевірки безпеки зосереджені на коді, що проходить через них, а не на механізмах, які його переміщують. Білд-раннер містить облікові дані репозиторію, ключі підпису та токени хмарних сервісів, одночасно виконуючи скрипти встановлення з кожної залежності, яку він розв’язує. Він також може посилатися на сторонні дії за змінними тегами, які власник вищого рівня може перенаправити на будь-який коміт. Це означає, що конвеєр, який проходить усі перевірки коду, все ще може передати зловмиснику облікові дані для підпису та публікації релізу.
«Ви можете мати конвеєр, де ви думаєте: “Я чудово справляюся з безпекою: я сканую свій код, я блокую критичні помилки від проходження перевірок CI” і так далі», — каже Кастро. «Потім ви збільшуєте масштаб, і ця система збирання знаходиться в публічному інтернеті, тому що команда розробників розподілена по всьому світу, і ви дозволили їм помістити довготривалі персональні токени доступу у свої скрипти збирання. Це не безпечна система».
Команди виявлення та реагування посилюють прогалину, оскільки їх телеметрія охоплює кінцеві точки, системи ідентифікації та виробничу інфраструктуру, тоді як інженерія керує серверами збирання, репозиторіями артефактів та раннерами. Вони можуть взагалі не моніторитися, або, якщо моніторитися, захисникам часто незрозуміло, яка поведінка вказує на справжнє вторгнення порівняно з інженерною роботою.
«Якщо подивитися на більшість традиційних команд безпеки, вони зазвичай мають мало або зовсім не мають людей з реальним досвідом DevOps або SRE», — додає Кастро. «Їм часто доводиться моніторити та захищати системи, якими вони ніколи не користувалися і не розуміють, і вони не мають довіри своїх інженерних колег, які бояться, що команда безпеки щось зламає».
Розмір ускладнює стандартизацію, особливо в компаніях, які зростали шляхом поглинань і отримували новий набір інструментів з кожною угодою. Кастро, який раніше обіймав посади CISO у двох великих багатонаціональних фірмах, зазначає, що розробники в компаніях будь-якого розміру перебувають під постійним тиском швидкого випуску продукції, і не всі з них мають необхідну підтримку чи експертизу для безпечної роботи.
«Розробники повинні робити те, що вони можуть, щоб полегшити собі роботу», — каже Кастро. «Якщо їм потрібна певна дія GitHub, вони візьмуть її та запустять, і вони повинні припустити, що їхня команда безпеки робить усе можливе, щоб їх захистити, хоча в багатьох випадках насправді цього не відбувається за лаштунками».
AI-агенти для кодування та “громадянські” розробники розширюють поверхню атаки
Програми для “громадянських” розробників дозволяють аналітикам та менеджерам з операційної діяльності, які ніколи не писали виробничий код, створювати програмне забезпечення за допомогою агентних інструментів кодування, виводячи розробку програмного забезпечення за межі середовищ і процесів, які традиційно регулюються ІТ.
Значна частина цієї роботи виконується на ноутбуках і передбачає завантаження пакунків з відкритого інтернету без контрольних точок для впровадження засобів безпеки. Існуючі засоби безпеки, керовані ІТ-командою, більше не є достатніми, каже Кастро.
«Коли ми спілкувалися з людьми, які постраждали від напливу атак на ланцюжок постачання цього року, ми виявили, що часто єдиним засобом захисту, який вони мали, були традиційні засоби виявлення та реагування на кінцевих точках (EDR) та антивіруси», — пояснює він. «Команди з операційної безпеки в цих компаніях працювали до знемоги, реагуючи на сповіщення про те, що шкідливе програмне забезпечення або черв’як встановив себе, або вони постійно шукали у своїх середовищах, чи не постраждали їхні інженери. Це я, як CISO, кажу, але скільки б люди не використовували слова на кшталт “AI-native”, немає нічого “AI-native” в тому, щоб дозволяти будь-кому робити будь-що, а командам безпеки залишати розбиратися з наслідками».
Безпека ланцюжка постачання має передувати реагуванню на інциденти
Збиток від компрометації ланцюжка постачання може тривати довше, ніж реагування. Ці атаки часто збирають секрети з середовищ, яких вони досягають, надаючи зловмисникам облікові дані, які вони можуть використовувати ще довго після виявлення початкової компрометації.
У березні 2026 року під час атаки на Trivy, широко використовуваний сканер вразливостей з відкритим кодом, зловмисники викрали хмарні ключі, SSH-ключі, токени Kubernetes, паролі баз даних тощо, потенційно викривши понад 2500 організацій. Aqua Security обернула облікові дані після виявлення попереднього порушення, але стримування було неповним, залишивши зловмисникам доступ, який допоміг здійснити подальшу атаку на ланцюжок постачання.
«Людям потрібен радикально інший спосіб боротьби з безпекою ланцюжка постачання, зосереджений щонайменше на запобіганні, а не лише на виявленні та реагуванні», — каже Кастро. «Метою має бути запобігання потраплянню скомпрометованих пакетів у середовище з самого початку».
Походження переносить рішення вище за ланцюжком
«Ми вступаємо у світ необмеженого коду з відкритим кодом, і це не зникне», — каже Кастро. «Окремо, обсяг коду та збільшення “vibe coding” піддають агентів та менш кваліфікованих користувачів впливу зловмисних пакетів-двійників та атак типу typo-squatting».
Щоб відсортувати безпечне від небезпечного за такого обсягу, потрібні докази, прив’язані до артефакту. Це перетворює перевірене походження, підписані артефакти та довірені системи збирання на контроль, який конвеєр застосовує самостійно, зі швидкістю машини.
«Ви хочете перевірити, що те, що ви завантажуєте у свій конвеєр збирання, є саме тим, чим воно має бути — не просто вірити комусь на слово, а мати можливість криптографічно довести це», — каже він. «Ви також хочете знати, що воно було зібрано в безпечному середовищі і що нічого не було підсунуто в останній момент».
Середовище розробки стає засобом контролю безпеки
Chainguard будує свій бізнес на цій основі, безпечно отримуючи, аналізуючи, захищаючи та перебудовуючи пакети з відкритим кодом та контейнерні образи, а також надаючи їх із зазначенням походження, щоб клієнти вирішували питання довіри до розгортання. Це перекладає тягар на платформу та встановлює стелю для збитків, які можуть бути завдані стеком, що надається розробникам.
«Це означає, що інструменти налаштовані з репозиторіями артефактів, налаштовані з правильними інструментами CI/CD, із захищеними діями, захищеними раннерами, захищеними навичками та властиво навколо безпечними компонентами», — каже Кастро. «Зловмисник може зробити щось погане, але йому доведеться докласти набагато більше зусиль, і ви тим часом надасте багато переваг своїм захисникам».
Це також стосується місця виконання коду. Організація безпеки може надати моніторингове хмарне середовище з необхідними для розробників ресурсами, зберігаючи експериментальну роботу в межах простору, який компанія може спостерігати, а не на окремих ноутбуках поза її полем зору, що є перевагою для керівників безпеки, які намагаються підтримувати видимість у міру розширення розробки ШІ.
«Для тих CISO, які прагнуть виділитися та бути поміченими як такі, що розширюють можливості бізнесу, створення цього проактивно у партнерстві з інженерією та SRE є способом допомогти вашому бізнесу бути проактивним щодо безпеки ланцюжка постачання програмного забезпечення та додатків», — каже Кастро. «Це також спосіб, яким організації можуть сприяти інноваціям, цифровій трансформації та впровадженню ШІ без шкоди для контролю над ланцюжком постачання програмного забезпечення».
Оригінал статті: venturebeat.com
