Глава 13. Безопасность приложений

«Вы не можете доверять коду только потому, что он прошёл сборку. Вы должны доверять всей цепочке: от исходного кода до работающего контейнера.» — SLSA Framework, slsa.dev

В модели Zero Trust приложение — не конечная точка доверия, а ещё одна поверхность атаки, требующая непрерывной верификации. Эта глава охватывает три ключевых направления: безопасность цепочки поставок ПО (supply chain), контроль допуска в Kubernetes (admission control) и защиту API.

13.1. Зачем: приложения как вектор атаки

Уроки атак на цепочку поставок

Атаки на цепочку поставок ПО стали одним из самых разрушительных векторов последних лет:

Инцидент	Дата	Механизм	Последствия
SolarWinds / SUNBURST	Дек 2020	Внедрение вредоносного кода в процесс сборки Orion	~18 000 организаций получили троянизированное обновление
Codecov	Янв–Апр 2021	Модификация Bash-скрипта загрузки через утёкший HMAC-ключ	Эксфильтрация CI-переменных 23 000+ клиентов
Dependency Confusion	Фев 2021	Публикация пакетов с высокими версиями в публичные реестры	35+ организаций, включая Apple, Microsoft, Tesla
Log4Shell (CVE-2021-44228)	Дек 2021	JNDI-инъекция в библиотеке логирования Apache Log4j	CVSS 10.0, миллионы Java-приложений
3CX	Мар 2023	Каскадная атака: компрометация X_Trader → компрометация 3CX	Первый публичный случай «атаки через атаку»
XZ Utils (CVE-2024-3094)	Мар 2024	Социальная инженерия для получения роли мейнтейнера за 3 года	CVSS 10.0, бэкдор в SSH через liblzma

Общий паттерн: злоумышленник компрометирует не целевую систему, а процесс создания или доставки ПО. Традиционный периметр бесполезен против кода, который приходит изнутри.

Нормативная база

EO 14028 (12 мая 2021): обязывает поставщиков федерального ПО предоставлять SBOM и следовать практикам SSDF (NIST SP 800-218).
EO 14144 (16 января 2025): расширяет требования — машиночитаемые аттестации безопасной разработки, аудит CISA.
NIST SP 800-218 (SSDF) v1.1 (февраль 2022): четыре группы практик — Prepare (PO), Protect (PS), Produce (PW), Respond (RV). Черновик v1.2 опубликован в декабре 2025.
NIST SP 800-228 (27 июня 2025): руководство по защите API в облачных системах — каждый API-вызов (внутренний или внешний) должен обрабатываться как потенциально ненадёжный.

13.2. Supply Chain Security

13.2.1. SBOM: инвентаризация компонентов

SBOM (Software Bill of Materials) — формальная запись компонентов ПО и их зависимостей. SBOM — это инвентаризация, а не отчёт об уязвимостях; уязвимости — отдельный слой (VEX, сканеры).

Два основных формата:

Критерий	CycloneDX	SPDX
Текущая версия	v1.7 (октябрь 2025)	v3.0.1 (декабрь 2025)
Стандартизация	ECMA-424, 2-е изд. (декабрь 2025)	ISO/IEC 5962:2021 (только v2.2.1)
Организация	OWASP / Ecma TC54	Linux Foundation
Форматы	XML, JSON, Protocol Buffers	JSON-LD, RDF, Tag-Value, XLSX
Область применения	SBOM, SaaSBOM, HBOM, AI/ML-BOM, VEX	SBOM, лицензионный анализ
Экосистема инструментов	219 (CycloneDX Tool Center)	470+ (широкая экосистема)

Оба формата признаны NTIA и CISA как допустимые для выполнения требований EO 14028. Выбор зависит от контекста: CycloneDX распространён в DevOps/CI-CD, SPDX — в регулируемых отраслях (финансы, здравоохранение, госсектор).

Важно: SPDX 3.0 ещё не является ISO-стандартом — ISO/IEC 5962:2021 покрывает только SPDX 2.2.1. Статус SPDX 3.0 в ISO — DIS (Draft International Standard).

Генерация SBOM в CI/CD (пример с Syft для CycloneDX):

bash

# Генерация SBOM из образа контейнера
syft packages registry.example.com/app:v1.2.3 \
  -o cyclonedx-json > sbom.cdx.json

