Модуль 4.5: Моделювання загроз і теорія ланцюга постачання

Складність: [СЕРЕДНЯ] - Основне мислення безпеки

Час на виконання: 25-30 хвилин

Передумови: Модуль 4.1: Поверхні атак, Модуль 4.4: Загрози ланцюга постачання

Що ви зможете робити

Після завершення цього модуля ви зможете:

Спроєктувати модель загроз для Kubernetes за допомогою STRIDE або подібних фреймворків у всіх рівнях 4C
Оцінити межі довіри в ланцюгах постачання програмного забезпечення для визначення місць, де потрібна верифікація
Оцінити ризики ланцюга постачання систематично, а не реагувати на окремі загрози
Визначити які засоби контролю (підпис, сканування, admission-політики) адресують які загрози ланцюга постачання

У грудні 2020 року рутинний аудит безпеки FireEye виявив щось жахливе: зловмисники провели дев’ять місяців усередині 18 000+ організацій через єдиний компрометований сервер збірки SolarWinds. Жоден брандмауер не заблокував їх. Жодна IDS не позначила їх. Шкідливий код прийшов через довірене оновлення програмного забезпечення — підписане, верифіковане та доставлене через офіційні канали. Організації, які впоралися найкраще, не були тими, хто мав найбільше інструментів — вони були тими, хто змоделював загрози свого ланцюга постачання і точно знав, які межі довіри мають значення.

Чому цей модуль важливий

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

KCSA перевіряє, чи можете ви думати про загрози систематично — а не просто реагувати на них. Цей модуль навчає, як моделювати загрози в усіх рівнях 4C Kubernetes та застосовувати це мислення до ризиків ланцюга постачання.

Модель 4C: Систематичне мислення про загрози

Безпека Kubernetes працює в чотирьох концентричних рівнях. Кожен рівень успадковує слабкості нижчого рівня — безпечний контейнер нічого не означає на компрометованому кластері.

┌─────────────────────────────────────────────────────────────┐
│              МОДЕЛЬ 4C                                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  CLOUD (Рівень інфраструктури)                       │  │
│  │  • Неправильні конфігурації IAM                      │  │
│  │  • Зловживання сервісом метаданих (169.254.169.254)  │  │
│  │  • Мережева відкритість (публічні API-сервери)       │  │
│  │  • Витоки сховищ (storage bucket)                    │  │
│  │                                                       │  │
│  │  ┌─────────────────────────────────────────────────┐  │  │
│  │  │  CLUSTER (Рівень оркестрації)                  │  │  │
│  │  │  • Відкритість etcd (всі секрети тут)          │  │  │
│  │  │  • Неправильна конфігурація API-сервера        │  │  │
│  │  │  • Шкідливі admission webhooks                 │  │  │
│  │  │  • Надмірно дозвільний RBAC                    │  │  │
│  │  │                                                 │  │  │
│  │  │  ┌───────────────────────────────────────────┐  │  │  │
│  │  │  │  CONTAINER (Рівень виконання)            │  │  │  │
│  │  │  │  • Підвищення привілеїв                  │  │  │  │
│  │  │  │  • Необмежені системні виклики            │  │  │  │
│  │  │  │  • Файлова система для запису             │  │  │  │
│  │  │  │  • Запуск від root                        │  │  │  │
│  │  │  │                                           │  │  │  │
│  │  │  │  ┌─────────────────────────────────────┐  │  │  │  │
│  │  │  │  │  CODE (Рівень застосунку)          │  │  │  │  │
│  │  │  │  │  • Вразливі залежності             │  │  │  │  │
│  │  │  │  │  • Отруєні базові образи           │  │  │  │  │
│  │  │  │  │  • Секрети у вихідному коді         │  │  │  │  │
│  │  │  │  │  • Неперевірений ввід               │  │  │  │  │
│  │  │  │  └─────────────────────────────────────┘  │  │  │  │
│  │  │  └───────────────────────────────────────────┘  │  │  │
│  │  └─────────────────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
│  КЛЮЧОВИЙ ВИСНОВОК: Кожен рівень успадковує ризик від      │
│  внутрішніх рівнів. Компрометований рівень Code підриває   │
│  безпеку Container, Cluster і Cloud — ось чому ланцюг      │
│  постачання має значення.                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чому 4C важлива для ланцюга постачання

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

