Модуль 4.4: Загрози ланцюга постачання
Складність:
[СЕРЕДНЯ]- Обізнаність щодо загрозЧас на виконання: 25-30 хвилин
Передумови: Модуль 4.3: Втеча з контейнера
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Визначити вектори атак ланцюга постачання: компрометовані базові образи, шкідливі залежності, підроблені конвеєри
- Оцінити механізми перевірки походження образів та підпису (cosign, Sigstore, SLSA)
- Оцінити безпеку конвеєра CI/CD на предмет точок ін’єкції та порушень меж довіри
- Пояснити як admission-контролери можуть забезпечувати підпис образів та обмеження реєстру
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Атаки на ланцюг постачання компрометують довірені компоненти до того, як вони потрапляють до вашого кластера. Шкідливий образ контейнера, компрометована залежність або підроблений конвеєр CI/CD може обійти всі засоби захисту часу виконання, оскільки атака вбудована в довірені артефакти.
KCSA перевіряє ваше розуміння ризиків ланцюга постачання програмного забезпечення та заходів їх зменшення.
Що таке атака на ланцюг постачання?
Розділ «Що таке атака на ланцюг постачання?»┌─────────────────────────────────────────────────────────────┐│ ВИЗНАЧЕННЯ АТАКИ НА ЛАНЦЮГ ПОСТАЧАННЯ │├─────────────────────────────────────────────────────────────┤│ ││ ЛЕГІТИМНИЙ ЛАНЦЮГ ПОСТАЧАННЯ: ││ Розробник → Код → Збірка → Образ → Реєстр → Кластер ││ ✓ ✓ ✓ ✓ ✓ ✓ ││ ││ АТАКА НА ЛАНЦЮГ ПОСТАЧАННЯ: ││ Будь-яка точка в ланцюгу може бути компрометована ││ ││ Розробник → Код → Збірка → Образ → Реєстр → Кластер ││ ✓ ✓ ✓ ✓ ✓ ✓ ││ ↑ ↑ ││ Шкідлива Підроблений ││ залежність образ ││ ││ ВПЛИВ: ││ • Шкідливий код виконується з повною довірою ││ • Обходить засоби захисту часу виконання ││ • Може зачепити багато кластерів/організацій ││ • Важко виявити ││ │└─────────────────────────────────────────────────────────────┘Вектори атак
Розділ «Вектори атак»1. Шкідливі базові образи
Розділ «1. Шкідливі базові образи»┌─────────────────────────────────────────────────────────────┐│ АТАКИ ЧЕРЕЗ БАЗОВІ ОБРАЗИ │├─────────────────────────────────────────────────────────────┤│ ││ ТАЙПОСКВОТИНГ ││ ├── Створення: ngimx/nginx (помилка в написанні) ││ ├── Користувач помиляється: завантажує шкідливий образ ││ └── Містить: Бекдор, криптомайнер тощо ││ ││ КОМПРОМЕТОВАНИЙ МЕЙНТЕЙНЕР ││ ├── Зловмисник отримує доступ до мейнтейнера образу ││ ├── Публікує шкідливе оновлення ││ └── Усі, хто завантажує :latest, отримують бекдор ││ ││ ПОКИНУТІ ОБРАЗИ ││ ├── Популярний образ перестає підтримуватися ││ ├── Вразливості накопичуються ││ └── Виправлення безпеки недоступні ││ ││ ЗАХОДИ ЗАХИСТУ: ││ • Використовувати лише офіційні/верифіковані образи ││ • Прив'язувати до дайджесту, а не до тегу ││ • Сканувати всі образи перед використанням ││ • Створювати власні базові образи ││ │└─────────────────────────────────────────────────────────────┘2. Компрометовані залежності
Розділ «2. Компрометовані залежності»┌─────────────────────────────────────────────────────────────┐│ АТАКИ ЧЕРЕЗ ЗАЛЕЖНОСТІ │├─────────────────────────────────────────────────────────────┤│ ││ ШКІДЛИВИЙ ПАКЕТ ││ ├── Зловмисник публікує пакет у npm/PyPI тощо ││ ├── Назва пакету схожа на популярну бібліотеку ││ ├── Розробник встановлює неправильний пакет ││ └── Шкідливий код виконується під час збірки або роботи ││ ││ ПЛУТАНИНА ЗАЛЕЖНОСТЕЙ ││ ├── Компанія має внутрішній пакет "auth-utils" ││ ├── Зловмисник публікує "auth-utils" у публічному реєстрі││ ├── Система збірки завантажує публічний (вища версія) ││ └── Встановлюється публічний шкідливий пакет ││ ││ КОМПРОМЕТОВАНИЙ МЕЙНТЕЙНЕР ││ ├── Зловмисник отримує доступ до мейнтейнера пакету ││ ├── Публікує шкідливу версію ││ └── Усі залежні проєкти зачеплені ││ ││ ПРИКЛАДИ: ││ • event-stream (npm) — крадіжка Bitcoin-гаманців ││ • ua-parser-js (npm) — впровадження криптомайнера ││ • Атаки тайпосквотингу на PyPI ││ │└─────────────────────────────────────────────────────────────┘3. Атаки на конвеєр CI/CD
Розділ «3. Атаки на конвеєр CI/CD»┌─────────────────────────────────────────────────────────────┐│ АТАКИ НА КОНВЕЄР CI/CD │├─────────────────────────────────────────────────────────────┤│ ││ ПОВЕРХНІ АТАК: ││ ││ Репозиторій вихідного коду ││ ├── Вкрадені облікові дані ││ ├── Компрометована робоча станція розробника ││ └── Пряме впровадження коду ││ ││ Система збірки ││ ├── Шкідливі скрипти збірки ││ ├── Компрометовані агенти збірки ││ └── Впровадження змінних середовища ││ ││ Сховище артефактів ││ ├── Крадіжка облікових даних реєстру ││ ├── Заміна образів ││ └── Перезапис тегів ││ ││ Розгортання ││ ├── Підробка маніфестів ││ ├── Впровадження секретів ││ └── Зміна конфігурації ││ ││ РЕАЛЬНІ ВИПАДКИ: SolarWinds (компрометація системи збірки)││ РЕАЛЬНІ ВИПАДКИ: Codecov (підробка bash-завантажувача) ││ │└─────────────────────────────────────────────────────────────┘4. Атаки на реєстр образів
Розділ «4. Атаки на реєстр образів»┌─────────────────────────────────────────────────────────────┐│ АТАКИ НА РЕЄСТР │├─────────────────────────────────────────────────────────────┤│ ││ ЗМІННІСТЬ ТЕГІВ ││ ├── Завантаження image:v1.0 у понеділок ││ ├── Зловмисник перезаписує image:v1.0 у вівторок ││ ├── Новий вузол завантажує image:v1.0 у середу ││ └── Запускається інший (шкідливий) образ ││ ││ КОМПРОМЕТАЦІЯ РЕЄСТРУ ││ ├── Зловмисник отримує доступ до реєстру ││ ├── Замінює образи версіями з бекдором ││ └── Усі кластери, що завантажують з реєстру, зачеплені ││ ││ АТАКА «ЛЮДИНА ПОСЕРЕДИНІ» ││ ├── Перехоплення трафіку до реєстру ││ ├── Надання шкідливого образу ││ └── Обходиться, якщо не використовується перевірка ││ дайджесту ││ ││ ЗАХОДИ ЗАХИСТУ: ││ • Незмінні теги ││ • Підписування образів ││ • Завантаження за дайджестом ││ • Приватні реєстри ││ │└─────────────────────────────────────────────────────────────┘Заходи безпеки ланцюга постачання
Розділ «Заходи безпеки ланцюга постачання»Підписування та верифікація образів
Розділ «Підписування та верифікація образів»┌─────────────────────────────────────────────────────────────┐│ ПІДПИСУВАННЯ ОБРАЗІВ │├─────────────────────────────────────────────────────────────┤│ ││ КОНЦЕПЦІЯ: ││ • Підписувати образи після збірки ││ • Перевіряти підпис перед розгортанням ││ • Відхиляти непідписані/неправильно підписані образи ││ ││ ІНСТРУМЕНТИ: ││ ├── Cosign (Sigstore) — Підписування без ключів ││ ├── Notary v2 — Довіра до контенту ││ └── Docker Content Trust (DCT) ││ ││ РОБОЧИЙ ПРОЦЕС COSIGN: ││ 1. Збірка образу ││ 2. Підпис: cosign sign --key cosign.key myimage:tag ││ 3. Завантаження підпису до реєстру ││ 4. Перевірка: cosign verify --key cosign.pub myimage:tag ││ ││ ПІДПИС БЕЗ КЛЮЧІВ (Sigstore): ││ • Використовує OIDC-ідентичність (GitHub, Google тощо) ││ • Без управління ключами ││ • Прозоро, з можливістю аудиту ││ │└─────────────────────────────────────────────────────────────┘Admission Control для образів
Розділ «Admission Control для образів»┌─────────────────────────────────────────────────────────────┐│ ADMISSION CONTROL ДЛЯ ОБРАЗІВ │├─────────────────────────────────────────────────────────────┤│ ││ ПРИМУСОВЕ ЗАСТОСУВАННЯ НА РІВНІ КЛАСТЕРА: ││ ││ 1. ДОЗВОЛЕНІ РЕЄСТРИ ││ Дозволяти образи лише з довірених реєстрів ││ Блокувати: docker.io, дозволити: gcr.io/my-project ││ ││ 2. ПЕРЕВІРКА ПІДПИСУ ││ Вимагати дійсні підписи на всіх образах ││ Інструменти: Kyverno, OPA/Gatekeeper, Connaisseur ││ ││ 3. СКАНУВАННЯ ВРАЗЛИВОСТЕЙ ││ Блокувати образи з критичними CVE ││ Інструменти: Trivy, Snyk, Anchore ││ ││ 4. ВИМОГА ДАЙДЖЕСТУ ││ Вимагати дайджест, відхиляти теги ││ image: nginx@sha256:abc123... ││ ││ ПРИКЛАД ПОЛІТИКИ KYVERNO: ││ Перевірка, що образи підписані конкретним ключем ││ перед дозволом створення поду ││ │└─────────────────────────────────────────────────────────────┘SBOM (Software Bill of Materials)
Розділ «SBOM (Software Bill of Materials)»┌─────────────────────────────────────────────────────────────┐│ ПЕРЕЛІК КОМПОНЕНТІВ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ │├─────────────────────────────────────────────────────────────┤│ ││ ЩО ТАКЕ SBOM? ││ • Інвентаризація всіх компонентів у програмному ││ забезпеченні ││ • Перелік пакетів, версій, ліцензій ││ • Дозволяє відстежувати вразливості ││ ││ ФОРМАТИ: ││ ├── SPDX (стандарт ISO) ││ ├── CycloneDX (OWASP) ││ └── SWID tags ││ ││ ІНСТРУМЕНТИ ГЕНЕРАЦІЇ: ││ ├── Syft (Anchore) ││ ├── Trivy (Aqua) ││ └── Docker Scout ││ ││ ВИПАДКИ ВИКОРИСТАННЯ: ││ • Реагування на вразливості (знайти зачеплені образи) ││ • Відповідність ліцензіям ││ • Відстеження залежностей ││ • Реагування на інциденти ││ ││ ПРИКЛАД: Реагування на Log4Shell ││ З SBOM: Запит "які образи мають log4j?" ││ Без SBOM: Ручне сканування всіх образів ││ │└─────────────────────────────────────────────────────────────┘Практики безпечного ланцюга постачання
Розділ «Практики безпечного ланцюга постачання»Безпека образів
Розділ «Безпека образів»┌─────────────────────────────────────────────────────────────┐│ ЧЕКЛІСТ БЕЗПЕКИ ОБРАЗІВ │├─────────────────────────────────────────────────────────────┤│ ││ ФАЗА ЗБІРКИ ││ ☐ Використовувати мінімальні базові образи (distroless, ││ scratch) ││ ☐ Багатоетапні збірки (розділення збірки/виконання) ││ ☐ Прив'язати базовий образ до дайджесту ││ ☐ Сканувати під час збірки, зупиняти при критичних CVE ││ ☐ Генерувати SBOM ││ ││ ПІДПИС ТА ЗБЕРІГАННЯ ││ ☐ Підписувати образи після збірки ││ ☐ Використовувати приватний реєстр ││ ☐ Увімкнути незмінні теги ││ ☐ Зберігати підписи разом з образами ││ ││ РОЗГОРТАННЯ ││ ☐ Завантажувати за дайджестом, а не за тегом ││ ☐ Перевіряти підписи при admission ││ ☐ Дозволяти лише схвалені реєстри ││ ☐ Блокувати образи з критичними вразливостями ││ ││ ЧАС ВИКОНАННЯ ││ ☐ Безперервне сканування в реєстрі ││ ☐ Сповіщення про нові CVE у запущених образах ││ ☐ Процес оновлення/перезбірки ││ │└─────────────────────────────────────────────────────────────┘Безпека CI/CD
Розділ «Безпека CI/CD»┌─────────────────────────────────────────────────────────────┐│ ЗАХОДИ БЕЗПЕКИ CI/CD │├─────────────────────────────────────────────────────────────┤│ ││ ВИХІДНИЙ КОД ││ ├── Вимагати перевірку коду для всіх змін ││ ├── Правила захисту гілок ││ ├── Підписані коміти ││ └── Сканування залежностей у PR ││ ││ СЕРЕДОВИЩЕ ЗБІРКИ ││ ├── Ефемерні агенти збірки ││ ├── Мінімальні дозволи збірки ││ ├── Ізольовані середовища збірки ││ └── Журналювання аудиту всіх збірок ││ ││ УПРАВЛІННЯ СЕКРЕТАМИ ││ ├── Без секретів у коді/змінних середовища ││ ├── Використовувати менеджери секретів (Vault, AWS ││ │ Secrets) ││ ├── Регулярна ротація облікових даних ││ └── Аудит доступу до секретів ││ ││ РОЗГОРТАННЯ ││ ├── GitOps (декларативне, з можливістю аудиту) ││ ├── Вимагати затвердження для продакшну ││ ├── Перевіряти артефакти перед розгортанням ││ └── Можливість відкату ││ │└─────────────────────────────────────────────────────────────┘Фреймворки безпеки ланцюга постачання
Розділ «Фреймворки безпеки ланцюга постачання»SLSA (Supply-chain Levels for Software Artifacts)
Розділ «SLSA (Supply-chain Levels for Software Artifacts)»┌─────────────────────────────────────────────────────────────┐│ ФРЕЙМВОРК SLSA │├─────────────────────────────────────────────────────────────┤│ ││ SLSA = Supply-chain Levels for Software Artifacts ││ Вимовляється "salsa" ││ ││ РІВНІ: ││ ││ Рівень 0: Без гарантій ││ └── Без провенансу, без верифікації ││ ││ Рівень 1: Провенанс існує ││ └── Процес збірки генерує провенанс ││ ││ Рівень 2: Керована платформа збірки ││ └── Збірка на керованій платформі ││ ││ Рівень 3: Зміцнені збірки ││ └── Ізольовані, ефемерні середовища збірки ││ ││ ПРОВЕНАНС: ││ • Хто зібрав? ││ • Який вихідний код використано? ││ • Який процес збірки? ││ • Криптографічно підписана атестація ││ │└─────────────────────────────────────────────────────────────┘Екосистема Sigstore
Розділ «Екосистема Sigstore»┌─────────────────────────────────────────────────────────────┐│ ЕКОСИСТЕМА SIGSTORE │├─────────────────────────────────────────────────────────────┤│ ││ КОМПОНЕНТИ: ││ ││ Cosign ││ ├── Підписування та верифікація образів контейнерів ││ ├── Підпис без ключів через OIDC ││ └── Зберігання підписів у OCI-реєстрах ││ ││ Fulcio ││ ├── Центр сертифікації для Sigstore ││ ├── Видає короткочасні сертифікати ││ └── На основі OIDC-ідентичності ││ ││ Rekor ││ ├── Журнал прозорості ││ ├── Незмінний запис підписів ││ └── Публічний, з можливістю аудиту ││ ││ РОБОЧИЙ ПРОЦЕС БЕЗ КЛЮЧІВ: ││ 1. Автентифікація через OIDC (GitHub, Google) ││ 2. Fulcio видає короткочасний сертифікат ││ 3. Підписання артефакту сертифікатом ││ 4. Запис у журнал прозорості Rekor ││ 5. Верифікатор перевіряє Rekor + OIDC-ідентичність ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
Атака SolarWinds компрометувала 18 000+ організацій через одне порушення ланцюга постачання. Системи збірки є високоцінними цілями.
-
Тайпосквотинг відповідає за тисячі шкідливих пакетів. Одна різниця у символі (наприклад,
lodashпроти1odash) може призвести до компрометації. -
SBOM стає обов’язковим у багатьох секторах. Виконавчий указ США 14028 вимагає SBOM для програмного забезпечення, що продається федеральному уряду.
-
Підпис без ключів за допомогою Sigstore усуває управління ключами — одну з найбільших перешкод для впровадження підписування образів.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Рішення |
|---|---|---|
| Використання тегу :latest | Змінний, непередбачуваний | Прив’язувати до дайджесту |
| Відсутність сканування образів | Невідомі вразливості | Сканувати в CI та реєстрі |
| Довіра до публічних образів | Можуть бути компрометовані | Створювати/верифікувати власні |
| Жорстко закодовані секрети в CI | Відкриті в журналах/історії | Використовувати менеджери секретів |
| Відсутність провенансу | Неможливо перевірити походження | Реалізувати SLSA |
Перевірка знань
Розділ «Перевірка знань»-
Що таке атака на ланцюг постачання?
Відповідь
Атака, яка компрометує програмне забезпечення в якійсь точці його створення або ланцюга доставки — наприклад, шкідливі залежності, компрометовані системи збірки або підроблені образи — до того, як воно потрапляє до цільового середовища. Шкідливий код виконується з повною довірою, оскільки він вбудований у довірені артефакти. -
Чому змінність тегів є ризиком безпеки?
Відповідь
Теги можна перезаписати. Зловмисник, який отримає доступ до реєстру, може замінити образ із тегом на шкідливу версію. Нові поди, що завантажують цей тег, отримують шкідливий образ. Використання дайджестів запобігає цьому, оскільки дайджести є адресованими за контентом та незмінними. -
Що таке SBOM і чому це важливо?
Відповідь
Software Bill of Materials — це інвентаризація всіх компонентів у програмному забезпеченні: пакети, версії, ліцензії. Це дозволяє реагувати на вразливості (швидко знайти, що зачеплено новою CVE), відповідати ліцензійним вимогам та відстежувати залежності. -
Як працює підпис без ключів (Sigstore)?
Відповідь
Замість управління ключами, підписанти автентифікуються через постачальника OIDC-ідентичності (GitHub, Google). Fulcio видає короткочасний сертифікат на основі цієї ідентичності. Підпис та ідентичність записуються у журнал прозорості Rekor. Верифікатори перевіряють підпис за записаною ідентичністю. -
Які рівні SLSA?
Відповідь
SLSA (Supply-chain Levels for Software Artifacts) визначає прогресивні рівні безпеки: Рівень 0 (без гарантій), Рівень 1 (провенанс існує), Рівень 2 (керована платформа збірки), Рівень 3 (зміцнені, ізольовані збірки). Вищі рівні забезпечують сильніші гарантії цілісності ланцюга постачання.
Практична вправа: Оцінка ризиків ланцюга постачання
Розділ «Практична вправа: Оцінка ризиків ланцюга постачання»Сценарій: Перегляньте цю конфігурацію CI/CD та визначте ризики ланцюга постачання:
# DockerfileFROM ubuntu:latestRUN apt-get update && apt-get install -y nodejs npmCOPY package.json .RUN npm installCOPY . .CMD ["node", "app.js"]
# CI Pipelinesteps: - checkout - run: docker build -t myapp . - run: docker push myregistry/myapp:latest - run: kubectl set image deployment/myapp myapp=myregistry/myapp:latestВизначте ризики ланцюга постачання:
Ризики ланцюга постачання
Проблеми Dockerfile:
-
FROM ubuntu:latest
- Змінний тег, непередбачуваний контент
- Великий образ із багатьма пакетами
- Виправлення: Використовувати прив’язку до дайджесту, мінімальний базовий образ
-
apt-get install nodejs npm
- Встановлення з публічних репозиторіїв під час збірки
- Без прив’язки версій
- Виправлення: Використовувати офіційний образ Node або прив’язати версії
-
npm install без lockfile
- Версії залежностей можуть змінюватися між збірками
- Вразливий до плутанини залежностей
- Виправлення: Використовувати npm ci з package-lock.json
Проблеми конвеєра CI:
-
Без сканування образів
- Вразливості не виявляються перед публікацією
- Виправлення: Додати крок сканування trivy/grype
-
Без підписування образів
- Немає способу перевірити автентичність образу
- Виправлення: Підписувати за допомогою cosign після збірки
-
Публікація з тегом :latest
- Змінний тег
- Виправлення: Використовувати SHA коміту або тег версії + дайджест
-
kubectl set image з тегом
- Поди можуть завантажувати різні образи
- Виправлення: Використовувати дайджест у deployment
-
Без затвердження/шлюзу
- Пряма публікація у продакшн
- Виправлення: Додати крок ручного затвердження
Концепція безпечної версії:
- Прив’язати базовий образ до дайджесту
- Використовувати lockfile для залежностей
- Сканувати образи на CVE
- Підписувати образи після збірки
- Публікувати з незмінними тегами
- Перевіряти підписи при admission
- Використовувати GitOps із шлюзами затвердження
Підсумок
Розділ «Підсумок»Безпека ланцюга постачання захищає шлях від коду до кластера:
| Вектор атаки | Приклади | Запобігання |
|---|---|---|
| Базові образи | Тайпосквотинг, компрометація | Прив’язка до дайджесту, верифікація, сканування |
| Залежності | Шкідливі пакети, плутанина | Lockfile, сканування, приватні репозиторії |
| CI/CD | Компрометація збірки, крадіжка секретів | Ізольовані збірки, управління секретами |
| Реєстр | Перезапис тегів, компрометація | Підписування, дайджест, незмінні теги |
Ключові заходи:
- Підписувати образи та перевіряти при admission
- Генерувати та підтримувати SBOM
- Безперервне сканування на вразливості
- Реалізувати SLSA для провенансу
- Використовувати GitOps для розгортань з можливістю аудиту
Наступний модуль
Розділ «Наступний модуль»Модуль 5.1: Безпека образів — Захист образів контейнерів протягом їхнього життєвого циклу.