Приложение с открытым исходным кодом (детальная дока допом к посту), разработанное компанией Netflix Security, которое намеренно реализует отказ в обслуживании для инстансов в production среде. Имеет высокую требовательность к зрелости процессов внутри компании и к компетенциям администраторов инструмента. Для корректного тестирования сам инструмент и нагружаемые приложения должны администрироваться в Spinnaker - CI/CD платформы, используемой оффициальными разработчиками. Тип лицензии: Apache License 2.0.

- Имитация отказа в обслуживании инфраструктуры
- Выявление узкого горлышка в архитектуре
- Проверка узлов системы на избыточное дублирование
- Контроль падений каждого из серверов и детализация информации как это влияет на системы
- Принудительные контроли и реализация health-check, включая A/C таймапов
- Имитация нагрузочного тестирования и стресс-тестов , включая проверка нагрузки типов портов 429 и тд.

$ go get github.com/netflix/chaosmonkey/cmd/chaosmonkey

# Поставить Halyard
$ curl -O https://raw.githubusercontent.com/spinnaker/halyard/master/install/debian/InstallHalyard.sh
$ sudo bash InstallHalyard.sh
$ hal config features edit --chaos true
$ hal config version edit --version $VERSION

# Проверка соединения с Spinnaker
$ chaosmonkey config spinnaker

# С установленным Spinnaker
$ sudo nano /opt/deck/html/settings.js

# Ставим для специального параметра значение True
$ var chaosEnabled = true

# Ручная остановка инстансов с заданными параметрами
$ chaosmonkey terminate   [--stack=] [--cluster=] [--leashed]

- Инструмент, поддерживает только совместимое со Spinnaker - AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry
- Инструмент достаточно старый. Решение вышло еще в 2011 году и способно вырубать один инстанс за раз. С учетом текущих масштабов инфраструктуры есть необходимость проведения chaos сканирования в гораздо большем масштабе. Так, логическое продолжение инструмента - Chaos Kong может проводить проверку отказоустойчивости гораздо большего масштаба, например, отрубая один из регионов AWS. Сам Chaos Kong рассмотрим дальше