Рівень	Як проявляються атаки на ланцюг постачання
Code	Шкідлива залежність, отруєний образ, бібліотека з бекдором
Container	Компрометований образ працює як очікується — без аномалій часу виконання
Cluster	Admission-контролери схвалюють “довірений” артефакт
Cloud	Викрадені дані передаються через легітимні мережеві шляхи

Традиційна атака працює зовні-всередину (мережа → кластер → контейнер). Атака на ланцюг постачання працює зсередини-назовні — вона починається з довіри та використовує цю довіру.

Робочий процес моделювання загроз для Kubernetes

Моделювання загроз — це структурований спосіб відповісти: “Що може піти не так, і що ми повинні з цим робити?”

┌─────────────────────────────────────────────────────────────┐
│              РОБОЧИЙ ПРОЦЕС МОДЕЛЮВАННЯ ЗАГРОЗ               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Крок 1: ІДЕНТИФІКАЦІЯ АКТИВІВ                              │
│  ├── Що ми захищаємо?                                       │
│  ├── Секрети в etcd                                         │
│  ├── Дані клієнтів у базах даних                            │
│  ├── Облікові дані сервісів                                 │
│  └── Образи контейнерів та артефакти збірки                 │
│                                                             │
│  Крок 2: КАРТУВАННЯ ПОТОКІВ ДАНИХ                           │
│  ├── Як переміщуються дані?                                 │
│  ├── kubectl → API-сервер → etcd                            │
│  ├── CI/CD → Реєстр → kubelet → Контейнер                  │
│  ├── Pod → Service → Ingress → Інтернет                     │
│  └── Кожна стрілка — потенційна поверхня атаки              │
│                                                             │
│  Крок 3: ІДЕНТИФІКАЦІЯ ТОЧОК ВХОДУ                          │
│  ├── Де можуть проникнути зловмисники?                      │
│  ├── API-сервер (зовнішній/внутрішній)                      │
│  ├── Ingress-контролери                                     │
│  ├── Конвеєр CI/CD                                          │
│  ├── Реєстр образів                                         │
│  └── Робочі станції розробників                             │
│                                                             │
│  Крок 4: МОДЕЛЮВАННЯ ВИПАДКІВ ЗЛОВЖИВАННЯ                   │
│  ├── Що якщо зловмисник отримає cluster-admin?              │
│  ├── Що якщо базовий образ буде отруєно?                    │
│  ├── Що якщо admission webhook буде компрометовано?         │
│  └── Що якщо облікові дані CI/CD будуть вкрадені?           │
│                                                             │
│  Крок 5: ПРИЗНАЧЕННЯ ЗАХОДІВ ЗАХИСТУ                        │
│  ├── Хто відповідає за кожен контроль?                      │
│  ├── Команда платформи → admission-політики, RBAC            │
│  ├── Команда безпеки → сканування, моніторинг               │
│  ├── Команда розробки → безпечний код, оновлення залежностей│
│  └── Документувати залишковий ризик для прийнятих прогалин  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

STRIDE у застосуванні до Kubernetes

STRIDE — це класичний фреймворк моделювання загроз. Ось як кожна категорія відповідає Kubernetes:

Категорія STRIDE	Приклад у Kubernetes	Аспект ланцюга постачання
Spoofing (Підробка)	Фальшивий kubelet, що приєднується до кластера	Тайпосквотинг назви образу
Tampering (Підробка даних)	Змінений ConfigMap у сховищі	Артефакт збірки підроблено в CI
Repudiation (Відмова від дій)	Немає аудиту, хто запускав kubectl	Немає провенансу для зібраних образів
Information Disclosure (Витік інформації)	etcd відкрито без TLS	SBOM розкриває інформацію про внутрішні залежності
Denial of Service (Відмова в обслуговуванні)	Бомба ресурсів у pod spec	Залежність з нескінченним циклом
Elevation of Privilege (Підвищення привілеїв)	Втеча з контейнера на вузол	Компрометований образ з reverse shell

Ризик ланцюга постачання: глибша модель

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

Межі довіри в ланцюзі постачання

Кожна передача в конвеєрі доставки програмного забезпечення перетинає межу довіри. Загрози концентруються на цих межах:

