Що таке supply chain security: як захищають програмні залежності

У 2020 році зловмисники впровадили шкідливий код у процес збірки популярного програмного продукту, і тисячі організацій, серед яких державні установи, встановили оновлення з бекдором як звичайний рутинний апдейт. Жодна з жертв не була зламана напряму — атака пройшла через довіреного постачальника. Саме з таких випадків починається розмова про supply chain security: безпеку всього шляху, яким програмний код потрапляє від розробника до кінцевого користувача.

Що таке supply chain security простими словами

Supply chain security — це сукупність практик, інструментів і правил, які захищають ланцюг постачання програмного забезпечення від навмисного впровадження шкідливого коду та від випадкового використання вразливих компонентів. Простими словами: коли програма складається з тисяч готових бібліотек, потрібно бути певним, що жодна з них не містить закладки, що її ніхто не підмінив по дорозі і що її автори не підхопили компрометацію власних систем.

Сучасний застосунок рідко пишуть з нуля. Типовий проєкт на JavaScript може прямо підключати кілька десятків пакетів, але разом із транзитивними залежностями — тими, що підтягуються автоматично, — їх кількість легко перевищує тисячу. Кожен такий пакет має свого автора, свій репозиторій, свої облікові записи й власні залежності. Зловмиснику достатньо скомпрометувати одну ланку, щоб потрапити до всіх, хто цю ланку використовує.

Термін прийшов із логістики: так само, як фізичний товар проходить через виробників, склади й перевізників, код проходить через системи контролю версій, CI/CD-конвеєри, реєстри пакетів і механізми оновлення. Supply chain security відповідає на запитання: чи можна довіряти кожному етапу цього шляху і як довести, що артефакт, який потрапив у продакшен, — саме той, що створили розробники.

Чому залежності стали головною поверхнею атаки

Атакувати добре захищену компанію напряму дорого й повільно. Набагато ефективніше вразити щось, чому вона вже довіряє. Програмні залежності ідеально підходять для цього з кількох причин.

• Довіра за замовчуванням. Менеджери пакетів встановлюють бібліотеки без будь-якої перевірки їхнього походження — досить правильної назви.
• Масштаб. Один популярний пакет із мільйонами завантажень перетворює одну компрометацію на масову атаку.
• Непомітність. Шкідливий код може активуватися лише за певних умов і місяцями залишатися непоміченим.
• Людський фактор. Мейнтейнери open source часто працюють безкоштовно, без команд безпеки й іноді втрачають пильність або передають права на проєкт стороннім.

Відомі інциденти це підтверджують. Подія із SolarWinds показала, як компрометація системи збірки дає доступ до клієнтів постачальника. Випадок із пакетом event-stream продемонстрував, як права на підтримку бібліотеки передали людині зі зловмисними намірами. Вразливість у бібліотеці Log4j у 2021 році виявила іншу проблему: багато організацій навіть не знали, що використовують цей компонент, і не могли швидко визначити масштаб ризику. Кожен із цих сценаріїв — різний, але всі вони стосуються довіри до ланцюга постачання.

Як працюють типові атаки на ланцюг постачання

Щоб будувати захист, потрібно розуміти, як виглядає загроза. Основних сценаріїв кілька, і реальні атаки нерідко їх поєднують.

Компрометація акаунта або репозиторію розробника

Зловмисник отримує доступ до облікового запису майнтейнера — через фішинг, витік пароля або крадіжку сесійного токена — і публікує нову версію пакета зі шкідливим кодом. Для світу це виглядає як звичайне оновлення від легітимного автора.

Підміна пакетів і dependency confusion

Менеджери пакетів можуть шукати залежність у кількох джерелах: спочатку у внутрішньому реєстрі компанії, потім у публічному. Якщо назва внутрішнього пакета випадково збігається з опублікованим у відкритому реєстрі, система може завантажити чужий пакет із вищим номером версії. Ця техніка відома як dependency confusion, і вона спрацьовувала проти великих технологічних компаній. Схожий прийом — typosquatting: публікація пакетів із назвами, що відрізняються однією літерою від популярних.

Компрометація конвеєра збірки

Найнебезпечніший сценарій: вихідний код чистий, але шкідливий код впроваджується під час збірки. Якщо зловмисник контролює CI/CD-сервер, токени деплою або кроки конвеєра, він може модифікувати артефакт так, що підсумковий бінарний файл не відповідатиме жодному коміту в репозиторії. Перевірка коду в такому разі нічого не покаже.

Вразливості в самих залежностях

Не кожен ризик — навмисна атака. Часто проблема в тому, що бібліотека містить відому вразливість, а команда не оновлює її роками або не знає про її присутність у проєкті. Транзитивні залежності особливо сліпа зона: їх ніхто не обирав свідомо, але саме вони становлять більшість коду.

Основні практики захисту: від SBOM до підпису артефактів

Повністю усунути ризик неможливо, але його можна звести до керованого рівня. Набір практик у зрілої організації зазвичай виглядає так. Впровадження таких практик потребує постійного відстеження нових технології та інновації.

Інвентаризація: SBOM