— Секреты и ключи: .env, *.pem, *.key, id_rsa, как полный доступ к БД, серверам, API, приватные ssh ключи
— Конфигурации с паролями: config/*.json, settings.yml, как утечка учётных данных и внутренних настроек
— Данные пользователей: *.sqlite, *.db, exports/, как утечка персональных данных
— Служебные файлы системы и IDE: .git/, .idea/, .vscode/, как раскрытие истории изменений, путей, логинов
— Временные и кэш-файлы: tmp/, cache/, __pycache__/, как утечка отладочной информации

- Аналогичный формат для helm-чартов. Все описаное для dockerignore также верно и для .helmignore

— Баз данных
— Файлов, образующихся в процессе и результате компиляции проекта вроде target/, output/, release/, debug/
— Разные сторонние инструменты
— Файлы, генерируемые тестовым фреймворком, профилировщиком, дебаггером и т.п.
— Сгенерированная из кода документация только в отдельный удаленный репозиторий, через который потом развертываете сайт с документацией (пример mkdocs + gpages)
— Файлы, создаваемые при выполнении кода: журналы (*.log), результаты работы и т.п.
— Временные файлы текстового редактора или среды разработки типа *~.
— Файлы, создаваемые операционной системой, например thumbs.db, .DS_Store

- Необходимо реализовать раздельные CI workflow для каждого контура внутри стендов, как пример DEV, TEST, CERT, PROD и тд
- Все секреты и ключи должны использоваться только через одобренные переменные CI/CD
- Хранение секретов в коде, в репозитории или в конфигурационных файлах запрещено. В случае обнаружения секретов в MR, пайплайн должен автоматически блокировать merge/ pull
- Неиспользуемые сервисы должны быть отключены, брандмауэр настроен и ограничен сетевой доступ к инстансу
- Доступ должен осуществляться исключительно по протоколу TLS 1.3 с современными шифрами. Использование HTTP или устаревших алгоритмов шифрования запрещено
- Все Runner'ы должны быть размещены в изолированных сетях с строгим контролем исходящего трафика

- Доступ в интернет должен быть запрещен по умолчанию и предоставляться только выделенным Runner'ам через прокси-серверы с white-list фильтрацией по FQDN для загрузки исключительно необходимых зависимостей
- Должен быть разработан и поддерживаться Disaster Recovery Plan (DRP), включая периодическую проверку восстановления
- База данных должна размещаться в отдельном инстансе/ кластерe, с ограничением доступа только для серверов repo hpsts с применением шифрования

- Развёртывание repo host в выделенном серверном сегменте VLAN с ограниченным входом только по HTTPS/SSH с рабочих сетей и из сегмента раннеров
- Белые списки должны быть только реализованы для доверенных пользователей и только через сторонний jump сервер и/или песочницу
- Использовать отдельные VM, а также кластера под Web UI, API, Sidekiq тд, включая отдельный экземпляра для PostgreSQL, Redis и тд либо управляемых сервисов БД, кэша
- Необходимо достичь отказа от «all‑in‑one» на PROD
- Обязательное включение HTTPS с внутренним корпоративным PKI, запрет plain HTTP, настройка HSTS и TLS 1.3
- Необходима реализация для ограничения протоколов, шифров по корпоративному криптопрофилю
- Необходимо использование 2FA, SSO при IdP, а также принудительная 2FA политика для всех пользователей
- Использование только сильных ключей SSH Ed25519, RSA с достаточной длиной, реализовать запрет DSA

— bastion‑узлов: админ‑доступ (Web, SSH для root/ maintenance) только из jump‑host’ов
— Inbound: HTTPS (443)/SSH (22) с рабочих подсетей, сегмента раннеров
— Outbound: только к корпоративному SMTP, мониторингу/ логам, внутреннему Nexus/ registry, внешнему интернету через прокси при необходимости зависимости, с явным egress‑ACL

— Размещение в отдельном сегменте «CI‑runner zone» с доступом Outbound к GitLab по HTTPS/SSH (API для регистрации, получения job, push артефактов)
— Размещение в отдельном сегменте «CI‑runner zone» с доступом Outbound к Nexus/иному артефакт‑репозиторию только по нужным портам (например, 8081/8082 для HTTP(S))
— Запрет прямого доступа раннеров к боевым БД и внутренним бизнес‑сервисам, кроме явно необходимых для тестов стендов
— Outbound к Интернету — через прокси и только для скачивания зависимостей/ баз уязвимостей; при возможности использовать зеркала в Nexus
— Inbound к раннерам: закрыт (только инициатива от раннера к GitLab/Nexus); управляющее соединение runner → GitLab по HTTPS

— Inbound: доступ только из сегмента раннеров и, при необходимости, из сегмента сборочных серверов/релиз‑оркестраторов
— Outbound: к внешним central‑репозиториям (Maven Central, PyPI, npm и т.п.) через контролируемый прокси; к Internet — только через egress‑фильтрацию и инспекцию

- При построении ACL использовать принцип белых списков: запрещено всё, что не разрешено явно
- Сетевой трафик между всеми сегментами VLAN должен быть запрещен по умолчанию
- Административный доступ (SSH, RDP, доступы к DB и тд.) ко всем узлам во всех сегментах должен быть разрешен только со специально выделенного сегмента управления Management VLAN
- Должна соблюдаться четкая классификация всех проектов в соответствии с уровнем конфиденциальности данных: Private (конфиденциальные данные), Internal (внутренняя информация), Public (открытые данные)
- Видимость проекта не может быть менее строгой, чем видимость родительской группы
- Не привилегированным пользователям должно быть доступно создание только Private репозиториев
- В защищённых ветках должно быть запрещено выполнение force push
- Запрос на слияние должен быть выполнен только при успешном прохождении всех проверок
- Рекомендуется включать этап проверки подписи коммитов в конвейер CI/CD
- Артефакты CI/CD должны храниться в корпоративных зашифрованных хранилищах с ограничением срока жизни (пример S3)
- Доступ к изменению конфигурации CI/CD должен быть строго ограничен, а сами изменения должны отслеживаться
- Необходимо использовать защиту тегов для контроля над развертыванием и выпуском версий
- Джобы, работающие с секретами или производящие сборку для продакшена, должны запускаться на выделенных раннерах со строгим контролем доступа
- Видимость секретов, хранящихся в переменных CI/CD должны быть «masked and hidden»
- Рекомендуется выполнять централизованное хранение всех логов стадии сборки и журналов событий конвейеров для последующего аудита и анализа

Это инструмент для статического анализа (SAST) инфраструктуры как кода (IaC), который сканирует конфигурации на предмет ошибок безопасности и соответствия стандартам до их развертывания. Open-source (Apache 2.0). Форматы отчетов: CLI, JSON, JUnit XML, GitHub Failed Only, GitLab SAST, SARIF, CSV, CycloneDX.

• Анализирует Terraform, CloudFormation, Kubernetes‑манифесты, Dockerfile и другие инфраструктурные файлы на ошибки конфигурации
• Подходит для автоматической проверки Docker/IaC в пайплайнах, чтобы не пропускать небезопасные настройки в образах и инфраструктуре
• Может использоваться для быстрой проверки конфигураций перед коммитом, чтобы исключить базовые misconfiguration
• SARIF → GitHub Security, GitLab SAST
• JSON → DefectDojo, Jira
• Поддержка как атрибутных (на Python), так и графовых (на YAML) политик для анализа взаимосвязей ресурсов

pip install checkov
 
# Сканирование директории
checkov -d /path/to/terraform/code
 
# Запуск только определенных проверок (по ID или severity)
checkov -d . --check CKV_AWS_20,CKV_AWS_57
checkov -d . --check HIGH
 
# Пропуск определенных проверок
checkov -d . --skip-check CKV_AWS_20
 
# Вывод в формате JUnit XML (для CI/CD)
checkov -d . -o junitxml > checkov.xml
 
# Сканирование с загрузкой внешних Terraform модулей
checkov -d . --download-external-modules true
 
# Подавление конкретной проверки в коде (inline comment) checkov:skip=CKV_AWS_20
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  acl    = "private"
}

stage('Checkov') {
  steps {
    script {
      docker.image('bridgecrew/checkov:latest').inside("--entrypoint=''") {
        unstash 'terragoat'
        try {
          sh '''
            checkov -d . --use-enforcement-rules -o cli -o junitxml \
              --output-file-path console,results.xml \
              --repo-id example/terragoat --branch master
          '''
          junit skipPublishingChecks: true, testResults: 'results.xml'
        } catch (err) {
          junit skipPublishingChecks: true, testResults: 'results.xml'
          throw err
        }
      }
    }
  }
  options {
    preserveStashes()
    timestamps()
  }
}

enforcement_rules:
  - name: "prod-enforcement"
    description: "Строгие политики для прод-веток: блокируем Critical/High, предупреждаем по Medium."
    is_default: true
    criteria:
      provider: "terraform"          # к каким сканам применяем
      filter:
        # пример — применять к репо terragoat в ветке master/main
        repo_id: "example/terragoat"
        branches:
          - "master"
          - "main"
    rules:
      - rule_id: "CKV_AWS_*"         # все AWS-политики
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

      - rule_id: "CKV_K8S_*"         # все политики по Kubernetes
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

      - rule_id: "CKV_SECRET_*"      # поиск секретов
        soft_fail_threshold: "LOW"
        hard_fail_threshold: "MEDIUM"

  - name: "dev-relaxed"
    description: "Более мягкие политики для dev/feature-веток."
    is_default: false
    criteria:
      provider: "terraform"
      filter:
        branches:
          - "develop"
          - "feature/*"
    rules:
      - rule_id: "CKV_AWS_*"
        soft_fail_threshold: "HIGH"   # Medium только как инфо
        hard_fail_threshold: "CRITICAL"

      - rule_id: "CKV_K8S_*"
        soft_fail_threshold: "HIGH"
        hard_fail_threshold: "CRITICAL"

      - rule_id: "CKV_SECRET_*"
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

• Анализируем Dockerfile и Helm-чарты как основной слой упаковки
• Фильтруем предупреждения по enforce/ skip, quiet: false
• Срабатывание в разделе enforce будем считать ошибкой пайплайна
• Для dev-веток переопределяем флагом в CI ошибки как soft-fail: true/ false
• Запрещаем автоматическое скачивание модулей и делаем меньше сетевых зависимостей - download_external_modules: false
• Формируем «белый список» security-политик - run_all_checks: false

enforce:
  docker:
    - CKV_DOCKER_2      # Контейнер не должен запускаться под root
    - CKV_DOCKER_3      # Минимизировать лишние пакеты и слои
    - CKV_DOCKER_5      # Избегать образов с тегом latest без необходимости
    - CKV_DOCKER_7      # Не использовать ADD вместо COPY
    - CKV_DOCKER_8      # Явно задавать non-root пользователя
    - CKV_DOCKER_9      # Удалять временные файлы, кеши, package manager metadata
    - CKV_DOCKER_10     # Обязательный healthcheck для оркестраторов (k8s, swarm) и SLA
    - CKV_DOCKER_12     # Не хранить секреты в ENV/ ARG/ лейблах образа
    - CKV_DOCKER_13     # Запрет запуска контейнера в privileged режиме
    - CKV_DOCKER_14     # Ограничить Linux capabilities: drop ALL
    - CKV_DOCKER_16     # read-only root filesystem

  helm:
    - CKV_K8S_11         # networkPolicy для контролируемого трафика между подами
    - CKV_K8S_20        # spec.securityContext.privileged: false
    - CKV_K8S_37        # runAsNonRoot: true, runAsUser != 0
    - CKV_K8S_40        # Не хранить чувствительные данные в явном виде в values/ ConfigMap
    - CKV_K8S_14        # hostNetwork/hostPID/hostIPC должны быть false
    - CKV_K8S_38        # securityContext.capabilities: drop ALL, запрещены SYS_ADMIN и подобные
    - CKV_K8S_22        # readOnlyRootFilesystem: true
    - CKV_K8S_8         # Требовать requests/ limits для CPU и памяти

directory:
  # Директория анализа
  - .

file:
  - vulnerable-app/Dockerfile
  - docker-compose.yml
  
# Helm-чарты:
  - helm/service/values.yaml
  - helm/service/templates/deployment.yaml

# skip_check:
#  - CKV_DOCKER_5  # образ тестовой среды жёстко привязан к latest (exmpl)

 policy:
   docker:
     require_non_root_user: true  # USER != root
     require_healthcheck: true # HEALTHCHECK
     require_explicit_user: true # Указание USER
     forbid_secrets_in_env: true # ENV/ARG != pswrd/ token
     forbid_default_credentials: true # Запрет admin/admin и т.д.
     drop_all_capabilities_by_default: true # CAP_* по минимуму
     forbid_privileged: true # privileged: false
     forbid_host_network: true # hostNetwork: false
     prefer_read_only_rootfs: true # rootfs read-only

   helm:
     require_pod_security_context: true  # securityContext
     require_network_policies: true # networkPolicy
     forbid_host_path_mounts: true # hostPath монтируется по approve-list
     require_resource_limits: true # requests/limits заданы
     forbid_plaintext_secrets: true  # секреты не хранятся в values.yaml/ConfigMap

• Контекст реального запуска, где уязвимость видна только с учётом данных, конфигурации, фич‑флагов и окружения
• Важен рабочий вектор атаки, как payload в эффект: RCE, LFI, доступ к данным
• Используются логи, трассировки, RASP/ IAST: видно, какой запрос, какая функция и какие данные дошли до опасной операции
• Баги после авторизации: IDOR, эскалация прав, злоупотребление легальными функциями
• Уязвимость специфична для прод‑конфигурации: IAM, сеть, секреты, версии сервисов
• Уязвимость уже в проде, есть PoC и нужны временные меры до фикса кода

Инъекции — класс уязвимостей, где данные попадают в интерпретатор как часть команды или запроса с изменением смысла. Возникает уязвимость, когда приложение не валидирует ввод, а также строит динамические запросы конкатенацией строк. Уязвимость использует данные напрямую в интерпретаторах без параметризации и экранирования. Конкатенация строк — это соединение строк в одну без изменения содержимого.

- id: java-sqli-concat-critical
    languages: [java]
    severity: CRITICAL
    message: |
      OWASP A03:2024 (Injection) — возможная SQL-инъекция через конкатенацию
      строк. Используйте PreparedStatement с параметрами.
    patterns:
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.executeQuery("SELECT " + $VAR);
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.execute("SELECT " + $VAR);
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.executeUpdate("SELECT " + $VAR);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-89"]
      likelihood: "HIGH"
      impact: "HIGH"

  - id: java-sqli-prepared-misuse-high
    languages: [java]
    severity: HIGH
    message: |
      OWASP A03:2024 (Injection) — PreparedStatement. 
      Используйте плейсхолдеры '?' и setXxx().
    pattern: |
      PreparedStatement $PSTMT = $CONN.prepareStatement("SELECT " + $VAR + " FROM " + $TABLE);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-89"]
      likelihood: "MEDIUM"
      impact: "HIGH"

  - id: java-os-command-injection-runtime
    languages: [java]
    severity: CRITICAL
    message: |
      OWASP A03:2024 (Injection) — возможная командная инъекция через
      Runtime.getRuntime().exec()
    patterns:
      - pattern: |
          Runtime.getRuntime().exec($CMD);
      - pattern: |
          Runtime.getRuntime().exec(new String[] { $A, $B, $C });
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-78"]
      likelihood: "HIGH"
      impact: "CRITICAL"

  - id: java-expression-language-injection
    languages: [java]
    severity: HIGH
    message: |
      OWASP A03:2024 (Injection) — динамическая компиляция/ выполнение выражений.
    patterns:
      - pattern: |
          new org.springframework.expression.spel.standard.SpelExpressionParser()
            .parseExpression($EXPR).getValue($CTX);
      - pattern: |
          $ENGINE.eval($EXPRESSION);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-94"]

- Вводит default‑deny egress для Pod’ов, кроме DNS и FQDN, чтобы скомпрометированный сервис не мог свободно сливать данные
- CiliumClusterwideNetworkPolicy задаёт жёсткий baseline для всего кластера и базовую защиту multi-tenant
- Ограничивает пути до backend только для БД и конкретных API, а frontend для namespaces
- На L7 (HTTP, gRPC, DNS, SQL‑протоколы, запросы/ методы/ URL внутри трафика) разрешает только определённые методы, тем самым уменьшая API и предотвращая вызовы

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
meta
  name: "cluster-baseline-default-deny-egress"
spec:
  description: |
    Кластерный baseline:
      - DNS (kube-dns/CoreDNS);
      - явный список внешних эндпоинтов

  # Политика применяется ко всем endpoint'ам в кластере
  # если CNP не переопределяет узким matchLabels
  endpointSelector:
    matchLabels: {}

  egress:
    # namespace kube-system
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*"  # любые домены

    # трафик к ограниченному списку внешних хостов
    - toFQDNs:
        - matchName: "api.payment.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

  # default-deny для egress
  egressDeny:
    - {}

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
meta
  name: "app-frontend-backend-policy"
  namespace: "app-namespace"
spec:
  description: |
      - ingress: только от frontend к backend
      - egress backend'а: только к БД и внешнему API
      - L7 принимает безопасный набор методов

  # backend‑pods по метке
  endpointSelector:
    matchLabels:
      app: my-backend

ingress:
    # трафик от Pod'ов с app=my-frontend
    - fromEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": app-namespace
            app: my-frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "^/healthz$"
              - method: "GET"
                path: "^/api/public/.*$"
              - method: "POST"
                path: "^/api/orders$"
              - headers:
                 - "X-API-KEY: .+"

  egress:
    # backend'у к базе данных в том же namespace
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": app-namespace
            app: my-database
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP  # PostgreSQL
    # доступ к внешнему API ограниченному кластерным CNP по FQDN
    - toFQDNs:
        - matchName: "api.payment.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP