- Переработана структура репозитория
- Исправлены неучтенные материалы
- Изменены пути для лабораторных работ, дополнительных материалов и примеров кейсов ИБ (планирую также долить далее тар архивы имеджей и тд, для лабки по докеру)
- Изменены shields и проставлены линки для них на репу, сурсы
- Кастомизирован пайп под лабораторные работы и их содержание, ты сможешь почекать его и посмотреть также как правильно выстраивать сам пайп для сборки через GitHub Actions
- Доработаны стили для читаемости отображаемого кода и clipboard
- Проработан адаптив и сайзинг под широкие экраны
- Допилена контентная часть
- Подсказки и приложения дополнены
- и тд

DevSecOps Toolchain Map — это интерактивная карта инструментов для DevSecOps и тулов AppSec, помогающая архитекторам, безопасникам и разработчикам осознанно собирать и эволюционировать свой security‑toolchain, а не «тащить всё подряд». Проект фокусируется на практическом применении: от минимального набора инструментов «в одного человека» до комплексных ландшафтов в крупных организациях.

Суть карты в том, что она помогает подобрать оптимальные решения под любые условия: когда нет бюджета, когда невозможно внедрить тяжёлую корпоративную платформу, когда команда маленькая или приходится закрывать все роли в одиночку и т.д.

- полностью переработанная версия и стилизация на базе mkdocs в описанном

релизе v2.0.0

- вот

тут

ты можешь посмотреть на карту и скачать ее в PDF для себя, она автоматизирована и при изменении состава карты - актуализируется
- вот

тут

ты можешь покликать интерактивную карту инструментов и посмотреть какие есть описанные данные
- вот

тут

ты можешь воспользоваться картой с свободным поиском и по категориям
- вот

тут

вывел список всех основных лицензий, которые считаю важными для ознакомления и ты можешь почитать у меня в канале про них #licenses
- привел список православных, зарубежных вендоров и крупных open-source проектов
-

справка

по типам инструментов

Приложение с открытым исходным кодом (детальная дока допом к посту), разработанное компанией 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"