Комментарии 3
Из статьи напрашивается вывод "не использовать Jenkins"
Выглядит, что правда самым безопасным было бы прекратить использовать Jenkins. Это уже устаревший инструмент с архитектурой которая не менялась более 15 лет. На текущий момент тот же GitLab из коробки дает больше возможностей, чем Jenkins с любыми плагинами
Не соглашусь - любой инструмент требует правильного применения.
Jenkins такой же инструмент, как и GitLab, упомянутый в другом комменте. Если вы посмотрите на раздел документации GitLab Security Hardening, то там тоже много пунктов что и как правильно стоит делать.
Если вернемся к итогам из статьи:
Следить за CVE и уязвимостями надо как в Jenkins, так и в GitLab (или любом другом продукте)
Делать отдельный инстанс для тестов обновлений - вариант нормы в любом продукте
Разграничивать CI/CD - тема для рассуждений "как правильно", бывают варианты
Подписывать артефакты тоже нужно - на gitlab схема supply chain attack также может быть применена. В зависимости от инсталляции и интеграции могут быть кейсы более или менее успешной атаки
Внешняя аутентификация - чаще всего ее делают в больших инсталляциях в любом случае, для удобства
Защита от CSRF и XSS - должна быть, возможно в GitLab, она просто включена из коробки
В GitLab через бездумное создание джоб также тоже много чего можно поделать
Еще хотел бы подсветить, что не совсем корректно сравнивать GitLab и Jenkins:
GitLab это комбайн, который умеет много чего (хранение код, сборка и т.д.)
Jenkins это специализированный инструмент под конкретный вид задач
Каждый имеет плюсы и минусы, разные концепции применения и реализации самого инструмента. Однозначного лидера, на мой взгляд нет.
Hardening Jenkins: как подать блюдо, чтобы оставили чаевые