Contents
Introduction
How Kubernetes Visibility Agent(KVA) Discovers Your K8s Cluster
Where Aqua Trivy Steps In
Extracting the Software Bill Of Materials (SBOM)
Connecting It Back to the Software asset Management (SAM) Layer
The Big Picture
Introduction -
Ever wondered how ServiceNow can give you end-to-end visibility into your Kubernetes environment — right from cluster discovery down to the software components packed inside your container images? And what if you could connect all of that to a downloadable SBOM without ever leaving the platform? Let's walk through exactly how these pieces fit together.
Typically, the SBOM Workspace relies on SBOM data ingested from third-party tools or provided directly by publishers. However, in this use case, we demonstrate how native ServiceNow modules can work together to identify vulnerabilities within containers—without depending solely on external SBOM feeds.
Before progressing further, it is important to acknowledge the primary intention of SBOM Workspace is to track vulnerabilities for :
- Open Source Components — Instantly identify every application carrying a vulnerable component the moment a CVE like Log4Shell is disclosed.
- COTS Software — Ingest vendor-supplied SBOMs for purchased applications, applying the same vulnerability and remediation workflows to third-party software.
- Firmware & IoT/OT Devices — Centralize OT/IoT risk management by ingesting SBOMs from specialist firmware analysis tools into the same platform used for IT.
- Home-Grown Applications — Continuously track open-source dependencies in internally built software via manual uploads or CI/CD pipeline integration.
- Container Images — Beyond application-layer code libraries, SBOM Workspace tracks OS-level packages within container images, ensuring that vulnerabilities present in base layers are surfaced and managed alongside application-layer risks.
🔍 Our focus: This document is specifically concerned with container image vulnerability monitoring, leveraging the Kubernetes Visibility Agent(KVA), container scanning and SBOM Workspace capabilities of the ServiceNow platform.
How Kubernetes Visibility Agent(KVA) Discovers your K8s Cluster -
ServiceNow's Kubernetes Visibility Agent (KVA) is a purpose-built capability designed to scan and map your Kubernetes environment in its entirety. Once deployed, KVA connects to your cluster and begins building out the full topology — starting from the cluster itself and progressively drilling down through every layer of the hierarchy.
At the top level, KVA identifies the Cluster and its associated Namespaces. Within each namespace, it discovers Workloads — this includes Deployments, StatefulSets, DaemonSets, ReplicaSets, and Jobs. Each workload then maps to its underlying Pods, and within those pods, KVA identifies the individual Containers running inside them. Finally, each container resolves back to the Docker Image it was instantiated from. This gives you a clean, navigable hierarchy: Cluster → Namespace → Workload → Pod → Container → Docker Image.
All of this discovered data can be navigable with ease through the Kubernetes Explorer(in Cloud Discovery workspace) — giving asset managers and security teams a live, visual map of what is running and where.
More details - https://www.servicenow.com/docs/r/it-operations-management/discovery/acc-kubernetes-visibility-landi...
Where Aqua Trivy Steps In -
KVA discovers the hierarchy and brings you to the docker image level, but it doesn't stop there. This is where the complementary scanning agent — Aqua Trivy — takes over. Trivy is an open-source vulnerability scanner that goes inside the docker image itself and enumerates all the OS-level packages and libraries bundled within it. Once Trivy completes its scan, those findings are loaded into the Container Image OS Packages table in ServiceNow, giving you a precise bill of materials for every image running in your environment.
More details - https://www.servicenow.com/docs/r/it-operations-management/discovery/container-image-concept.html
Extracting the Software Bill Of Materials (SBOM) -
Once the OS packages are populated, you can generate and download a Software Bill of Materials (SBOM) directly from within ServiceNow. To do this, navigate to the Kubernetes Explorer in the Cloud Discovery workspace or Discovery Admin Workspace>>Insights, locate the docker image of interest, and from there you can extract the SBOM hitting the ‘Download SBOM’ link as shown above — capturing all the software components, packages, and versions that make up that image. This SBOM then becomes available in the SBOM workspace(using manual load or smart scripts), where it can be analysed for vulnerabilities, matched against known CVEs, and tied back to your broader software asset inventory.
Connecting It Back to the Software asset Management (SAM) Layer -
Here's where it gets powerful. The software components identified within the SBOM don't just sit in isolation — they can be connected to the SAM (Software Asset Management) layer in ServiceNow. Publisher names, product versions, and package identifiers discovered through Trivy's scan can be reconciled against your software catalog, giving your SAM team visibility into what open-source and commercial software is running inside containers — often a blind spot in traditional SAM programs. This means you're not just tracking licenses on devices anymore; you're extending compliance and risk visibility into your containerized workloads.
SBOM can be loaded to SBOM workspace manually or automated using rest api integrations.
Manual - OOTB currently, one has to load the SBOM extracted from K8 explorer manually and that is when the software model should be mentioned.
Automation - People can also write some smart scripts/jobs to auto-push the SBOMs from docker images to SBOM workspace using OOTB offered Rest API.
‘productModelId’ – mentioning this parameter in the request becomes must if the SBOM has to be mapped against any product model.
Once the SBOM is linked to a software model, one can have a report or dashboard created using ‘Component Dependencies[sn_sbom_comp_relationship]’ table to have better visibility of how a software is connected to a package and what kind of vulnerabilities are associated with its components.
Note: The components depicted in this image are for illustrative purposes only and do not reflect the actual packaging or composition of the product model.
The Big Picture -
What makes this flow compelling is how each ServiceNow module hands off to the next — KVA maps the cluster topology -> Trivy scans the image contents -> the SBOM workspace surfaces the risk -> SAM closes the loop on compliance and risk visibility.
It's a great example of the platform's single-architecture advantage: the data discovered at the infrastructure layer is the same data your security and asset teams act on — no re-ingestion, no reconciliation across tools, just one connected workflow from container to compliance.