┌─────────────────────────────────────────────────────────────┐
│              МЕЖІ ДОВІРИ ЛАНЦЮГА ПОСТАЧАННЯ                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Розробник ──┬── Репозиторій ──┬── Збірка ──┬── Реєстр     │
│              │                │            │                │
│         МЕЖА 1            МЕЖА 2       МЕЖА 3              │
│                                                             │
│  МЕЖА 1: Розробник → Вихідний код                          │
│  ├── РИЗИК: Компрометована робоча станція, вкрадені         │
│  │   облікові дані                                          │
│  ├── КОНТРОЛЬ: MFA, підписані коміти, захист гілок          │
│  └── ПЕРЕВІРКА: Підписи комітів, ревю коду                  │
│                                                             │
│  МЕЖА 2: Вихідний код → Збірка                             │
│  ├── РИЗИК: Шкідливі скрипти збірки, плутанина залежностей │
│  ├── КОНТРОЛЬ: Ізольовані збірки, прив'язані залежності     │
│  └── ПЕРЕВІРКА: Відтворювані збірки, провенанс збірки       │
│                                                             │
│  МЕЖА 3: Збірка → Реєстр                                  │
│  ├── РИЗИК: Підробка образу, перезапис тегу                 │
│  ├── КОНТРОЛЬ: Підписування образів, незмінні теги           │
│  └── ПЕРЕВІРКА: Верифікація підпису при admission            │
│                                                             │
│  Реєстр ──┬── Admission ──┬── Час виконання                │
│            │               │                                │
│        МЕЖА 4          МЕЖА 5                               │
│                                                             │
│  МЕЖА 4: Реєстр → Кластер                                 │
│  ├── РИЗИК: Завантаження компрометованих/застарілих образів │
│  ├── КОНТРОЛЬ: Admission-політики, дозволені реєстри        │
│  └── ПЕРЕВІРКА: Збіг дайджесту, перевірка підпису, CVE-скан │
│                                                             │
│  МЕЖА 5: Admission → Час виконання                         │
│  ├── РИЗИК: Допущений под поводиться зловмисно              │
│  ├── КОНТРОЛЬ: NetworkPolicies, seccomp, AppArmor            │
│  └── ПЕРЕВІРКА: Моніторинг часу виконання (Falco), аудит    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Провенанс: знати, звідки що прийшло

Провенанс відповідає на фундаментальне питання: чи можете ви довести, що цей артефакт є тим, за що він себе видає?

┌─────────────────────────────────────────────────────────────┐
│              ЛАНЦЮГ ПРОВЕНАНСУ                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  БЕЗ ПРОВЕНАНСУ:                                            │
│  "Цей образ прийшов звідкись. У нього є тег. Розгортаємо." │
│                                                             │
│  З ПРОВЕНАНСОМ (SLSA Рівень 3):                             │
│  ├── ХТО зібрав? → Ідентичність CI-системи (OIDC)           │
│  ├── ЯКИЙ вихідний код? → git commit SHA + URL репозиторію  │
│  ├── ЯК було зібрано? → конфігурація збірки, точка входу    │
│  ├── КОЛИ було зібрано? → мітка часу                        │
│  ├── ДЕ було зібрано? → ізольований, ефемерний білдер       │
│  └── ДОКАЗ? → Підписана атестація в журналі прозорості Rekor│
│                                                             │
│  SBOM додає: ЩО ВСЕРЕДИНІ?                                  │
│  ├── Кожна бібліотека, кожна версія                         │
│  ├── Кожна транзитивна залежність                           │
│  └── Кожна ліцензія                                         │
│                                                             │
│  Разом, провенанс + SBOM відповідають:                      │
│  "Я точно знаю, що в цьому артефакті,                       │
│   хто його зібрав, з якого вихідного коду, і можу           │
│   це довести."                                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Шлюзи політик: забезпечення довіри на межі кластера

Шлюзи політик — це контролі на етапі admission, які забезпечують вимоги ланцюга постачання перед запуском подів:

┌─────────────────────────────────────────────────────────────┐
│              МОДЕЛЬ ШЛЮЗУ ПОЛІТИК                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Запит на створення поду                                    │
│        │                                                    │
│        ▼                                                    │
│  ┌──────────────┐   FAIL → "Образ не з дозволеного         │
│  │ Список       │           реєстру"                       │
│  │ дозволених   │                                           │
│  │ реєстрів     │                                           │
│  └──────┬───────┘                                           │
│         │ PASS                                              │
│         ▼                                                    │
│  ┌──────────────┐   FAIL → "Образ не підписаний             │
│  │ Перевірка    │           довіреним ключем"               │
│  │ підпису      │                                           │
│  └──────┬───────┘                                           │
│         │ PASS                                              │
│         ▼                                                    │
│  ┌──────────────┐   FAIL → "Знайдено КРИТИЧНУ CVE:          │
│  │ Перевірка    │           CVE-2024-XXXX"                  │
│  │ вразливостей │                                           │
│  └──────┬───────┘                                           │
│         │ PASS                                              │
│         ▼                                                    │
│  ┌──────────────┐   FAIL → "Атестація SBOM не               │
│  │ SBOM/        │           знайдена"                       │
│  │ Атестація    │                                           │
│  └──────┬───────┘                                           │
│         │ PASS                                              │
│         ▼                                                    │
│  Под допущено ✓                                              │
│                                                             │
│  ІНСТРУМЕНТИ: Kyverno, OPA/Gatekeeper, Connaisseur, Ratify │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Матриця заходів захисту

