- Переработана структура репозитория
- Исправлены неучтенные материалы
- Изменены пути для лабораторных работ, дополнительных материалов и примеров кейсов ИБ (планирую также долить далее тар архивы имеджей и тд, для лабки по докеру)
- Изменены 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»
- Рекомендуется выполнять централизованное хранение всех логов стадии сборки и журналов событий конвейеров для последующего аудита и анализа