Beyond Container Discovery: Bringing Software Intelligence to Kubernetes with Syft and KVA

[Sakshi_Tiwari]

Kubernetes has become the backbone of modern application delivery. As organizations scale their cloud-native environments, platform teams are managing an ever-growing number of clusters, workloads, and container images.

Kubernetes Visibility Agent (KVA) helps organizations discover these dynamic environments and bring their Kubernetes resources into the ServiceNow Configuration Management Database (CMDB).

But there's a question that often comes after the initial discovery:

We know which container images are running. But what software is actually inside those images?

That question matters.

A container image is more than a name, a tag, and a registry location. It is a bundle of software components that may include an operating system, application packages, libraries, and other dependencies.

For teams responsible for infrastructure visibility, software governance, and compliance, knowing the contents of those images can be just as important as knowing where they are running.

This is the problem we set out to address with Syft-powered container image scanning in Kubernetes Visibility Agent.

In this blog, I'll walk through the problem we're solving, how the integration works, and what this means for KVA customers.

---

The challenge: Container visibility is only the starting point

KVA helps customers populate the CMDB with Kubernetes resources and information about the container images used in their clusters.

This provides a foundation for understanding Kubernetes infrastructure and the workloads running on it.

However, the initial image information is intentionally limited.

Consider an image such as:

registry.example.com/customer-api:2.4

From the image metadata, you may be able to identify the image name, tag, and registry.

But several important questions remain unanswered:

• Which operating system is packaged inside the image?

• What version of the operating system is being used?

• Which software packages and libraries are included?

• What other components have been introduced through the image's base layers?

• How can this information be made available for software inventory and governance?

For customers operating large Kubernetes environments, manually answering these questions across images is not a scalable approach.

This is where software composition visibility becomes important.

The objective is to complement Kubernetes resource discovery with deeper insight into the software components that make up container images.

---

Introducing Syft: Image intelligence without vulnerability scanning

To address this requirement, we are integrating Syft by Anchore into KVA.

Syft is an open-source tool that analyzes software artifacts, including container images, and generates a Software Bill of Materials (SBOM).

Syft focuses on identifying the software components present in an image. It is not a vulnerability detection engine, and its core scanning workflow does not depend on an external vulnerability database.

That distinction is important.

The purpose of this integration is to provide software composition information, rather than to replace dedicated vulnerability management tools.

What can Syft-powered scanning tell you?

Depending on the contents of the image and the information available to Syft, customers can gain visibility into:

• Operating system and OS version.

• OS family, such as RHEL, CentOS, Alpine, or Windows.

• Image architecture, such as amd64 or arm64.

• Image size and creation timestamp.

• Software packages and their versions, where available.

• Other software component metadata captured through the image analysis.

• SBOM-related information that can support software inventory and governance.

The result is a richer understanding of the software packaged inside the images running in your Kubernetes environment.

KVA helps you discover where your images are running. Syft helps you understand what those images contain.

---

Why integrate Syft directly into KVA?

ServiceNow already supports container image scanning through the Trivy CLI integration.

Trivy remains an option for customers who do not use Kubernetes Visibility Agent. However, the existing Trivy-based approach requires a MID Server and a separate Trivy tool installation on that MID Server.

For customers already using KVA, we wanted to provide a more integrated approach.

Instead of introducing another scanning component to deploy and maintain, the Syft integration is designed to leverage the existing KVA Informer architecture.

This means KVA customers can access image software decomposition through the same Kubernetes visibility ecosystem they already use.

A quick comparison

	Trivy integration	Syft via KVA
Primary purpose	Container image scanning	Container image software composition
Deployment model	Requires a MID Server with Trivy installed	Syft runs alongside the KVA Informer
Additional scanning infrastructure	MID Server required	No separate MID Server for the KVA-based workflow
Vulnerability detection	Trivy supports vulnerability-related capabilities	Syft itself does not detect vulnerabilities
Software inventory	Supported through the relevant integration	Provides image software composition information
Best fit	Customers using the Trivy integration, including those without KVA	Customers using KVA who want integrated image software visibility

The choice between the two approaches depends on the customer's environment and requirements.

For KVA customers, Syft provides an integrated path to image software visibility.

---

How it works: A sidecar architecture built into KVA

One of the key design considerations was minimizing the additional infrastructure that customers need to deploy and maintain.

The solution uses a sidecar architecture within the existing KVA Informer pod.

Here's what happens behind the scenes.

1. Install KVA with the Syft scanner enabled

When a customer installs the KVA Informer using Helm and enables the Syft scanner option, the deployment creates an additional sidecar container within the Informer pod.

The Syft container includes the Syft CLI tool and a wrapper that accepts scan instructions from the main Informer container.

There is no need to deploy a separate scanning pod or create a new Kubernetes cluster for this workflow.

2. The Informer requests an image scan

The KVA Informer sends a scan instruction to the Syft sidecar using a synchronous HTTP request.

The Syft sidecar analyzes the requested image and generates the relevant software composition information.

The sidecar exposes its HTTP endpoint only on localhost. This means the endpoint is intended to be accessible only to the Informer container within the pod, rather than being exposed as an external scanning service.

3. Scan results return to the Informer

Once Syft completes the scan, the results are returned to the main Informer container.

The Informer then sends the information to the ServiceNow instance through the existing ECC queue-based communication path.

4. ServiceNow updates the CMDB

On the instance, image metadata is populated in the same Docker image CMDB table used by the existing Trivy flow:

cmdb_ci_docker_image

Software packages are modeled separately in:

sn_itom_pattern_container_image_os_packages

These packages appear in the related list of the Docker image configuration item.

This common data model is important for customers who already have processes, reports, or integrations built around their container image records.

The architecture at a glance

Kubernetes cluster → KVA Informer → Syft sidecar → Image analysis → Informer → ECC queue → ServiceNow CMDB

The design keeps image scanning closely aligned with KVA's existing architecture while extending the depth of information available about container images.

---

Behind the scenes: How image scanning is orchestrated

Beyond the scanning container itself, the solution includes an orchestration mechanism to manage scan requests.

A script called Scan Container Images, executed through a scheduled job, runs every minute.

Here's how the process works:

1. The scheduled job identifies up to 10 images that have not yet been scanned.

2. The system checks whether an earlier batch is still in progress.

3. If the previous batch has not completed, a new batch is not started.

4. The system evaluates the configured properties to determine whether scanning is required and which scanning method should be used.

5. If KVA-based scanning is selected, the system chooses an appropriate Informer using the Informer selection algorithm.

6. The scan status is tracked, and the results are processed when the scan completes.

This approach helps control the number of concurrent image scan requests and provides a structured way to process images awaiting analysis.

The scan status continues to be maintained in:

sn_itom_pattern_container_image_scan_status

Customers can also retrieve Syft scanner logs through the Get Syft Scanner Logs action on an Informer record configured for image scanning.

---

What does this mean for the CMDB?

One of the most important aspects of this enhancement is where the data ends up.

The goal is not simply to generate an SBOM and leave it disconnected from the rest of the platform.

The image information is populated in the existing Docker image configuration item model.

Image-level information

The following fields can be populated on cmdb_ci_docker_image, depending on the information available in the image:

CMDB field	Description
Operating System (os)	Operating system identified in the image
OS Version (os_version)	Operating system version
Architecture (architecture)	Image architecture, such as amd64 or arm64
Size (size_bytes)	Image size in bytes
OS Family (os_family)	OS family, such as Alpine or RHEL
Image Created (image_created_at)	Image creation timestamp
Command (command)	Command information associated with the image

Not every field is guaranteed to be available for every image.

Software packages

Software packages identified in the image are modeled in:

sn_itom_pattern_container_image_os_packages

These records are displayed in the related list of the Docker image CI.

One important consideration: Syft provides the maintainer and version information, and these attributes may not be populated in every case.

The availability of software metadata depends on the image contents and what Syft can identify.

This additional information gives customers a stronger starting point for understanding the software components associated with their container images.

---

Getting started with Syft-powered image scanning

For customers who want to enable this capability, the integration is available through the KVA installation and configuration process.

Prerequisites

The relevant application versions specified in the documentation are:

Component	Required version
Kubernetes Visibility Agent	3.16.x or later
Discovery and Service Mapping Patterns	1.32.x or later
KVA Informer	2.9.x or later