Ця матриця відображає поширені загрози Kubernetes на концептуальні заходи захисту. Використовуйте її як шаблон при моделюванні загроз ваших кластерів:

Загроза	Рівень 4C	Захист	Відповідальний
Компрометований admission webhook	Cluster	mTLS, мінімальний RBAC, fail-closed за замовчуванням, ізоляція webhook	Платформа
Отруєння реєстру	Code	Підписані образи, прив’язані дайджести, обмежений вихідний трафік до реєстру, SBOM-скан перед admission	Безпека
Втеча з вузла/контейнера	Container	seccomp/AppArmor, скинуті capabilities, distroless бази, rootfs тільки для читання	Платформа
Вкрадений kubeconfig	Cluster	Короткочасні облікові дані, ротація клієнтських сертифікатів, RBAC з мінімальними привілеями, MFA	Безпека
Шкідлива залежність	Code	Lockfile, сканування залежностей, приватні репозиторії пакетів, генерація SBOM	Розробка
Крадіжка облікових даних CI/CD	Code/Cluster	Ефемерні агенти збірки, менеджери секретів, OIDC-федерація (без довгоживучих токенів)	Платформа
Відкритість даних etcd	Cluster	Шифрування у сховищі, обмеження доступу до etcd лише для API-сервера, mTLS	Платформа
Зловживання сервісом метаданих	Cloud	IMDSv2/приховування метаданих, обмеження IAM, мережеві політики	Хмара/Платформа

Застосування моделей загроз: розроблений приклад

Розглянемо команду, яка розгортає платіжний сервіс:

┌─────────────────────────────────────────────────────────────┐
│              МОДЕЛЬ ЗАГРОЗ ПЛАТІЖНОГО СЕРВІСУ                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  АКТИВИ:                                                    │
│  • Токени кредитних карток (область PCI)                    │
│  • API-ключі до платіжного процесора                        │
│  • Журнали транзакцій                                       │
│                                                             │
│  ПОТІК ДАНИХ:                                               │
│  Користувач → Ingress → payment-svc → payment-processor     │
│                              │         (зовнішній)          │
│                              ▼                              │
│                         PostgreSQL (дані PCI)                │
│                                                             │
│  ОСНОВНІ ЗАГРОЗИ:                                           │
│  1. Компрометований образ payment-svc (ланцюг постачання)   │
│     → Викрадає токени карток через DNS                       │
│     → Захист: підписані образи, SBOM, egress NetworkPolicy  │
│                                                             │
│  2. Вкрадений API-ключ платіжного процесора                 │
│     → Шахрайські транзакції                                  │
│     → Захист: External Secrets Operator, ротація             │
│                                                             │
│  3. SQL-ін'єкція, що розкриває дані PCI                     │
│     → Порушення відповідності, штрафи                        │
│     → Захист: Параметризовані запити, WAF, журнал аудиту    │
│                                                             │
│  4. Втеча з контейнера payment-svc                           │
│     → Доступ до вузла, потім до кластера                     │
│     → Захист: seccomp, non-root, rootfs тільки для читання  │
│                                                             │
│  ЗАЛИШКОВИЙ РИЗИК:                                          │
│  • Zero-day у базовому образі (прийнято, зменшено           │
│    скануванням)                                              │
│  • Компрометація платіжного процесора (поза нашим           │
│    контролем)                                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Порушення SolarWinds 2020 року зачепило 18 000 організацій, включно з урядовими агентствами США, хоча зловмисники компрометували лише один сервер збірки. Атаки на ланцюг постачання мають надзвичайний важіль — одне порушення, тисячі жертв.
Фреймворк SLSA від Google народився з десятиліття внутрішньої роботи над безпекою ланцюга постачання. Google вимагає провенанс для кожного бінарного файлу, що працює у продакшні — понад два мільярди контейнерів на тиждень.
Концепція “моделювання загроз” старша за комп’ютери — військові стратеги використовували структуроване змагальне мислення століттями. Microsoft формалізував STRIDE для програмного забезпечення у 1999 році, і він залишається найширше використовуваним фреймворком.
Звіт Sonatype за 2023 рік виявив, що атаки на ланцюг постачання програмного забезпечення зросли на 742% за попередні три роки, з понад 245 000 виявлених шкідливих пакетів у npm, PyPI та інших реєстрах.

