ок. еще раз финализируем
- внешний сканер уязвимостей в публичном образе должен показывать что у вас ВСЕ ЧИКИ ПУКИ
- уязвимости в образе которые тащатся через зависимости
- root в контейнере и всякие бинарники типа tcpdump и mcedit
- размер образа
- образ долго собирается в ci/cd

вот так все выглядит?

Да

можно посканить не только публичный образ но и приватный. У публичного доступны исходники, чтобы поковыряться и применить логику..

Почему у тебя значимые вещи типа артефактов собираются в after_script вообще? 😳

да там не артефакты на самом деле

и я уже вроде перераспределил всё )

- внешний сканер уязвимостей в публичном образе должен показывать что у вас ВСЕ ЧИКИ ПУКИ
перед docker publish
делаем docker scan
см. https://docs.docker.com/engine/scan/
или
https://github.com/aquasecurity/trivy

для которого даже github actions есть
https://github.com/aquasecurity/trivy-action

или
https://github.com/anchore/grype
https://github.com/marketplace/actions/anchore-container-scan

а лучше все вместе это в паралели запускать
и делать FAIL если что-то не так


- уязвимости в образе которые тащатся через зависимости
см. предыдущий пункт + snyk.io сканирование исходников

и https://www.defectdojo.org/ какой нибудь в который результаты сканирования сгружать и показывать динамику руководству...

- root в контейнере и всякие бинарники типа tcpdump и mcedit
для контроллируемого тобой environment
отрубается через
kubernetes securityContext в podTemplate
у Deployment, DaemonSet

для неконтроллируемого
опять банально

grep "RUN addgroup -S -g 101 rootles" Dockerfile 
grep "USER rootless" Dockerfile 

- размер образа
https://github.com/docker-slim/docker-slim
может решить проблемы левых бинарников
но нужны какие то e2e тесты чтобы понять что лишнее в образе

- образ долго собирается в ci/cd
свои базовые образа и всякие паралельные сборки с кешированием
или отдельные сборщики типа
https://github.com/genuinetools/img

вон вроде werf от фланта как то очень хитро пытается собирать образ


твое решение, хреново тем что если у вас публичный образ
то по факту вы свое приложение непонятно как тогда распостраняете
у вас откуда то должен будет взяться артифакт с исходниками
(.deb \ .rpm пакеты с исходниками?)
и это все будет ставиться в runtime, что неприемлимо с точки зрения контейнеризированного окружения
там все артефкты для запуска кроме секретов и юзерских настроек - они build time

Ой всё. Спасибо за развёрнутое описание и ссылочки. Сохранил, почитаю.

Вообще, выглядит так, будто взяли хорошую devops-практику(контейнеризация и иммутабельное приложение вместе с его окружением) и затащили ее в привычное противостояние разработки и эксплуатации. Пытаетесь пользовать контейнеры как виртуалки. ИМХО - докер-образ должен быть в зоне ответственности разработчика т.к. это и есть неотделимая часть приложения. А бороться надо уже с попытками вытолкать уязвимое приложение в то место где у вас хранятся приложения(регистри в данном случае). Это обычно делается как раз с помощью сканирований и тестов где-то между сборкой и registry push.

если соберешь сей адский конструктор, получишь компетенции devsecops ;)

Хорошее обозначение "адский конструктор". Кодовое название "Люцифер" 😁

Дарю, использую с 2012 года, со времен LinguaLeo ;)
весь современный софт именно такое впечатление  и производит
гигантская куча бесполезного и плохо стыкующегося между собой какахена...

Стареешь 😂

Всем доброго дня!
Можт есть у кого на продажу Unifi Cloud Key?

Вот так лучше

​Вакансия DevOps
Ребята не обращались, но как тут не помочь.
Вот их инста: https://www.instagram.com/p/CQaotWJD5H3/

Уже даже на VC это постили ;)

😁😁

Астрологи объявили неделю интереса бабуль и дедуль к айти.
Спрос на инфоциганские курсы вырос в 2 раза.

Хайпанули ребята. Круто сработали хры или маркетологи или кто у них там