# Сканирование SBOM на уязвимости через Grype
grype sbom:sbom.cdx.json --output json > vulns.json

13.2.2. Sigstore: подпись и верификация артефактов

Sigstore — проект OpenSSF (graduated, март 2024) для подписи, верификации и защиты артефактов ПО. Три компонента:

Cosign (v3.0.4, январь 2026): CLI для подписи контейнеров и OCI-артефактов.
Fulcio: удостоверяющий центр, выпускающий краткосрочные сертификаты на основе OIDC-идентичности.
Rekor: неизменяемый лог прозрачности, фиксирующий все подписи.

Keyless signing (рекомендуемый подход):

bash

# Подпись образа (keyless — откроет OIDC-авторизацию)
cosign sign $IMAGE

# Верификация с привязкой к идентичности (обязательно в v3)
cosign verify $IMAGE \
  --certificate-identity=ci@example.com \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

Механизм keyless signing:

Разработчик аутентифицируется через OIDC (GitHub, Google, Microsoft).
Fulcio выпускает краткосрочный сертификат (минуты), привязывающий эфемерный ключ к OIDC-идентичности.
Артефакт подписывается эфемерным ключом.
Приватный ключ уничтожается сразу после подписи.
Подпись и сертификат записываются в Rekor.
Верификация проверяет: запись в Rekor, валидность сертификата на момент подписи, совпадение OIDC-идентичности.

Внимание: Keyless signing не «безопаснее во всех случаях» — безопасность зависит от модели доверия OIDC-провайдера и строгости политик верификации. Для изолированных сред без доступа к публичным OIDC-провайдерам используйте key-based подпись.

Adoption в экосистемах пакетов:

Экосистема	Статус	Масштаб
npm	GA (сентябрь 2023)	500M+ загрузок пакетов с provenance
PyPI	GA (ноябрь 2024)	20 000+ аттестаций
Maven Central	Валидация подписей (январь 2025)	Опционально, параллельно с PGP
Homebrew	in-toto аттестации (май 2024)	Все формулы

13.2.3. SLSA: уровни зрелости сборки

SLSA (Supply-chain Levels for Software Artifacts) — фреймворк OpenSSF для оценки защищённости процесса сборки. Текущая версия — v1.2 (ноябрь 2025), обратно совместимая с v1.1.

Build Track (v1.0+):

Уровень	Название	Требования
L0	Нет гарантий	Нет требований SLSA
L1	Provenance	Платформа сборки автоматически генерирует provenance
L2	Build Service	Provenance подписан размещённой платформой сборки
L3	Hardened Builds	Строгая изоляция сборок, ключи подписи недоступны заданиям

Source Track (v1.2, ноябрь 2025): новый трек, покрывающий угрозы от авторства, ревью и управления исходным кодом. Source Level 2 фокусируется на истории и происхождении; Level 3 — на непрерывном соблюдении технических контролей.

Практическая реализация SLSA L2 в GitHub Actions:

yaml

# .github/workflows/build.yml
name: SLSA Build
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write    # Для OIDC-федерации
      contents: read
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t $IMAGE .
      - name: Sign with cosign (keyless)
        uses: sigstore/cosign-installer@v3
      - run: cosign sign $IMAGE
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: $IMAGE
          format: cyclonedx-json
      - name: Attest SBOM
        run: cosign attest --predicate sbom.cdx.json $IMAGE

13.3. Admission Control в Kubernetes

Admission control — механизм перехвата API-запросов к kube-apiserver после аутентификации и авторизации, но до сохранения в etcd. В модели Zero Trust admission control — это PEP (точка применения политик) для всех ресурсов кластера.

13.3.1. Pod Security Standards (PSS)

Замена устаревшего PodSecurityPolicy (удалён в Kubernetes 1.25). Три уровня, применяемые через лейблы namespace:

Уровень	Назначение	Ключевые ограничения
Privileged	Системные нагрузки	Нет ограничений
Baseline	Минимальная защита	Блокирует hostNetwork, hostPID, privileged-контейнеры
Restricted	Лучшие практики	runAsNonRoot, drop ALL capabilities, seccomp RuntimeDefault

Три режима применения:

