배경 및 맥락
AI 워크로드가 Kubernetes에 빠르게 확산되면서, 보안팀은 배포 승인을 받은 모델과 실제 실행 중인 모델·runtime·container의 차이를 추적해야 한다. 기존 SBOM은 빌드 시점 의존성을 잘 보여 주지만, 현장에서 누가 어떤 AI runtime을 가동했는지까지 자동으로 보장하지는 않는다. 이 간극은 shadow AI, 승인되지 않은 model serving, 누락된 취약점 관리로 이어질 수 있다.
핵심 내용
Google Cloud가 공개한 k8s-aibom은 경량·비권한형 Kubernetes controller다. cluster API와 container environment를 지속적으로 관찰해 vLLM, Triton 같은 실행 중 AI runtime을 찾아내고, 이를 OWASP CycloneDX 1.6 형식의 Machine Learning Bill of Materials로 정리한다. 생성된 ML-BOM은 custom resource의 status.bomDocument에 붙으며, Google Cloud Storage나 외부 webhook 같은 optional sink로도 내보낼 수 있다. Google은 이를 통해 수동 pod-spec 편집이나 privileged DaemonSet 요구 없이 runtime 기반 가시성을 제공한다고 설명한다.
경쟁 구도 / 비교
CI 단계의 SBOM 생성은 artifact가 만들어질 때의 구성에는 강하지만, 배포 후 변경·사이드카·동적으로 내려받은 모델을 놓칠 수 있다. k8s-aibom은 runtime 관찰을 통해 이 약점을 보완하는 계층이다. 다만 자동 탐지 도구만으로 거버넌스가 완성되지는 않는다. BOM에 기록된 component를 취약점 DB, 허용 모델 목록, 승인된 registry, 서비스 소유자와 연결해야 실제 대응이 가능하다.
의미
AI 공급망 관리는 모델 weight의 provenance만 확인하는 단계를 넘고 있다. 조직은 training·build·deployment·runtime 각각에서 어떤 artifact와 endpoint가 사용되는지 이어지는 증적을 만들어야 한다. 이를 위해 발견 결과의 severity 기준, 예외 승인 만료, owner 지정, 패치 SLA, egress 통제를 정책화하면 AI 프로젝트를 속도와 감사 가능성을 함께 갖춘 production 운영으로 옮길 수 있다.