The post has been translated automatically. Original language: Russian
DevSecOps Pipeline. Part 15: A real example of a triage of vulnerabilities (Input, Logic, Decision)
One of the comments to my last post gave me the idea to make this material as practical as possible. Instead of abstract arguments about "AI prioritization", I will show real input data, analysis logic, and the final solution to eliminate vulnerabilities using the example of a single live scan.
1. Input data (The Input)
The KICS tool scanned Kubernetes manifests and returned 10 MEDIUM-level finds. Here are three of them exactly as the AI assistant received them.:
- [KICS][MEDIUM] Shared Service Account File: k8s/deployment/deployment.yaml Description: A shared Service Account token between workloads.
- File: k8s/deployment/deployment.yaml
- Description: A shared Service Account token between workloads.
- [KICS][MEDIUM] Container Running With Low UID File: k8s/deployment/deployment.yaml Description: The container's UID may conflict with the host's user table.
- File: k8s/deployment/deployment.yaml
- Description: The container's UID may conflict with the host's user table.
- [KICS][MEDIUM] Container Capabilities Unrestricted File: k8s/deployment/deployment.yaml Description: Redundant Linux capabilities have not been reset.
- File: k8s/deployment/deployment.yaml
- Description: Redundant Linux capabilities have not been reset.
All three findings have the same criticality level — MEDIUM. From the point of view of the basic scanner, they are absolutely equal in priority.
2. The Prioritization Logic
AI does not rank vulnerabilities based only on the scanner's dry assessment. He evaluates the possibility of real exploitation (exploitability) and the potential business impact on the system.
As a result, the pipeline gave the following ranking:
- #1 Shared Service Account Compromising a pod with a shared automatically mounted token gives an attacker direct multiple access to the Kubernetes API. No additional exploits are required.
- #2 Container Running With Low UID Is a risk of conflict at the host level. The threat is real, but a specific UID match is required for operation.
- #3 Unrestricted Capabilities Expands the attack vector, but it becomes dangerous mainly when the attacker has already been able to execute his code inside the container.
Bottom line: The severity level is the same, but the real risk is completely different. This is the difference between a simple vulnerability count and a real triage.
3. The Final Decision
Based on this prioritization, the remediation order was as follows:
- Disabling automatic token mounting (automountServiceAccountToken: false).
- Explicitly specifying a secure user (runAsUser).
- Reset unnecessary Linux capabilities.
One commit closed all three finds at once. The next launch of the scanner showed the transition from 10 MEDIUM vulnerabilities to a clean check in Conftest. Now, 48 out of 48 security policies firmly block such unsafe patterns, even if someone later decides to edit the YAML file manually.
Why is this important for the industry?
The scanner metrics (vulnerability count) show you only the total amount of problems. The triage and context show what needs to be fixed right now.
Now our pipeline automates both stages.:
- KICS and Trivy are responsible for vulnerability detection.
- AI (Llama 3 / Groq) — ranks findings according to the degree of exploitability and argues logic.
- Conftest (Policy-as-Code) — makes corrections permanent and protects against hidden regressions.
In the next part (Part 16), we'll look at how to apply these same policies on the fly inside the cluster itself using OPA Gatekeeper, and not just at the CI pipeline stage.
#DevSecOps #AI #Kubernetes #KICS #PolicyAsCode #SecurityAutomation #CyberSecurity
DevSecOps Pipeline. Часть 15: Реальный пример триажа уязвимостей (Input, Logic, Decision)
Один из комментариев к моему прошлому посту натолкнул меня на мысль сделать этот материал максимально прикладным. Вместо абстрактных рассуждений об «ИИ-приоритизации» я покажу реальные входные данные, логику анализа и финальное решение по устранению уязвимостей на примере одного живого сканирования.
1. Входные данные (The Input)
Инструмент KICS просканировал манифесты Kubernetes и вернул 10 находок уровня MEDIUM. Вот три из них ровно в том виде, в каком их получил ИИ-ассистент:
- [KICS][MEDIUM] Shared Service AccountФайл: k8s/deployment/deployment.yamlОписание: Токен Service Account разделяемый (shared) между ворклоудами.
- Файл: k8s/deployment/deployment.yaml
- Описание: Токен Service Account разделяемый (shared) между ворклоудами.
- [KICS][MEDIUM] Container Running With Low UIDФайл: k8s/deployment/deployment.yamlОписание: UID контейнера может конфликтовать с таблицей пользователей хоста.
- Файл: k8s/deployment/deployment.yaml
- Описание: UID контейнера может конфликтовать с таблицей пользователей хоста.
- [KICS][MEDIUM] Container Capabilities UnrestrictedФайл: k8s/deployment/deployment.yamlОписание: Избыточные Linux-капабилити не сброшены.
- Файл: k8s/deployment/deployment.yaml
- Описание: Избыточные Linux-капабилити не сброшены.
У всех трех находок одинаковый уровень критичности — MEDIUM. С точки зрения базового сканера они абсолютно равны по приоритету.
2. Логика приоритизации (The Prioritization Logic)
ИИ не ранжирует уязвимости только по сухой оценке сканера. Он оценивает возможность реальной эксплуатации (exploitability) и потенциальный бизнес-импакт на систему.
В итоге пайплайн выдал следующее ранжирование:
- #1 Shared Service AccountКомпрометация пода с общим автоматически примонтированным токеном дает злоумышленнику прямой многократный доступ к Kubernetes API. Дополнительных эксплойтов не требуется.
- #2 Container Running With Low UIDРиск конфликта на уровне хоста. Угроза реальна, но для эксплуатации требуется специфическое совпадение UID.
- #3 Unrestricted CapabilitiesРасширяет вектор атаки, но становится опасным в основном тогда, когда атакующий уже смог выполнить свой код внутри контейнера.
Итог: Уровень severity один, а реальный риск — абсолютно разный. В этом и заключается разница между простым подсчетом уязвимостей и реальным триажем.
3. Финальное решение (The Decision)
Опираясь на эту приоритизацию, порядок исправления (remediation order) был следующим:
- Отключение автоматического монтирования токена (automountServiceAccountToken: false).
- Явное указание безопасного пользователя (runAsUser).
- Сброс ненужных Linux capabilities.
Один коммит закрыл сразу все три находки. Следующий запуск сканера показал переход от 10 MEDIUM уязвимостей к чистому прохождению проверок в Conftest. Теперь 48 из 48 политик безопасности намертво блокируют подобные небезопасные паттерны, даже если кто-то позже решит отредактировать YAML-файл вручную.
Почему это важно для индустрии?
Метрики сканеров (vulnerability count) показывают вам лишь общий объем проблем. Триаж и контекст показывают то, что нужно чинить прямо сегодня.
Сейчас наш пайплайн автоматизирует оба этапа:
- KICS и Trivy — отвечают за обнаружение уязвимостей.
- ИИ (Llama 3 / Groq) — ранжирует находки по степени эксплуатируемости и аргументирует логику.
- Conftest (Policy-as-Code) — делает исправления перманентными и защищает от скрытых регрессий.
В следующей части (Part 16) разберем, как применять эти же политики на лету внутри самого кластера с помощью OPA Gatekeeper, а не только на этапе CI-пайплайна.
#DevSecOps #AI #Kubernetes #KICS #PolicyAsCode #SecurityAutomation #CyberSecurity
Share