enforce — отклоняет создание Pod
audit — записывает нарушения в audit log
warn — показывает предупреждение пользователю

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Применяем restricted: отклонение + аудит + предупреждение
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

13.3.2. OPA / Gatekeeper

OPA (Open Policy Agent) — CNCF Graduated (январь 2021), универсальный движок политик. Gatekeeper (v3.21.1, февраль 2026) — его реализация для Kubernetes через Validating Webhook.

Архитектура: два CRD-слоя:

ConstraintTemplate — определяет шаблон политики на Rego и параметры. Gatekeeper автоматически генерирует CRD из каждого шаблона.
Constraint — экземпляр сгенерированного CRD с конкретными значениями параметров.

yaml

# ConstraintTemplate: запретить контейнеры из недоверенных реестров
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sallowedrepos
spec:
  crd:
    spec:
      names:
        kind: K8sAllowedRepos
      validation:
        openAPIV3Schema:
          type: object
          properties:
            repos:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sallowedrepos
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          satisfied := [good | repo = input.parameters.repos[_];
                        good = startswith(container.image, repo)]
          not any(satisfied)
          msg := sprintf("container <%v> image <%v> not from allowed repos: %v",
                         [container.name, container.image, input.parameters.repos])
        }
---
# Constraint: разрешить только ghcr.io и registry.example.com
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: prod-allowed-repos
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces: ["production"]
  parameters:
    repos:
      - "ghcr.io/my-org/"
      - "registry.example.com/"

Gatekeeper v3.17+ поддерживает генерацию Kubernetes-нативных ValidatingAdmissionPolicy из ConstraintTemplate, используя CEL вместо Rego.

13.3.3. Kyverno

Kyverno (v1.17, 2 февраля 2026) — CNCF Incubating (с июля 2022), Kubernetes-нативный движок политик. Политики пишутся на YAML, без отдельного DSL.

Три типа правил:

validate — проверяет ресурсы, отклоняет несоответствующие
mutate — модифицирует ресурсы при создании (применяется до validate)
generate — автоматически создаёт дополнительные ресурсы (NetworkPolicy, ResourceQuota)

Kyverno 1.17: CEL-политики достигли GA (v1), ClusterPolicy (kyverno.io/v1) помечен как deprecated (удаление запланировано на 1.20, октябрь 2026).

yaml

# Kyverno: запрет latest-тегов и обязательные лейблы
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Image tag ':latest' запрещён. Используйте конкретный тег или digest."
        pattern:
          spec:
            containers:
              - image: "!*:latest"
    - name: require-team-label
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Label 'team' обязателен для всех Pod."
        pattern:
          metadata:
            labels:
              team: "?*"

13.3.4. Верификация образов при admission

Kyverno имеет встроенную поддержку верификации подписей через Cosign/Sigstore (verifyImages):

