Meeting 2025’s SBOM Compliance Deadlines: A Practical Implementation Guide

2025 has become the year of SBOM compliance deadlines. March 31st marked PCI DSS 4.0’s enforcement date, requiring payment processors to maintain comprehensive inventories of all software components. Meanwhile, the EU’s Cyber Resilience Act takes full effect in August 2027, but organizations selling products with digital elements in Europe must start preparing now—meaning SBOM implementation can’t wait.

These aren’t isolated regulatory experiments—they’re the latest milestones in a global trend that shows no signs of slowing. As regulatory bodies worldwide continue to steadily drive SBOM adoption, organizations face a stark choice: accept this new reality and commit to comprehensive software supply chain security, or get left behind by competitors who embrace transparency as a competitive advantage.

The urgency is real, but so is the solution. Anchore Enterprise serves as the “easy button” for organizations looking to comply with both newly updated frameworks while building a foundation for whatever regulatory requirements come next. Rather than scrambling to manually catalog software components or piece together makeshift compliance solutions, organizations can automate SBOM generation and analysis across their entire container portfolio.

---

---

Solution Overview

Anchore Enterprise is a self-hosted SBOM management solution that can be deployed across various cloud and on-premises environments. It’s available as cloud images for appliance-like experiences or in container form for deployment to Kubernetes clusters. For organizations using cloud platforms, this might mean deploying on Amazon EC2, Azure VMs, or Google Compute Engine. For Kubernetes users, deployment options include hyper-scaler Kubernetes engines or on-premises Kubernetes distributions.

Deployment Options:

• Cloud Image Deployment: Available as AMIs for AWS EC2, similar images for other cloud providers
• Container Deployment: Helm charts for any Kubernetes cluster (cloud or on-premises)
• On-Premises & Air-Gapped: Flexible architecture supports secure, disconnected environments requiring complete internal deployment

Above: A typical Cloud Image-based deployment

Above: A typical Container Image deployment on Amazon EKS

With Anchore Enterprise deployed in your environment, you can immediately start generating SBOMs for software in your repositories by scanning container registries or uploading SBOMs directly via API, CLI and UI import mechanisms. With stored SBOMs, Anchore Enterprise provides a comprehensive view into your software contents, issuing alerts to developers or security teams on vulnerabilities or content drift. Policy-based enforcement allows you to act on vulnerabilities in content or content from unapproved sources and vendors. Searches can be performed on any metadata contained within the SBOM to enable fast response during zero day situations such as the infamous Log4j.

Full details on how to deploy the solution can be found here.

SBOM Generation Methods

Anchore Enterprise supports two primary SBOM generation approaches that work with any container registry:

Distributed Scanning: The SBOM is generated using a command line tool, AnchoreCTL (based on the Syft open source project). This tool is typically invoked in CI/CD pipelines but can also be run on developer workstations. The resulting SBOM is then uploaded to the Anchore Enterprise API for processing. This approach works regardless of your registry provider.

Centralized Scanning: Anchore Enterprise retrieves container images from registries either as one-time operations or on an ongoing basis using repository or tag subscriptions. The SBOM is then generated from the retrieved image within the Anchore Enterprise deployment itself. This method supports all major container registries with appropriate authentication.

For this walkthrough, we’ll demonstrate centralized scanning using Amazon ECR as an example, but the same principles apply to other container registries.

Connecting to Container Registries

Before importing images for SBOM generation, Anchore Enterprise requires access to your container registries. The authentication method varies by registry type:

For Cloud Registries:

• AWS ECR: IAM roles, access keys, or service account integration
• Azure ACR: Service principals, managed identity, or access tokens
• Google GCR/Artifact Registry: Service accounts or workload identity
• Docker Hub: Username/password or access tokens

For Private Registries:

• Harbor, Quay, Nexus: Username/password, certificates, or token-based authentication

Example: Configuring Amazon ECR Access

