Привет!
Продолжение истории Bridgecrew! После сбора статистических данных команда решила проанализировать наиболее часто встречающиеся Helm-dependencies.
Задача отчасти похожа на создание Software Bill of Materials (SBOM), только для Helm-chart: необходимо понять какие именно компоненты являются «зависимыми» и насколько они корректны с точки зрения ИБ.
В статье продемонстрированы графы с легендой:
🍭 Зеленый: сканируемый chart
🍭 Синий: зависимость (URI) ссылается на тот же Helm repository, что и сам chart
🍭 Черный: «локальные» зависимости chart (отсутствует URI, только local file path)
🍭 Красный: Все остальные зависимости
В результате анализа получилось собрать статистику о наиболее часто используемых зависимостях (одной из которых стала bitnami/postgresql) и сделать вывод, что существует большая фрагментация зависимостей, их массовое дублирование, которые можно было бы переиспользовать. В конце статьи Bridgecrew привели несколько рекомендаций о том, как можно повысить уровень ИБ в такой ситуации: Embed static analysis into your CI/CD pipeline, Understand your runtime posture, Audit third-party Infrastructure code, Increase awareness of IaC security, Automate posture information at the point of consumption
Продолжение истории Bridgecrew! После сбора статистических данных команда решила проанализировать наиболее часто встречающиеся Helm-dependencies.
Задача отчасти похожа на создание Software Bill of Materials (SBOM), только для Helm-chart: необходимо понять какие именно компоненты являются «зависимыми» и насколько они корректны с точки зрения ИБ.
В статье продемонстрированы графы с легендой:
🍭 Зеленый: сканируемый chart
🍭 Синий: зависимость (URI) ссылается на тот же Helm repository, что и сам chart
🍭 Черный: «локальные» зависимости chart (отсутствует URI, только local file path)
🍭 Красный: Все остальные зависимости
В результате анализа получилось собрать статистику о наиболее часто используемых зависимостях (одной из которых стала bitnami/postgresql) и сделать вывод, что существует большая фрагментация зависимостей, их массовое дублирование, которые можно было бы переиспользовать. В конце статьи Bridgecrew привели несколько рекомендаций о том, как можно повысить уровень ИБ в такой ситуации: Embed static analysis into your CI/CD pipeline, Understand your runtime posture, Audit third-party Infrastructure code, Increase awareness of IaC security, Automate posture information at the point of consumption