yaml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/my-org/*"
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.githubusercontent.com"
                    subject: "https://github.com/my-org/*"
          mutateDigest: true
          verifyDigest: true
          required: true

Для Gatekeeper верификация образов требует внешнего Data Provider (проект cosign-gatekeeper-provider архивирован; рекомендуемая альтернатива — github/artifact-attestations-opa-provider).

13.3.5. ValidatingAdmissionPolicy (VAP)

Начиная с Kubernetes 1.30, VAP — встроенный механизм валидации через CEL-выражения, работающий внутри API-сервера без внешних webhook:

yaml

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-non-root
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: >-
        object.spec.template.spec.containers.all(c,
          c.?securityContext.?runAsNonRoot == optional.of(true))
      message: "Все контейнеры должны запускаться как non-root"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: require-non-root-binding
spec:
  policyName: require-non-root
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: production

13.3.6. Сравнение подходов

Критерий	PSS	OPA/Gatekeeper	Kyverno	VAP
Язык политик	Лейблы namespace	Rego	YAML / CEL	CEL
Область	Pod security	Любые ресурсы K8s	Любые ресурсы K8s	Любые ресурсы K8s
Мутация	Нет	Да (с v3.10)	Да (нативно)	Нет (alpha в K8s 1.32)
Генерация ресурсов	Нет	Нет	Да	Нет
Верификация образов	Нет	Через external provider	Нативно (verifyImages)	Нет
Латентность	Встроенный	Webhook (сетевой hop)	Webhook (сетевой hop)	Встроенный (in-process)
Кроссплатформенность	K8s only	OPA работает вне K8s	K8s-focused	K8s only

Рекомендация: PSS как базовый уровень + Kyverno или Gatekeeper для расширенных политик. VAP — для простых правил без внешних зависимостей.

13.4. Безопасность API

13.4.1. OWASP API Security Top 10 (2023)

OWASP API Security Top 10 — приоритизированный список рисков API-безопасности (не стандарт, а консенсус сообщества). Редакция 2023 включает три новых пункта по сравнению с 2019:

Код	Риск	Связь с Zero Trust
API1	Broken Object Level Authorization (BOLA)	Нарушение принципа минимальных привилегий
API2	Broken Authentication	Слабая аутентификация, отсутствие MFA
API3	Broken Object Property Level Authorization	Избыточное раскрытие данных
API4	Unrestricted Resource Consumption	Отсутствие rate limiting
API5	Broken Function Level Authorization (BFLA)	Нечёткое разделение ролей
API6	Unrestricted Access to Sensitive Business Flows	⭐ Новый в 2023
API7	Server Side Request Forgery (SSRF)	⭐ Новый в 2023
API8	Security Misconfiguration	Ошибки конфигурации
API9	Improper Inventory Management	Теневые и устаревшие API
API10	Unsafe Consumption of APIs	⭐ Новый в 2023

13.4.2. API Gateway как PEP

В архитектуре Zero Trust API-шлюз выступает как точка применения политик (PEP), проверяя каждый запрос:

API Gateway выполняет пять проверок для каждого запроса:

#	Проверка	Описание
1	Аутентификация	JWT, mTLS, API key
2	Авторизация	scopes, claims, roles
3	Rate limiting	per identity, не только per IP
4	Валидация запроса	схема, payload
5	Аудит	логирование каждого решения

OAuth 2.0 и JWT:

Ключевые RFC:

RFC 9068 (октябрь 2021): профиль JWT для access-токенов OAuth 2.0 — стандартизированные claims (iss, exp, aud, sub, client_id).
RFC 9700 (январь 2025): Security BCP — PKCE обязателен для всех клиентов; Implicit Grant и Resource Owner Password deprecated.

yaml

# AWS API Gateway: JWT-авторизатор
# docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html
Resources:
  HttpApi:
    Type: AWS::ApiGatewayV2::Api
    Properties:
      Name: zero-trust-api
      ProtocolType: HTTP
  JwtAuthorizer:
    Type: AWS::ApiGatewayV2::Authorizer
    Properties:
      ApiId: !Ref HttpApi
      AuthorizerType: JWT
      IdentitySource: "$request.header.Authorization"
      JwtConfiguration:
        Issuer: "https://login.example.com/"
        Audience:
          - "api.example.com"

xml

<!-- Azure API Management: validate-jwt policy -->
<!-- learn.microsoft.com/en-us/azure/api-management/validate-jwt-policy -->
<inbound>
  <validate-jwt header-name="Authorization"
                failed-validation-httpcode="401"
                require-expiration-time="true"
                require-signed-tokens="true">
    <openid-config url="https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration" />
    <required-claims>
      <claim name="aud" match="any">
        <value>api://my-api</value>
      </claim>
    </required-claims>
  </validate-jwt>
</inbound>

13.4.3. Rate limiting

Rate limiting реализует защиту от OWASP API4:2023 (Unrestricted Resource Consumption). В модели Zero Trust лимиты привязываются к аутентифицированной идентичности, а не только к IP-адресу.

Основные алгоритмы:

Алгоритм	Описание	Применение
Fixed Window	Счётчик за фиксированное окно (100 req/min)	Простые сценарии
Sliding Window	Взвешенная комбинация текущего и предыдущего окон	Более плавное ограничение
Token Bucket	Токены добавляются с фиксированной скоростью; допускает всплески	Burst-трафик
Leaky Bucket	Запросы обрабатываются с постоянной скоростью; избыток отбрасывается	Строгая равномерность

13.4.4. mTLS для API

mTLS обеспечивает взаимную аутентификацию на транспортном уровне (см. главу 12). Для API-безопасности используется гибридный подход:

mTLS — аутентификация сервисной идентичности (кто вызывает).
OAuth 2.0 — авторизация на уровне приложения (какие действия разрешены).

Этот паттерн стандартизирован в RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens) и является основой Financial-grade API (FAPI).

13.4.5. WAF для защиты API

Облачные WAF обеспечивают дополнительный уровень защиты на основе правил OWASP CRS:

Провайдер	Набор правил	Ключевые возможности
AWS WAF	Managed Rules + Bot Control	OWASP CRS, rate-based rules, интеграция с API Gateway
Azure WAF	DRS 2.2 (на базе CRS 3.3.4)	18 групп правил + Microsoft Threat Intelligence
Google Cloud Armor	CRS 3.3.2	4 уровня чувствительности (paranoia levels), JSON body inspection до 64 KB

13.4.6. NIST SP 800-228: защита API в облачных системах

NIST SP 800-228 (27 июня 2025) устанавливает ключевые принципы:

Zero Trust для всех API: каждый вызов (включая внутренние microservice-to-microservice) требует аутентификации и авторизации.
Спецификация API: каждый API должен иметь описание в IDL (OpenAPI, gRPC, Thrift).
Валидация схемы: проверка request и response на соответствие спецификации.
Инвентаризация API: централизованный реестр всех API (внутренних и внешних) с владельцами, требованиями безопасности и метриками.
Инкрементальный подход: применение контролей на основе оценки риска.

13.5. Lab: Kyverno для Zero Trust admission control

Предварительные требования

Docker, kind, kubectl
Helm v3

Шаг 1: Создание кластера

bash

kind create cluster --name kyverno-lab

Шаг 2: Установка Kyverno

bash

# Добавление Helm-репозитория
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

# Установка Kyverno
helm install kyverno kyverno/kyverno \
  -n kyverno --create-namespace \
  --set admissionController.replicas=1 \
  --wait

Шаг 3: Настройка namespace

bash

kubectl create namespace production
kubectl label namespace production environment=production

Шаг 4: Политика — запрет latest-тегов

bash

cat <<'EOF' | kubectl apply -f -
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - production
      validate:
        message: "Тег ':latest' запрещён. Используйте конкретный тег."
        pattern:
          spec:
            containers:
              - image: "!*:latest & !*"
EOF

Шаг 5: Политика — обязательный label team

bash

cat <<'EOF' | kubectl apply -f -
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-team-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - production
      validate:
        message: "Label 'team' обязателен."
        pattern:
          metadata:
            labels:
              team: "?*"
EOF

Шаг 6: Политика — генерация NetworkPolicy deny-all

bash

cat <<'EOF' | kubectl apply -f -
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-default-deny
spec:
  rules:
    - name: deny-all-ingress
      match:
        any:
          - resources:
              kinds:
                - Namespace
              selector:
                matchLabels:
                  environment: production
      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny-ingress
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            podSelector: {}
            policyTypes:
              - Ingress
EOF

Шаг 7: Тестирование

bash

# Должен быть ОТКЛОНЁН (latest tag)
kubectl run test-latest --image=nginx:latest -n production
# Error: "Тег ':latest' запрещён..."

# Должен быть ОТКЛОНЁН (нет label team)
kubectl run test-no-label --image=nginx:1.27 -n production
# Error: "Label 'team' обязателен."

# Должен быть ПРИНЯТ
kubectl run test-ok --image=nginx:1.27 -n production \
  --labels="team=platform"
# pod/test-ok created

# Проверка сгенерированной NetworkPolicy
kubectl get networkpolicy -n production
# NAME                    POD-SELECTOR   AGE
# default-deny-ingress    <none>         ...

Шаг 8: Мониторинг PolicyReport

bash

# Просмотр результатов политик
kubectl get policyreport -A
kubectl get clusterpolicyreport -o yaml

Очистка

bash

kind delete cluster --name kyverno-lab

13.6. Итоги

Направление	Ключевой инструмент	Принцип Zero Trust
Supply chain	SBOM + Sigstore + SLSA	Верификация происхождения каждого артефакта
Admission control	PSS + Kyverno/Gatekeeper	Deny-by-default для всех ресурсов кластера
API security	OAuth 2.0 + API Gateway + WAF	Аутентификация и авторизация каждого вызова

Безопасность приложений — четвёртый столп CISA ZTMM. В следующей главе мы углубимся в Kubernetes: RBAC, NetworkPolicy, полный Zero Trust-стек от SPIRE до Vault (глава 14).

Источники:

NIST SP 800-218 (SSDF) v1.1: csrc.nist.gov/pubs/sp/800/218/final
NIST SP 800-228: csrc.nist.gov/pubs/sp/800/228/final
OWASP API Security Top 10 (2023): owasp.org/API-Security/editions/2023/en/0x11-t10/
SLSA v1.2: slsa.dev/spec/v1.2/
Sigstore docs: docs.sigstore.dev
Kyverno docs: kyverno.io/docs/
Gatekeeper docs: open-policy-agent.github.io/gatekeeper/website/docs/
Kubernetes PSS: kubernetes.io/docs/concepts/security/pod-security-standards/
Kubernetes VAP: kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
RFC 9068: datatracker.ietf.org/doc/html/rfc9068
RFC 9700: datatracker.ietf.org/doc/rfc9700/
EO 14028: nist.gov/itl/executive-order-14028-improving-nations-cybersecurity
CycloneDX v1.7: cyclonedx.org/specification/overview/
SPDX 3.0.1: spdx.github.io/spdx-spec/v3.0.1/

Глава 13. Безопасность приложений ​

13.1. Зачем: приложения как вектор атаки ​

Уроки атак на цепочку поставок ​

Нормативная база ​

13.2. Supply Chain Security ​

13.2.1. SBOM: инвентаризация компонентов ​

13.2.2. Sigstore: подпись и верификация артефактов ​

13.2.3. SLSA: уровни зрелости сборки ​

13.3. Admission Control в Kubernetes ​

13.3.1. Pod Security Standards (PSS) ​

13.3.2. OPA / Gatekeeper ​

13.3.3. Kyverno ​

13.3.4. Верификация образов при admission ​

13.3.5. ValidatingAdmissionPolicy (VAP) ​

13.3.6. Сравнение подходов ​

13.4. Безопасность API ​

13.4.1. OWASP API Security Top 10 (2023) ​

13.4.2. API Gateway как PEP ​

13.4.3. Rate limiting ​

13.4.4. mTLS для API ​

13.4.5. WAF для защиты API ​

13.4.6. NIST SP 800-228: защита API в облачных системах ​

13.5. Lab: Kyverno для Zero Trust admission control ​

Предварительные требования ​

Шаг 1: Создание кластера ​

Шаг 2: Установка Kyverno ​

Шаг 3: Настройка namespace ​

Шаг 4: Политика — запрет latest-тегов ​

Шаг 5: Политика — обязательный label team ​

Шаг 6: Политика — генерация NetworkPolicy deny-all ​

Шаг 7: Тестирование ​

Шаг 8: Мониторинг PolicyReport ​

Очистка ​

13.6. Итоги ​

Глава 13. Безопасность приложений

13.1. Зачем: приложения как вектор атаки

Уроки атак на цепочку поставок

Нормативная база

13.2. Supply Chain Security

13.2.1. SBOM: инвентаризация компонентов

13.2.2. Sigstore: подпись и верификация артефактов

13.2.3. SLSA: уровни зрелости сборки

13.3. Admission Control в Kubernetes

13.3.1. Pod Security Standards (PSS)

13.3.2. OPA / Gatekeeper

13.3.3. Kyverno

13.3.4. Верификация образов при admission

13.3.5. ValidatingAdmissionPolicy (VAP)

13.3.6. Сравнение подходов

13.4. Безопасность API

13.4.1. OWASP API Security Top 10 (2023)

13.4.2. API Gateway как PEP

13.4.3. Rate limiting

13.4.4. mTLS для API

13.4.5. WAF для защиты API

13.4.6. NIST SP 800-228: защита API в облачных системах

13.5. Lab: Kyverno для Zero Trust admission control

Предварительные требования

Шаг 1: Создание кластера

Шаг 2: Установка Kyverno

Шаг 3: Настройка namespace

Шаг 4: Политика — запрет latest-тегов

Шаг 5: Политика — обязательный label team

Шаг 6: Политика — генерация NetworkPolicy deny-all

Шаг 7: Тестирование

Шаг 8: Мониторинг PolicyReport

Очистка

13.6. Итоги