Днешните атаки често не идват директно към вас, а през библиотека, контейнер образ или CI/CD pipeline. Ето практични стъпки да затворите най-честите дупки в software supply chain.
Как изглежда атаката в реалния свят
Вместо да атакуват директно инфраструктурата ви, нападателите:
- компрометират dependency (пакет/библиотека)
- подменят container image
- вкарват зловреден код през CI/CD секрети
- атакуват build сървъри или signing ключове
Резултатът: “вие” доставяте проблема към клиентите си или го разгръщате вътрешно.
Минимална цел: да знаете какво пускате в продукция
Първата практична линия на защита е видимост:
- кои зависимости имате (директни и транзитивни)
- кои версии
- откъде идват
- кой ги е построил (build provenance)
- как са подписани/валидирани
Тук SBOM и SLSA не са “buzzwords”, а начин да докажете произход и състав.
План в 3 нива (изпълним, без big-bang)
Ниво 1: “Хигиена” (1–2 седмици)
- заключете dependency версии (lock files)
- включете автоматични dependency updates с review
- забранете непроверени публични registry-та (или ги проксирайте през вътрешен)
- минимизирайте и ротирате CI/CD секрети
Ниво 2: “Контроли” (2–6 седмици)
- сканиране на зависимости и контейнер образи при всеки build
- policy gate: build-ът не минава при критични уязвимости (с разумни изключения и срок)
- отделни среди и права за build vs deploy
- ограничете кой може да модифицира pipeline-и и secrets
Ниво 3: “Доказуемост” (6–12 седмици)
- SBOM за всеки release (и архив)
- provenance/attestations за build артефакти (кой/как е построил)
- подписи за артефакти и валидация при deploy
- мониторинг за “аномалии” в build процеса
12 практични контрола за CI/CD и зависимости
- Principle of least privilege за CI runner-и и service accounts
- Secrets management вместо secrets в repo/variables “на доверие”
- Branch protections + mandatory reviews за pipeline файлове
- Signed commits/tags за release-и
- Immutable artifacts (не “latest”, не overwrite на версии)
- Container image pinning по digest, не по tag
- Allowlist на registry-та и package sources
- Reproducible builds където е възможно
- Separate build/deploy keys и отделни права
- Сканиране на IaC (Terraform/K8s manifests)
- Логване на pipeline действия (кой пусна, кой промени, кой одобри)
- План за реагиране при компрометирана зависимост (kill switch + бърз rebuild)
Как да започнете “утре” (най-лесният starter kit)
- изберете 1 критично приложение
- генерирайте SBOM за текущия release и го архивирайте
- включете dependency/container scanning в CI
- добавете правило: “критични CVE = fail”, но с изключение само по тикет и срок
- ограничете редакцията на CI/CD конфигурацията само до малка група
Полезни рамки за ориентация: OWASP за dependency рискове и SLSA като модел за нива на зрелост.