Software Bills of Materials (SBOMs) are critical for transparency and compliance. Think of them as the ingredients list for software, a simple record of what went in. But as attackers continue to target and exploit software supply chains, that ingredient list plays an increasingly important role in securing your software supply chain.

When you index SBOMs they become an accessible part of day-to-day workflows. They give you a clearer view of what you’re actually shipping and provide enough detail to make decisions earlier, before a risky dependency makes its way further downstream.

This post focuses on the shift in SBOM usage from descriptive document to proactive security tool. We’ll look at how SBOMs support prevention and how teams use SBOM-based policy enforcement to keep risks out of their pipelines.

Why SBOMs matter for prevention

A container image may look straightforward on the surface, but the real risk often sits several layers deep. The build process can indirectly introduce transitive dependencies and SBOMs expose that level of detail.

Once you have a detailed account of what’s inside an image, you can enforce rules that reflect how you want to build and consume software.

When using SBOMs for prevention, teams can:

• Block containers that include components with known vulnerabilities
• Apply license policies to the full contents of an image
• Catch issues buried multiple levels down the dependency tree
• Make security checks consistent across teams and pipelines

Put simply, SBOMs add context to policy decisions by exposing the components inside an image. Alongside metadata, SBOMs make it possible to apply existing rules more precisely when transitive dependencies introduce risk.

How Cloudsmith supports SBOM-driven prevention

To make SBOM-based policy enforcement dependable, teams need two things: 

1. Current intelligence about vulnerabilities and malicious packages
2. A consistent control point that evaluates every container in the same way

Cloudsmith provides both through continuous scanning and automated policy enforcement.

Generating SBOMs

Cloudsmith automatically generates CycloneDX format SBOMs during container image package synchronization. Once created, SBOM data is accessible by the Enterprise Policy Manager (EPM) schema, allowing you to incorporate them into security policies. You can also retrieve SBOMs via API or download them directly from the Cloudsmith UI.

For non-Docker artifacts, you can store SBOMs directly within packages. More information about how Cloudsmith generates and handles SBOMs is available here.

Policy enforcement at the point of entry

EPM evaluates artifacts automatically whenever they’re pushed, synchronized, or re-checked due to updated intelligence. Built on Open Policy Agent (OPA) to be highly flexible, EPM enforces policies on both artifact metadata and Cloudsmith-generated SBOM contents, then applies the outcome you define: allow, flag, quarantine, or block.

Policies can incorporate things like:

• High-risk or vulnerable component versions
• Disallowed licenses
• Naming and versioning conventions
• Publish-date or freshness constraints

Keeping risk information current

Threat intelligence changes constantly. Risks can emerge through newly published CVEs, the identification of malicious packages, or upstream dependency changes. Cloudsmith keeps this information current by ingesting data from sources like Aqua Trivy, OSV, NVD, the GitHub Advisory Database, and the OpenSSF Malicious Packages project. EPSS scoring adds context around how likely a vulnerability is to be exploited in practice.

Cloudsmith’s Continuous Security feature checks these data sources for new vulnerabilities every hour and matches them to artifacts in your Cloudsmith repositories. When Continuous Security detects a threat that affects an artifact in your workspace it triggers an Enterprise Policy Manager policy evaluation with the vulnerability data included in the policy input. This removes the gap between the existence of new information and your system’s ability to act on it.

Enforcing policy at the component level

Because EPM understands SBOMs, Cloudsmith can enforce policies at the component level, not just at the image level. This gives teams fine-grained control without adding friction to developer workflows.

Because of the nature of software supply chain threats and vulnerabilities, developers and security teams need policies that meet threats as they arise. Both proactive and reactive policies play a role in your overall security posture.

Proactive examples

These policies help restrict known issues and non-compliant components before they land in a pipeline.

• License enforcement: Check transitive dependencies for licenses that don’t meet your organization’s requirements.
• Vulnerability thresholds: Define a policy that quarantines any image containing a component with a CVSS score above a specified level.

Reactive example

The pace with which threats emerge makes it impossible to rely solely on proactive policies. Reactive rules can function as an important zero-day stopgap. These rules give teams a predictable way to lock down newly identified risks, before they hit OSV and other data sources, without chasing them manually.

• Deny rules for specific components: A deny rule for a specific package or version applies both to direct package downloads and to any Docker image that includes that package as a component, ensuring the same restriction is enforced regardless of how the package is consumed.

Turning SBOM visibility into policy enforcement at scale

SBOMs give you insight into the components you’re shipping, but their true value is in the action(s) this insight triggers. Enterprise Policy Manager lets you use that insight to trigger actions that keep known risks out of your pipeline. EPM uses SBOMs to ensure every component in your pipeline meets your organization’s specific security and license requirements, automatically and at scale.

Existing customers: Put your SBOMs to work. Contact Customer Success to enable Enterprise Policy Manager. Reach Out.

Explore Cloudsmith: See why the world's leading enterprises trust us to automate artifact policy. Book a Demo.

Frequently Asked Questions (FAQ)

Q: How does SBOM enforcement differ from traditional vulnerability scanning?

Traditional scanning often focuses on the final artifact's metadata. SBOM enforcement looks at the "ingredients" list (the dependencies) of the artifact, allowing you to block specific internal components even if the top-level artifact is marked as safe.

Q: Can Cloudsmith EPM block builds based on OPA policies?

Yes. Cloudsmith EPM uses Open Policy Agent (OPA) to evaluate artifacts at the moment they are pushed. If an artifact violates a Rego policy (e.g., contains a banned license), EPM can quarantine the file immediately and prevent it from being downloaded, keeping non-compliant packages and dependencies out of your builds.