Introducing KBOM – Kubernetes Bill of Materials
SBOM (Software Bill of Materials) is an accepted best practice to map the components and dependencies of your applications in order to better understand your applications’ risks. SBOMs are used as a basis for vulnerability assessment, licensing compliance, and more. There are plenty of available tools, such as Aqua Trivy, that help you easily generate SBOM for your applications.
While SBOM is a standard practice for applications, there is an entire underlying Kubernetes infrastructure that runs and operates our applications and is as important to secure. The current landscape of Kubernetes infrastructure security is led by misconfiguration and hardening scanners, but there’s a gap when it comes to vulnerability assessment for our Kubernetes clusters and the components they are made of.
Kubernetes has been called the “operating system of the cloud.” It is a critical piece of middleware between many other foundational layers such as network, container runtime, cloud infrastructure, storage and more. This positions Kubernetes as a key component in your threat model.
Moreover, Kubernetes is complex. There are many moving parts, and simply mapping and recording the composition of your cluster is a worthy goal.
Introducing the Kubernetes Bill of Materials, or KBOM. It is a manifest of all the important components that make up your Kubernetes cluster: Control plane components, Node Components, and Addons, including their versions and images. Which “api-server” version are you currently running? Which flavor of “kubelet” is running on each node? What kind of Network Plugin are you currently using? These are all questions that a KBOM can answer. And most importantly – are there any vulnerabilities known to affect these components.
Conceptual Depiction of a KBOM
Curious to find out what your K8s environment is made of? Great news, KBOM generation is available in Trivy today! Try out an early preview of the capability with the latest release of Trivy. In the future we are planning to add more accurate component discovery, more Kubernetes distributions support, and vulnerability matching.
To provide you more information around the new KBOM functionality we have compiled a list of questions and answers below.
Is KBOM the same as Kubernetes SBOM?
No. When people refer to “Kubernetes SBOM” they usually mean the SBOM of the workloads that are running in Kubernetes. By contrast, the Kubernetes Bill of Materials (KBOM) is for describing the composition of the Kubernetes cluster itself. Trivy already had Kubernetes SBOM features. This new KBOM capability is an additional layer of visibility.
Is KBOM a new standard?
No. We think KBOM can use the same industry formats that are common today for other “bills of materials.” Our first iteration is based on the popular CycloneDX BOM format, and the existing taxonomy that the Kubernetes project defines (core components, node components, addons, etc).
Is this related somehow to kube-hunter?
Kube-hunter, another Aqua open-source project, was one of the pioneers in Kubernetes vulnerability assessment. While kube-hunter took an imperative testing approach, by probing and poking potentially vulnerable components, Trivy KBOM functionality takes a more passive approach, by only listing components and matching with known vulnerabilities, which is a much more scalable, safe and familiar approach.
How accurate is KBOM?
Trivy’s KBOM currently uses Kubernetes API to discover the cluster. It is tested with popular Kuberntetes distributions such as OpenShift, Rancher, minikube, and kind. In the future we plan to enhance this with more sources of information, e.g nodes, cloud providers, etc.
In addition, KBOMs can be generated in different ways. For example, instead of analyzing an existing cluster after the fact, Kubernetes installers could report their outcome in KBOM format. This is analogous to the difference between SBOM generation with SCA vs from source.
Do I need any of this if I’m using a managed Kubernetes?
Yes. We think it’s important to know your stack even if you’re not operating it. For example, if your managed Kubernetes is using a vulnerable component, you want to know that you’re affected even if it’s not your responsibility to fix the issue. In the future, service providers could publish the KBOM for your consumption.