Поширені помилки

Помилка	Чому це шкодить	Рішення
Моделювання один раз без оновлень	Нові функції вводять нові поверхні атак	Повторно моделювати щоквартально та після великих змін
Фокус лише на загрозах часу виконання	Атаки ланцюга постачання обходять засоби захисту часу виконання	Включити конвеєр CI/CD та залежності в модель
Не призначено відповідальних за заходи захисту	Контролі без відповідальних не впроваджуються	Призначити кожний захід конкретній команді
Ігнорування залишкового ризику	Створює хибне відчуття безпеки	Документувати прийняті ризики та тригери перегляду
Моделювання загроз ізольовано	Пропускає міжкомандні шляхи атак	Включати команди платформи, безпеки та розробки

Перевірка знань

Які чотири рівні моделі безпеки 4C?

Відповідь
Cloud, Cluster, Container, Code. Кожен зовнішній рівень успадковує ризики внутрішніх рівнів — вразливий рівень Code підриває безпеку на кожному іншому рівні, тому безпека ланцюга постачання є такою критичною.
Чому атаки на ланцюг постачання є унікально небезпечними порівняно з традиційними мережевими атаками?

Відповідь
Атаки на ланцюг постачання входять через найвнутрішній рівень (Code) і працюють зсередини назовні. Шкідливий код надходить через довірені канали — підписаний, схвалений та розгорнутий через нормальні процеси. Засоби безпеки часу виконання бачать шкідливий код як легітимний, тому що він вбудований у довірені артефакти.
На які п’ять питань відповідає провенанс?

Відповідь
Хто зібрав (ідентичність), який вихідний код використано (git commit), як було зібрано (конфігурація збірки), коли було зібрано (мітка часу) та де було зібрано (платформа збірки). На рівні SLSA Level 3 ці відповіді криптографічно підписані та записані в журнал прозорості.
У STRIDE, що означає кожна літера і як це застосовується до Kubernetes?

Відповідь
Spoofing (підробка — фальшивий kubelet, тайпосквотинг образів), Tampering (підробка даних — змінені ConfigMap, артефакти збірки), Repudiation (відмова від дій — немає аудиту, немає провенансу образів), Information Disclosure (витік інформації — відкритість etcd, витік SBOM), Denial of Service (відмова в обслуговуванні — бомби ресурсів, погані залежності), Elevation of Privilege (підвищення привілеїв — втеча з контейнера, компрометовані образи з reverse shell).
Що таке межа довіри і чому загрози концентруються в цих точках?

Відповідь
Межа довіри — це точка, де дані або артефакти переходять з одного домену безпеки в інший — наприклад, від розробника до репозиторію вихідного коду, від системи збірки до реєстру або від реєстру до кластера. Загрози концентруються тут, тому що кожна передача вимагає верифікації: приймаюча сторона повинна перевірити, що артефакт не було підроблено. Без верифікації (підписи, дайджести, сканування) зловмисники можуть впровадити шкідливий контент на будь-якій межі.
Чому слід документувати залишковий ризик у моделі загроз?

Відповідь
Не кожну загрозу можна повністю усунути. Документування залишкового ризику (наприклад, "zero-day у базовому образі — прийнято, зменшено безперервним скануванням") запобігає хибному відчуттю безпеки та створює явні тригери перегляду. Це також допомагає визначити пріоритети майбутніх інвестицій у безпеку.

Практична вправа: Побудова моделі загроз

Завдання: Створіть модель загроз для веб-застосунку, що працює в Kubernetes.

Сценарій: Застосунок електронної комерції з трьома сервісами — frontend (React), API (Go) та база даних (PostgreSQL). Команда використовує GitHub Actions для CI/CD та публікує образи у приватний реєстр ECR.

Крок 1 — Визначте активи: Перелічіть щонайменше 5 активів, що потребують захисту.

