Лекция 7

1. Лекция 6. Верификация и развёртывание (Verify & Deploy)

ЛЕКЦИЯ 6.
ВЕРИФИКАЦИЯ И РАЗВЁРТЫВАНИЕ
(VERIFY & DEPLOY)

2.

Категории проверок
Секреты (Secret Scanning)
• Безопасность (SCA — Software Composition Analysis)
Пример реальной уязвимости — Log4Shell (2021): библиотека
Log4j версий 2.0–2.14.1 содержала критическую уязвимость
(CVE-2021-44228)
Лицензии

3.

Качество (Quality Gates)
Quality Gate — это пороговое значение для
метрики. Если метрика не проходит порог —
сборка считается неудачной.
• Целостность
• Артефакт может быть подменён:
• Злоумышленник взломал CI-сервер и подменил
JAR-файл
• Библиотека в реестре была скомпрометирована
• Разработчик по ошибке загрузил не тот файл
Защита:
• контрольные суммы и цифровые подписи.
• цифровая подпись

4. Практическое задание: Ситуация: Вы аналитик в коммерческой компании, разрабатывающей SaaS-продукт. CI-система выдала отчёт

ПРАКТИЧЕСКОЕ ЗАДАНИЕ: СИТУАЦИЯ: ВЫ АНАЛИТИК В КОММЕРЧЕСКОЙ КОМПАНИИ,
РАЗРАБАТЫВАЮЩЕЙ SAAS-ПРОДУКТ. CI-СИСТЕМА ВЫДАЛА ОТЧЁТ ПРОВЕРКИ ЛИЦЕНЗИЙ
ПЕРЕД РЕЛИЗОМ.
3. xml-parser (version 2.0.0)
• Product: MySaaSProduct v2.0.0
- License: LGPL v2.1
• Total dependencies: 47
- Usage: Dynamic linking (separate JAR loaded at runtime)
• DEPENDENCIES WITH RESTRICTIVE LICENSES:
- Risk: MEDIUM - Requires releasing changes to xml• 1. crypto-core (version 1.5.2)
parser only
• - License: AGPL v3.0
- Action: REVIEW
• - Usage: Embedded in backend service (static linking)
• - Risk: CRITICAL - Requires releasing full SaaS source code
4. logging-helper (version 1.0.0)
• - Action: REPLACE
- License: MIT
• 2. network-utils (version 3.2.1)
- Usage: Static linking
• - License: GPL v2.0
- Risk: NONE
• - Usage: Static linking inside main JAR
• - Risk: HIGH - Requires releasing source code under GPL - Action: APPROVE
Вопросы
• - Action: REPLACE
1. Какие библиотеки несовместимы с коммерческим SaaS-продуктом?
2. Какая библиотека представляет наибольший риск и почему?
3. Какую библиотеку можно оставить, но с оговорками?

5.

6.

7. Deploy (развёртывание) — процесс доставки верифицированного артефакта в целевую среду и его активации.

DEPLOY (РАЗВЁРТЫВАНИЕ) — ПРОЦЕСС ДОСТАВКИ
ВЕРИФИЦИРОВАННОГО АРТЕФАКТА В ЦЕЛЕВУЮ
СРЕДУ И ЕГО АКТИВАЦИИ.
СТРАТЕГИИ РАЗВЁРТЫВАНИЯ ДЛЯ
СЕРВЕРНЫХ ПРИЛОЖЕНИЙ
Стратегия 1: Recreate (пересоздание)

8.

Стратегия 2: Rolling Update
Стратегия 3: Blue-Green (сине-зелёный)

9.

Стратегия 4: Canary
A/B Testing

10. Задание «Выбор стратегии деплоя»   Ситуация: Подберите стратегию деплоя для каждого сценария. Обоснуйте выбор.

ЗАДАНИЕ «ВЫБОР СТРАТЕГИИ ДЕПЛОЯ»
СИТУАЦИЯ: ПОДБЕРИТЕ СТРАТЕГИЮ ДЕПЛОЯ ДЛЯ КАЖДОГО СЦЕНАРИЯ. ОБОСНУЙТЕ ВЫБОР.

11.

Kubernetes — стандарт для оркестрации
контейнеров. Деплой в K8s обычно выглядит так:
• 1. Собрать Docker-образ → загрузить в registry
• 2. Обновить Deployment (новый образ)
• 3. Kubernetes сам выполняет Rolling update (или
другую стратегию)
Deploy мобильных приложений

12.

Deploy библиотек в реестры

13. Роль аналитика в Verify и Deploy

РОЛЬ АНАЛИТИКА В VERIFY И DEPLOY
• 1. SCA проверка обязательна. Сборка должна падать
при критических уязвимостях (CVSS ≥ 7.0).
• 2. Проверка лицензий обязательна. Белый список
разрешённых лицензий утверждён с юристами.
Сборка падает при нарушении.
• 3. Проверка секретов обязательна. GitLeaks или
аналог должен быть в CI.
• 4. Quality Gates настроены. Покрытие тестами,
дублирование, сложность — с конкретными числами.
• 1. Стратегия деплоя выбрана с учётом бизнестребований (даунтайм, откат, ресурсы).
• 2. PROD деплоится только вручную (если нет
исключительных обстоятельств).
• 3. Есть разделение сред: DEV → TEST/STAGING
→ PROD.
• 4. Один и тот же артефакт идёт через все среды (не
пересобирается).
• 5. Для мобильных приложений — автоматическая
загрузка в магазины через fastlane.