Применение на стороне сервера важно, так как объекты Kubernetes представляют собой общее состояние: оно переносит право владения полями на API-сервер, что позволяет инструментам в стиле apply выявлять конфликты, а не скрывать их в виде тихих перезаписей.

В AI-проектах уже недостаточно знать только версии контейнеров и пакетов. Важно понимать, какие AI-модели, фреймворки и компоненты реально используются в кластере, где они запущены и от чего зависят. Что и как он идентифицирует можно почитать тут.

Команда Google Cloud представила k8s-aibom — инструмент с открытым исходным кодом, который помогает автоматически собирать AIBOM.
Что инструмент дает:
- инвентаризацию AI-компонентов в кластере;
- понимание, какие модели и ML-фреймворки используются;
- повышение прозрачности AI-нагрузок;
- помощь в анализе рисков, уязвимостей и соответствия требованиям безопасности;
- более удобный контроль AI-софта в production-средах.

Со временем окружение быстро усложняется, а ручной учет компонентов становится практически невозможным. По сути, k8s-aibom — это попытка сделать для AI-компонентов то же, что SBOM (только в формате OWASP CycloneDX 1.6 Machine Learning Bill of Materials (ML-BOM)) делает для обычного программного обеспечения: дать структурированное представление о составе системы, чтобы защитить цепочку поставки (supply chain), борьба с shadow AI.

Cilium работает на уровне ядра в сетевом пути миллионов подов Kubernetes. Если бы наша цепочка поставок была скомпрометирована, масштаб последствий был бы значительным. Укрепление проекта против такого сценария — это то, над чем мы работаем непрерывно, и мы хотели записать, что именно мы делаем, в деталях. Большая часть следующего не специфична для Cilium: любой проект с открытым исходным кодом, использующий CI/CD на GitHub Actions, может применить эти подходы.