Приклад активів

Персональні дані клієнтів (імена, адреси, електронні адреси)
Платіжна інформація (обробляється зовнішнім провайдером)
Облікові дані бази даних
Секрети GitHub Actions (облікові дані для публікації в ECR)
Токени автентифікації API
Образи контейнерів в ECR
Kubernetes Secrets

Крок 2 — Картуйте потоки даних та точки входу: Намалюйте шлях від коміту розробника до запущеного поду.

Приклад потоку даних

Розробник → GitHub (push) → GitHub Actions → docker build → ECR
                                                              │
                                            ArgoCD sync ←─────┘
                                                │
                                                ▼
                                          EKS Cluster
                                   ┌──────────────────────┐
                                   │ frontend → api → db  │
                                   └──────────────────────┘

Точки входу:
- GitHub (компрометовані облікові дані розробника)
- GitHub Actions (секрети, компрометація runner)
- ECR (доступ до реєстру)
- EKS API-сервер (крадіжка kubeconfig)
- Ingress (зовнішній трафік)

Крок 3 — Змоделюйте три випадки зловживання за допомогою STRIDE:

Приклади випадків зловживання

Tampering — Компрометація конвеєра збірки: Зловмисник змінює робочий процес GitHub Actions для впровадження бекдору під час збірки. Образ проходить перевірку підпису, тому що був зібраний легітимною CI-системою.
- Захист: Вимагати ревю PR для змін робочих процесів, використовувати повторно використовувані робочі процеси з окремого довіреного репозиторію, провенанс SLSA Level 3.
Spoofing — Плутанина залежностей: Зловмисник публікує публічний npm-пакет з такою ж назвою, як внутрішній пакет. GitHub Actions завантажує публічний (вища версія) пакет замість внутрішнього.
- Захист: .npmrc з обмеженням реєстру, перевірка цілісності lockfile, приватний реєстр для внутрішніх пакетів.
Information Disclosure — Витік секретів у журналах: Облікові дані бази даних з’являються в журналах помилок застосунку, захоплюються централізованим журналюванням, видимі для команди операцій.
- Захист: Очищення журналів, структуроване журналювання з редагуванням чутливих полів, External Secrets Operator для ротації.

Крок 4 — Створіть таблицю заходів захисту з відповідальними:

Приклад таблиці заходів захисту

Загроза	Захист	Відповідальний	Статус
Компрометація конвеєра збірки	Ревю PR для робочих процесів, провенанс SLSA	Платформа	Заплановано
Плутанина залежностей	Обмеження реєстру, перевірка lockfile	Розробка	Впроваджено
Секрети в журналах	Очищення журналів, ротація ESO	Розробка + Платформа	В процесі
Образ із критичною CVE	Trivy в CI, admission-політика	Безпека	Впроваджено
Вкрадений kubeconfig	Короткочасні токени, OIDC-автентифікація	Платформа	Впроваджено

Залишкові ризики:

Zero-day у Go stdlib (прийнято — зменшено швидким процесом оновлення)
Компрометація платформи GitHub Actions (прийнято — поза нашим контролем)

Критерії успіху: У вас є документ з активами, потоками даних, щонайменше 3 випадками зловживання на основі STRIDE, таблицею заходів захисту з відповідальними та документованими залишковими ризиками.

Підсумок

Моделювання загроз — це дисципліна мислення як зловмисник до того, як він це зробить:

Концепція	Ключовий висновок
Модель 4C	Безпека є шаруватою — внутрішні рівні (Code) впливають на всі зовнішні рівні
Ланцюг постачання	Атаки входять на рівні Code та використовують довіру — обходячи засоби захисту часу виконання
Межі довіри	Кожна передача (розробник → код → збірка → реєстр → кластер) потребує верифікації
Провенанс	Ви не можете довіряти тому, що не можете відстежити — підписуйте, атестуйте, верифікуйте
Шлюзи політик	Забезпечуйте вимоги ланцюга постачання на етапі admission, а не після розгортання
STRIDE	Систематичний фреймворк для уникнення пропуску категорій загроз
Залишковий ризик	Документуйте те, що не можете зменшити — хибна безпека гірша за відомий ризик

Мета не в тому, щоб усунути весь ризик — а в тому, щоб точно знати, де ваші ризики, хто за них відповідає та що провокує переоцінку.

Наступний модуль

Модуль 5.1: Безпека образів — Захист образів контейнерів протягом їхнього життєвого циклу.