The Discovery and Service Mapping Patterns requirement corresponds to the September 2026 release.

1. Enable the Syft scanner during installation

When installing the Informer using the Helm chart, enable the Syft scanner with:

--set runSyftScanner=true

The Syft container image is published using the following naming convention:

servicenowdocker/informer_syft:2.9.x

Customers using private image registries should copy the Syft image to their own registry, following the same process used for the main Informer image.

For customers who do not use Helm directly, the recommended approach is to render the Helm chart using helm template and use the resulting manifest for installation.

A dedicated k8s_informer.yaml manifest supporting the image scanning functionality is not provided.

2. Enable image scanning through system properties

The following system properties need to be enabled:

sn_itom_pattern.container_image_scan = true
sn_acc_visibility.image_scan_enabled = true

The first property enables the image scanning mechanism.

The second property instructs the system to use Syft-based scanning through KVA.

Trivy and Syft cannot be mixed within the same KVA image scanning flow. Customers should select the appropriate scanning approach for their deployment.

---

What this means for customers

From a product perspective, this enhancement is about more than adding another scanner to the Kubernetes ecosystem.

It addresses a few meaningful customer needs.

1. Moving from image metadata to software context

Previously, a customer could identify the image running in a Kubernetes workload but have limited visibility into the software packaged inside that image.

With Syft-powered decomposition, customers can access deeper image-level information, including operating system details and software packages where available.

This helps bridge the gap between Kubernetes infrastructure discovery and software inventory.

2. Building on existing KVA investments

For KVA customers, the integration uses the Informer architecture they already deploy.

There is no requirement for a separate MID Server for the KVA-based Syft scanning workflow.

Customers can extend their image visibility without introducing an entirely separate scanning deployment.

3. Supporting cloud-native access patterns

The integration supports identity-based access to private registries across supported cloud environments.

This allows customers to align image retrieval with their existing IAM practices, subject to their deployment and security configuration.

4. Creating a foundation for software governance

The software composition information generated by Syft can help support broader software governance initiatives.

For example, customers may use this data to improve their understanding of:

• Software components present in deployed images.

• Dependencies included in application images.

• Software inventory requirements.

• Containerized software supply chain information.

The integration itself is focused on image composition and does not replace dedicated vulnerability scanning or license compliance solutions.

However, better software inventory data can provide a useful foundation for broader enterprise workflows.

---

From discovering Kubernetes to understanding the software estate

Kubernetes environments are dynamic by nature.

Workloads are deployed, scaled, updated, and replaced continuously. This makes it increasingly important for organizations to connect their infrastructure visibility with a deeper understanding of the software running within that infrastructure.

With Syft integration, KVA takes a step in that direction.

The journey moves from:

Cluster → Workload → Container → Image

toward:

Cluster → Workload → Container → Image → Operating system and software components

This richer context can help teams connect cloud-native infrastructure with enterprise CMDB, software inventory, and governance initiatives.

For us, the goal is not simply to collect more data.

It is to make the data collected through Kubernetes discovery more meaningful and useful across the organization.

---

Looking ahead: Building a stronger foundation for cloud-native software intelligence

As Kubernetes adoption grows, the distinction between infrastructure visibility and software visibility becomes increasingly important.

Knowing where an image is running is valuable.

Knowing what software is inside that image provides another layer of context—one that can support inventory, governance, and broader software intelligence initiatives.

With Syft-powered image scanning in KVA, we are extending Kubernetes visibility into the software composition of container images, while building on the existing Informer architecture and CMDB data model.

This is an important step in helping customers understand not just their Kubernetes infrastructure, but also the software components that power their applications.

And there is more opportunity ahead.

As organizations bring together infrastructure operations, security, software asset management, and compliance, richer cloud-native software data can help connect these disciplines.

Our goal is to make Kubernetes visibility more actionable by bringing the software context closer to the infrastructure context.

Discover the workload. Understand the image. Build a more complete picture of your software estate.

---

Learn more

For technical details, installation instructions, configuration options, and supported environments, refer to the official ServiceNow Knowledge Base article:

📘 Scanning Container Images using Kubernetes Visibility Agent — KB3149735

Share your experiences in the comments. Your feedback helps us understand what matters most as we continue evolving KVA.