For cloud Kubernetes deployments, Anchore Enterprise can leverage cloud-native authentication. For AWS, this might involve IAM roles presented to Kubernetes Service Accounts. Other cloud providers offer similar mechanisms (Azure managed identity, Google workload identity).

With appropriate permissions configured, add your registry:

# For AWS ECR

ANCHORECTL_REGISTRY_PASSWORD=awsauto anchorectl registry add \

  your_account_id.dkr.ecr.region.amazonaws.com \

  –username awsauto –type awsecr

# For other registries, authentication varies:

# Docker Hub

anchorectl registry add docker.io –username your_username

# Harbor

anchorectl registry add your-harbor.company.com –username harbor_user

Confirm the registry has been added:

anchorectl registry list

The Anchore Enterprise UI also provides a visual interface for managing registry credentials across all supported registry types.

Generating SBOMs from Container Images

With registry access configured, you can begin adding container images for SBOM generation. This process is consistent regardless of your registry provider:

# Add images from any supported registry

anchorectl image add registry_url/repository:tag

# Examples for different registries:

# AWS ECR

anchorectl image add aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag

# Azure ACR  

anchorectl image add myregistry.azurecr.io/myapp:v1.0

# Google GCR

anchorectl image add gcr.io/my-project/myapp:v1.0

# Harbor

anchorectl image add harbor.company.com/project/myapp:v1.0

Anchore Enterprise will download the image from your registry, unpack and analyze it, then store the comprehensive SBOM in its database. You can also add annotations during scanning for better organization:

anchorectl image add registry_url/repository:tag –annotation owner=team-alpha

Verify images have been added:

anchorectl image list

Both UI and CLI (AnchoreCTL) image analysis are described in further detail here.

Inspecting Container SBOMs for Vulnerabilities

Once SBOMs are stored in Anchore Enterprise, you can analyze their contents through both UI and CLI interfaces. The analysis capabilities remain consistent regardless of the source registry.

With your SBOMs now stored in Anchore Enterprise, you can view the respective contents through the UI by clicking on the image digest:

Next, click on the Vulnerabilities (UI) tab to see a list of vulnerabilities present in this image. From here you can toggle on/off severity or OS/non-OS CVEs. You can also download the vulnerability report for both the entire image or a particular vulnerability itself. Doing the latter will allow you to find all other images impacted by this vulnerability!

You can also use the CLI tooling for this purpose, using the flag for all vulnerability types:

# View all vulnerabilities in an image

anchorectl image vulnerabilities registry_url/repository:tag -t all

# Export vulnerability data for further processing

anchorectl image vulnerabilities registry_url/repository:tag -o json > vuln_report.json

NOTE: You can also reference the unique digest in your CLI commands.

The vulnerability data includes detailed information about affected packages, severity scores, available fixes, and impact assessments that help prioritize remediation efforts.

Inspecting Container SBOMs for Additional Content

You can also use the SBOM as a mechanism to inspect the image for other contents, such as files, malware or secrets:

NOTE: SBOMs can be exported in either Native JSON (Syft), SPDX, or CycloneDX format.

Alternatively, you can use the CLI and API (via AnchoreCTL) for inspecting your container SBOM (for vulnerabilities).

To view all available content types cataloged in the SBOM, use the -a flag:

anchorectl image content aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -a

To list secrets which may have been located in the image:

anchorectl image content aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -t secret_search

For malware (which is available via centralized analysis) you can use:

anchorectl image content aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -t malware

NOTE: SBOM content search patterns are described in further detail here.

SBOM:

anchorectl image sbom aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -f <file>

NOTE: SBOMs can be exported via the UI or AnchoreCTL for external use.

What’s Next

In Part 2 of this series, we’ll explore how to leverage these SBOMs for automated compliance checking, policy enforcement, and comprehensive reporting across your entire container portfolio. We’ll cover how to customize policies for your organization’s specific compliance requirements and generate the reports needed for audit and governance purposes.

---

This is Part 1 of a 2-part series on automated SBOM management. [Continue to Part 2: Compliance and Policy Management →]

---