Атаки на ланцюг поставок: ризики від довіреного ПЗ

Чим відрізняються атаки на ланцюг поставок

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

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

Резонансні приклади

SolarWinds Orion (2020)

APT29 (угруповання, яке фінансується російською державою) скомпрометувало систему збірки SolarWinds — широко використовуваної платформи для моніторингу ІТ. Зловмисники впровадили бекдор — названий SUNBURST — у легітимне оновлення програмного забезпечення SolarWinds Orion. Приблизно 18 000 організацій встановили це трояновано оновлення, зокрема Міністерство фінансів США, Міністерство внутрішньої безпеки та великі підрядники оборонної галузі. Бекдор залишався бездіяльним протягом двох тижнів після встановлення перед активацією, уникаючи виявлення на основі поведінки.

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

Бекдор XZ Utils (2024)

Загрозливий актор витратив майже два роки на терпляче напрацювання довіри у проекті з відкритим кодом XZ Utils під фіктивною особистістю, поступово перебравши обов'язки мейнтейнера. Після цього він впровадив складний бекдор, що цілився в SSH-демони, пов'язані з systemd, на системах Linux. Бекдор виявив інженер Microsoft, який помітив незвичне навантаження на CPU під час SSH-входів — лише за кілька днів до того, як скомпрометована версія мала потрапити до основних репозиторіїв дистрибутивів.

Цей випадок продемонстрував витонченість тривалої соціальної інженерії, спрямованої проти мейнтейнерів відкритого коду.

Отруєння пакетів npm

Екосистема JavaScript вже пережила кілька інцидентів із ланцюгом поставок:

• event-stream (2018): новий мейнтейнер додав навантаження для майнінгу криптовалюти, спрямоване проти конкретного Bitcoin-гаманця
• node-ipc (2022): мейнтейнер навмисно вставив деструктивний код, що цілився в IP-адреси Росії та Білорусі
• Тайпсквотинг: пакети з назвами lodahs, crossenv або momnet для перехоплення помилково введених команд npm install

Реєстр npm містить понад два мільйони пакетів, а дерева залежностей зазвичай налічують сотні пакетів — більшість із яких ваша команда ніколи не перевіряла.

Вектори атак у ланцюгу поставок програмного забезпечення

Атаки на ланцюг поставок проникають через кілька каналів:

• Скомпрометовані системи збірки: впровадження шкідливого коду під час компіляції (як у SolarWinds)
• Підміна залежностей: завантаження шкідливого публічного пакета з тією ж назвою, що й приватний внутрішній пакет, використовуючи порядок розв'язання пакетних менеджерів
• Тайпсквотинг: реєстрація пакетів із назвами, схожими на популярні бібліотеки
• Захоплення облікового запису: злам облікового запису мейнтейнера пакета для публікації шкідливого оновлення
• Компрометація конвеєра CI/CD: впровадження шкідливих кроків у конвеєри збірки, які мають широкий доступ до виробничих систем
• Скомпрометоване апаратне забезпечення: імпланти, додані під час виробництва (актуально для прошивок і мережевого обладнання)

Захист: управління залежностями

Фіксуйте версії залежностей — не використовуйте плаваючі діапазони версій (^1.2.3 або latest). Lock-файли (package-lock.json, Cargo.lock, requirements.txt із хешами) гарантують встановлення саме того, що ви тестували. Перевіряйте цілісність за допомогою контрольних сум:

# npm — перевірка відповідно до lock-файлу
npm ci

# pip — вимога перевірки хешів
pip install --require-hashes -r requirements.txt

Регулярно перевіряйте залежності: npm audit, pip-audit, cargo audit, trivy для контейнерів. Підписуйтесь на сповіщення безпеки для ключових залежностей через GitHub Dependabot або OSV.dev.

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

Захист: безпека конвеєра збірки

• Використовуйте відтворювані збірки — однаковий вихідний код повинен завжди давати побайтно ідентичний результат, що робить несанкціоновані модифікації виявними
• Підписуйте артефакти релізу та перевіряйте підписи перед розгортанням: використовуйте Sigstore/cosign для контейнерів і бінарних файлів
• Дотримуйтеся принципу найменших привілеїв у CI/CD: завдання збірки повинні мати доступ лише до необхідного; секрети мають бути обмежені конкретними конвеєрами та середовищами
• Впроваджуйте SLSA (Supply Chain Levels for Software Artifacts) — фреймворк, який забезпечує верифіковану провенієнцію артефактів збірки
• Перевіряйте робочі процеси GitHub Actions та сторонні дії — прив'язуйте дії до конкретних SHA комітів, а не до змінних назв гілок або тегів

Захист: ризики постачальників і відкритого коду

• Ведіть Специфікацію програмного забезпечення (SBOM) — повний перелік усіх компонентів програмного забезпечення та їх версій. Інструменти на кшталт Syft і CycloneDX можуть автоматично генерувати SBOM.
• Перед прийняттям критично важливої бібліотеки з відкритим кодом перевіряйте активність її мейнтейнерів, модель управління та чи були у неї минулі інциденти безпеки
• Для критичних залежностей розгляньте вендоринг — копіювання вихідного коду у власний репозиторій — щоб запобігти автоматичному впливу змін вище за потоком
• Впровадьте контроль мережевого вихідного трафіку у вашому середовищі збірки, щоб запобігти крадіжці секретів шкідливими пакетами під час збірки