Комментарии 6
TL;DR — вот какой вывод должен быть из статьи. Много воды. Никакой практики. Для себя как для разработчика ничего не вынес, кроме каких-то прописных истин. Ну, и то, что коллеги из Джета могут построить процесс
Но лучше рекламой был бы пример реально выстроенной модели безопасности контейнерищированного приложения от А (пуша в гит) до Я (выкладки в продакшн, и не забываем, что реально жизненный цикл приложения заканчивается не на этом, а после эксплуатации — вывод его из оборота).
очень много всего, что можно сделать для devsecops, краткий неполный список:
1. золотые образы ОС должны приходить от безопасников после security hardening
2. endpoint security (tanium), логгирование (splunk), сканер уязвимостей (qualys, nessus), IAM (centrify) должны быть внедрены в образ ОС
3. исходный код должен проходить через стат анализатор кода
4. все сторонние библиотеки для разработчиков должны раздаваться из центрального artifactory, после прохождения аудита
1. золотые образы ОС должны приходить от безопасников после security hardening
2. endpoint security (tanium), логгирование (splunk), сканер уязвимостей (qualys, nessus), IAM (centrify) должны быть внедрены в образ ОС
3. исходный код должен проходить через стат анализатор кода
4. все сторонние библиотеки для разработчиков должны раздаваться из центрального artifactory, после прохождения аудита
НЛО прилетело и опубликовало эту надпись здесь
Привет с инфорсера, Лёх, очень много воды) давай кейсов в следующий раз)
Будем считать, статья вводная.
Следующий пост планируем накатать с кейсами и смешной историей изнасилования кластера OpenSHift на глазах RedHat'а :)
Следующий пост планируем накатать с кейсами и смешной историей изнасилования кластера OpenSHift на глазах RedHat'а :)
К сожалению, пришлось пропускать целые абзацы из-за их неинформативности. Многообещающее начало, ждал уже реальных действий, а их не последовало…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасность контейнеров в CI/CD