SBOM (Software Bill of Materials) — це структурований перелік усіх компонентів продукту: прямих і транзитивних залежностей, їхніх версій, ліцензій і походження. Без такого переліку організація не може швидко відповісти на просте запитання: чи використовуємо ми щойно розкритий вразливий компонент? Саме відсутність інвентаризації перетворила реакцію на Log4j у багатотижневий ручний пошук для багатьох команд. Стандарти на кшталт SPDX і CycloneDX описують формат такого переліку, а більшість сучасних інструментів генерують його автоматично під час збірки.

Сканування вразливостей і політики оновлення

Інструменти аналізу складу ПЗ (SCA) зіставляють залежності з базами відомих вразливостей, таких як NVD або OSV, і попереджають про небезпечні версії. Але сканування без процесу мало що дає: потрібні правила, які версії оновлювати негайно, які — у плановому порядку, і хто відповідає за рішення. Практичний орієнтир — критичність вразливості разом із фактичною експонованістю компонента, а не лише оцінка CVSS у вакуумі.

Підпис і атестація артефактів

Криптографічний підпис дозволяє перевірити, що артефакт створений очікуваною системою і не змінювався після збірки. Атестація походження (provenance) фіксує, з якого коміту, яким конвеєром і з якими параметрами зібрано реліз. Фреймворк SLSA формалізує рівні зрілості такого захисту — від базового відстеження джерел до ізольованих, відтворюваних збірок. Утиліти на кшталт sigstore спрощують підпис без ручного керування ключами. Детальніше про підхід до ланцюга довіри можна прочитати в документації SLSA.

Контроль джерел залежностей

Компанії знижують ризик dependency confusion, резервуючи внутрішні назви пакетів у публічних реєстрах, налаштовуючи проксі-репозиторії зі списками дозволених джерел і блокуючи пряме звернення конвеєрів до зовнішніх реєстрів. Додатково перевіряють метадані пакета: вік проєкту, кількість майнтейнерів, історію релізів, прив’язку до вихідного репозиторію. Свіжий пакет із одним анонімним автором, що імітує назву популярної бібліотеки, — очевидний сигнал тривоги.

Захист самого конвеєра

CI/CD-системи обробляють секрети й мають право публікувати артефакти, тож вони самі потребують захисту: мінімальні права токенів, короткоживучі облікові дані замість статичних ключів, ізоляція кроків збірки, обов’язковий код-рев’ю і двофакторна автентифікація для майнтейнерів. Ключова теза проста: джерело правди — підписаний процес збірки, а не окремий комп’ютер розробника.

Практичний чекліст для команди

Перехід на системний захист ланцюга постачання не вимагає робити все одночасно. Розумна послідовність виглядає приблизно так:

1. Скласти SBOM для ключових продуктів і налаштувати його автоматичне оновлення під час кожної збірки.
2. Увімкнути сканування залежностей у CI з блокуванням релізу за критичних вразливостей.
3. Зафіксувати версії залежностей через lock-файли та перевіряти цілісність за контрольними сумами.
4. Увімкнути двофакторну автентифікацію для всіх акаунтів із правами публікації пакетів і релізів.
5. Перевести релізи на підписані збірки з атестацією походження.
6. Налаштувати внутрішній проксі-репозиторій зі списком дозволених джерел.
7. Періодично переглядати, які залежності фактично використовуються, і видаляти зайві.

Навіть перші три кроки помітно змінюють ситуацію: команда починає бачити власний склад ПЗ і реагує на нові вразливості за години, а не тижні.

Поширені запитання про supply chain security

Чим supply chain security відрізняється від звичайної інформаційної безпеки? Класична безпека захищає власну інфраструктуру й код. Supply chain security фокусується на тому, що компанія не контролює напряму: сторонні бібліотеки, постачальники, сервіси збірки. Поверхня атаки тут — чужа довіра, а не лише власні помилки.

Чи вистачить антивіруса та файрвола? Ні. Шкідлива залежність потрапляє до системи легітимним шляхом — як оновлення, підписане довіреним автором. Потрібні контроль походження компонентів, інвентаризація й моніторинг поведінки.

Чи стосується це маленьких команд і стартапів? Так, бо інструменти ті самі: npm, PyPI, Docker-образи. Базовий рівень захисту — lock-файли, сканування залежностей і 2FA для публікації — доступний без додаткових витрат і закриває наймасовіші сценарії атак.

Що робити, якщо вразливу бібліотеку не можна швидко оновити? Варіанти: ізолювати компонент на мережевому рівні, застосувати тимчасовий патч або віртуальний патч на WAF, задокументувати ризик із дедлайном усунення. Головне — щоб рішення було усвідомленим, а не забутим.

Ключові висновки

Supply chain security — це не окремий продукт, який можна купити, а дисципліна: знати склад свого ПЗ, перевіряти походження кожного компонента, захищати конвеєр збірки і мати план реагування на компрометацію залежностей. Найдорожчі інциденти останніх років показали одну й ту саму закономірність: постраждали не ті, кого атакували, а ті, хто довіряв без перевірки. Почати варто з інвентаризації — без SBOM усі інші заходи працюють наосліп.