Всем привет!
Первая статья, посвященная тому, как Lyft выстраивали процесс управления уязвимостями в образах контейнеров и с какими трудностями они столкнулись.
Команда создала собственный концепт, который строится на идеях:
🍭 Самостоятельное устранение уязвимостей там, где это возможно (spoiler: почти не работает). Постановка задач на устранение только в том случае, если у уязвимости есть fix
🍭 Автоматизация всего, чего только можно. Заодно можно будет узнать, почему ребята перешли с Clair на Trivy
🍭 Что делать, если в компании используется базовый образ, на основе которого могут строиться остальные? Как сделать так, чтобы обновление получили все?
🍭 Единое окно по сбору информации об образах и уязвимостях.
🍭 Анализ только того, что используется. Общее количество образов оценивалось в 400 000, «активных» образов – 4 000
Очень много интересных размышлений, описание проблематики с которой можно столкнуться и возможные варианты решений на уровне идей. А реализация идей будет описана во второй статье, посвященной тому, как именно Lyft автоматизировали созданный ими концепт. Ждем!