Author: Jono Bergquist

If you’ve been following the Department of Defense’s (DoD) modernization efforts, you have probably noticed a significant shift in how the US Navy approaches deployment. Historically, the path to an Authorization to Operate (ATO) was a grueling marathon that often delayed critical capabilities by months or years. Today, the U.S. Navy is pivoting toward a model that prioritizes speed without sacrificing the rigorous security standards required for mission-critical systems.

At the heart of this transformation is RAISE 2.0. It is a framework designed to automate the Risk Management Framework (RMF) and move away from static, one-time security checks. By leveraging an authorized RAISE Platform of Choice (RPoC), the Navy is essentially rewriting the rules of software delivery.

Visibility: The Foundation of Every Security Check

Before you can secure a system, you must understand its composition. In the microservices-based world we operate in today, software stacks have become increasingly complex. They are no longer single blocks of code but intricate webs of dependencies. The Navy recognizes that you cannot defend a “black box” against modern threats like Log4j or any of the recent supply chain compromises.

As Brian Thomason, Partner and Solutions Engineering Manager at Anchore, puts it: “It’s hard to know what to fix in your software…if you don’t know what’s in your software.” This is why the security process begins with a high-fidelity Software Bill of Materials. An SBOM is a comprehensive ingredients list for your application. 

How can we expect to manage risk if we are blind to the very components we are deploying?

Stop Waiting for ATOs: The Power of Inheritance

The traditional ATO process required every new application to justify its entire existence from the hardware up. This created a massive bottleneck where security teams were constantly re-evaluating the same underlying infrastructure and DevSecOps tools. RAISE 2.0 solves this by introducing the concept of a RAISE Platform of Choice (RPoC) (i.e., the Navy’s version of the more general DoD DevSecOps Platform or DSOP) with a pre-existing ATO.

“Raise 2.0 automates the RMF…eliminating the need for a new ATO; instead you inherit the ATO of the RPoC.” This mechanism allows application teams to focus solely on the security of their specific code rather than the platform it runs on. Why waste months certifying a pipeline that has already been vetted and hardened by experts? By inheriting a certified platform’s posture, developers can move from “code complete” to “production ready” in days rather than years.

The Accidental Leak: Moving Beyond Simple CVEs

Security isn’t just about identifying known vulnerabilities in 3rd-party libraries; it’s also about catching the human errors that occur during the heat of a sprint. While we like to think our internal processes are foolproof, history shows that sensitive credentials (think: AWS or SSH keys) find their way into repositories with surprising frequency.

Anchore’s platform doesn’t just look for CVEs; it scans for these “silent” risks. Brian notes: “We also detect leaked secrets… not that anybody in your organization would do this… but companies have been known to…” This capability acts as a critical safety net for developers working in high-pressure environments. What happens to your security posture if a single accidental commit exposes the keys to your entire cloud environment?

Security for Tomorrow: Managing the Zero-Day Disclosures

The moment an application is deployed, its security posture begins to decay. New zero-day disclosures and changing requirements mean that a “clean” scan from yesterday may be irrelevant by tomorrow morning. Static security checks are insufficient for modern warfare. We need continuous intelligence that tracks code throughout its entire lifecycle.

“Future changes; new requirements, zero-day disclosures, etc. are covered by Anchore’s SBOM-based approach.” By maintaining a version-controlled SBOM in a tool like Anchore Enterprise, the Navy can rescan deployed code against new threat intelligence every 12 hours. This provides a continuous feedback loop: if a new vulnerability is discovered in a library you deployed six months ago, you are notified immediately. Is your current process capable of identifying risks in software that is already deployed in production?

The Path Forward: Two Steps and One Habit

Implementing RAISE 2.0 principles isn’t an overnight task, but it is the only viable path for modernizing federal software delivery.

• Step 1: Standardize on SBOM generation. Integrate high-fidelity SBOM creation into your build process immediately to establish a baseline of truth.
• Step 2: Map your RMF controls to automation. Identify which parts of your compliance checklist can be handled by a platform like Black Pearl and/or Anchore.
• The Habit: Continuous Rescanning. Make it a daily practice to check your production inventory against the latest vulnerability data (KEV/EPSS), rather than waiting for your next scheduled audit.

The goal isn’t just to achieve an ATO today; it’s to build a system that remains secure and compliant through whatever challenges tomorrow brings.

Watch Now

If you have ever tried to manually apply a Security Technical Implementation Guide (STIG) to a modern containerized environment, you know it feels like trying to fit a square peg into a round hole…while the hole is moving at 60 miles per hour.

The Department of Defense’s move to DevSecOps (and adoption of the DoD Software Factory paradigm) has forced a collision between rigid compliance standards and the fluid reality of cloud-native infrastructure. The old way of “scan, patch, report” simply doesn’t scale when you are deploying thousands of containers a day.

We recently sat down with Aaron Lipult, Chief Architect at MITRE to discuss the MITRE Security Automation Framework (SAF) to discuss how they are solving this friction. The conversation moved past the basics of “what is a STIG?” and into the architectural philosophy of how we can actually automate compliance without breaking the mission.

Here are four key takeaways on why the future of government compliance is open, active, and strictly standardized.

Collaboration over monetization

In an industry often dominated by proprietary “black box” security tools, MITRE SAF stands out by being radically open. The framework wasn’t designed to lock users into a vendor ecosystem; it was designed to solve a national security problem.

The philosophy is simple: security validation code should be as accessible as the application code it protects.

“MITRE SAF came from public funds, it should go back into the public domain. In my opinion, it was built to solve a problem for everybody—not just us.”

This approach fundamentally changes the dynamic between government agencies and software vendors. Instead of every agency reinventing the wheel, the community converged on a shared standard. When one team solves a compliance check for Red Hat Enterprise Linux 8, that solution goes back into the public domain for every other agency to use. It shifts compliance from a competitive differentiator to a collaborative baseline.

“Immutable” container myth

There is a prevalent theory in DevSecOps that containers are immutable artifacts. In a perfect world, you build an image, scan it, deploy it, and never touch it again. If you need to change something, you rebuild the image.

The reality of operations is much messier. Drift happens. Emergency patches happen. Humans happen.

“Ops will still login and mess with ‘immutable’ production containers. I really like the ability to scan running containers.”

If your compliance strategy relies solely on scanning images in the registry, you are missing half the picture. A registry scan tells you what you intended to deploy. A runtime scan tells you what is actually happening.

MITRE SAF accounts for this by enabling validation across the lifecycle. It acknowledges the operational headache that rigid immutability purism ignores: sometimes you need to know if a production container has drifted from its baseline, regardless of what the “gold image” says.

Real system interrogation vs static analysis

For years, the standard for compliance scanning has been SCAP (Security Content Automation Protocol). While valuable, legacy tools often rely on static analysis. They check file versions or registry keys without understanding the running context.

Modern infrastructure requires more than just checking if a package is installed. You need to know how it is configured, what process it is running under, and how it interacts with the system.

“Older tools like SCAP do static file system analysis. It doesn’t actually do real system interrogation. That’s what we’re changing here. If we didn’t, we would deploy insecure systems into production.”

This is the shift from “checking a box” to “verifying a state.” Real system interrogation means asking the live system questions. Is the port actually open? Is the configuration file active, or is it being overridden by an environment variable?

By moving to “real interrogation,” we stop deploying systems that are technically compliant on paper but insecure in practice.

The discipline of compliance automation

One of the most frustrating aspects of STIG compliance is the rigidity of the source material. Engineers often look at a STIG requirement and think, “I know a better way to secure this.”

But in the world of DoD authorization (ATO), creativity can be a liability. The goal of automation isn’t just security; it’s auditability.

“We write the SAF rules to follow the STIG profile ‘as written’, even if we know it could be done ‘better.’ You are being held accountable to the profile, not what is ‘best’.”

This is the hard truth of compliance automation. MITRE SAF creates a direct, defensible mapping between the written requirement and the automated check. If the STIG says “Check parameter X,” the automation must check parameter X, even if checking parameter Y would be more efficient.

This discipline ensures that when an auditor reviews your automated results, there is zero ambiguity. You aren’t being graded on your creativity; you are being graded on your adherence to the profile. By keeping the tooling “true to the document,” MITRE SAF streamlines the most painful part of the ATO process: proving that you did exactly what you said you would do.

The Path Forward

The transition to automated compliance isn’t just about buying a new tool; it’s about adopting a new mindset. It requires moving from static files to active interrogation, from proprietary silos to open collaboration, and from “creative” security to disciplined adherence.

MITRE SAF provides the framework to make this transition possible. By standardizing how we plan, harden, and validate our systems, we can finally stop fighting the compliance paperwork and start focusing on the mission.

Ready to see it in action? Watch our full webinar with the MITRE team.

Learn how to use the MITRE corporation’s SAF framework to automation compliance audits. Never fill out another compliance spreadsheet.

Watch Now

As 2025 draws to a close, we are looking back at the posts that defined the year in software supply chain security. If 2024 was the year the industry learned what an SBOM was, 2025 was the year we figured out how to use them effectively and why they are critical for the regulatory landscape ahead.

The Anchore content team spent the last twelve months delivering expert guides, engineering deep dives, and strategic advice to help you navigate everything from the EU Cyber Resilience Act to the complexities of Python dependencies.

This top ten list reflects a maturing industry where the focus has shifted from basic awareness to actionable implementation. Hot topics this year included:

• Mastering SBOM generation for complex ecosystems like JavaScript and Python
• Preparing for major regulations like the EU CRA and DoD STIGs
• Reducing noise in vulnerability scanning (see ya later, false positives!)
• Engineering wins that make SBOM scanning faster and vulnerability databases smaller

So, grab your popcorn and settle in; it’s time to count down the most popular Anchore blog posts of 2025!

The Top Ten List

10 | Add SBOM Generation to Your GitHub Project with Syft

Kicking us off at number 10 is a blog dedicated to making security automation painless. We know that if security isn’t easy, it often doesn’t happen.

Add SBOM Generation to Your GitHub Project with Syft is a practical guide on integrating sbom-action directly into your GitHub workflows. It details how to set up a “fire and forget” system where SBOMs are automatically generated on every push or release.

This post is all about removing friction. By automating the visibility of your software components, you take the first step toward a transparent software supply chain without adding manual overhead to your developers’ plates.

9 | Syft 1.20: Faster Scans, Smarter License Detection

Coming in at number nine is a celebration of speed and accuracy. Two things every DevSecOps team craves.

Syft 1.20: Faster Scans, Smarter License Detection made waves this year by announcing a massive performance boost; 50x faster scans on Windows! But speed wasn’t the only headline. This release also introduced improved Bitnami support and smarter handling of unknown software licenses.

It’s a look at how we are continuously refining the open source tools that power your supply chain security. The improvements ensure that as your projects grow larger, your scans don’t get slower.

8 | False Positives and False Negatives in Vulnerability Scanning

Landing at number eight is a piece tackling the industry’s “Boy Who Cried Wolf” problem: noise.

False Positives and False Negatives in Vulnerability Scanning explores why scanners sometimes get it wrong and what we are doing about it. It details Anchore’s evolution in detection logic. Spoiler alert: we moved away from simple CPE matching toward more precise GHSA data. This was done to build trust in your scan results.

Reducing false positives isn’t just about convenience; it’s about combating alert fatigue so your security team can stop chasing ghosts and focus on the real threats that matter.

7 | Generating SBOMs for JavaScript Projects

Sliding in at lucky number seven, we have a guide for taming the chaos of node_modules.

Generating SBOMs for JavaScript Projects addresses one of the most notoriously complex ecosystems in development. JavaScript dependencies can be a labyrinth of nested packages but this guide provides a clear path for developers to map them accurately using Syft.

We cover both package.json manifests and deeply nested, transitive dependencies. This is essential for frontend, backend and full stack devs looking to secure their modern web applications against supply chain attacks.

6 | Generating Python SBOMs: Using pipdeptree and Syft

At number six, we turn our attention to the data scientists and backend engineers working in Python.

Generating Python SBOMs: Using pipdeptree and Syft offers a technical comparison between standard tools like pipdeptree and Syft’s universal approach. Python environments can be tricky, but this post highlights why Syft’s ability to capture extensive metadata offers a more comprehensive view of risks.

If you want better visibility into transitive dependencies (the libraries of your libraries) this post explains exactly how to get it.

5 | Grype DB Schema Evolution: From v5 to v6

Breaking into the top five, we have an engineering deep dive for those who love to see what happens under the hood.

Grype DB Schema Evolution: From v5 to v6 details the redesign of the Grype vulnerability database. While database schemas might not sound like the flashiest topic, the results speak for themselves: moving to Schema v6 reduced download sizes by roughly 69% and significantly sped up updates.

This is a critical improvement for users in air-gapped environments or those running high-volume CI/CD pipelines where every second and megabyte counts.

4 | Strengthening Software Security: The Anchore and Chainguard Partnership

At number four, we highlight a power move in the industry: two leaders joining forces for a unified goal.

Strengthening Software Security: The Anchore and Chainguard Partnership details how we teamed up with Chainguard to help you “Start Safe and Stay Secure.” It explains how combining Chainguard’s hardened wolfi images with the Anchore Enforce‘s continuous compliance platform creates a seamless, secure workflow from build to runtime.

The key takeaway? Reducing your attack surface starts with a secure base image but maintaining that secure initial state requires continuous monitoring.

3 | EU CRA SBOM Requirements: Overview & Compliance Tips

Taking the bronze medal at number three is a wake-up call regarding the “Compliance Cascade.”

EU CRA SBOM Requirements: Overview & Compliance Tips breaks down the EU Cyber Resilience Act (CRA), a regulation that is reshaping the global software market. We covered the timeline, the mandatory SBOM requirements coming in 2027, and why compliance is now a competitive differentiator.

If you sell software in Europe (or sell to a business that sells software in Europe) this post was your signal to start preparing your evidence now. Waiting until the last minute is not a strategy!

2 | DISA STIG Compliance Requirements Explained

Just missing the top spot at number two is our comprehensive guide to the DoD’s toughest security standard.

DISA STIG Compliance Requirements Explained demystifies the Security Technical Implementation Guides (STIGs). We broke down the difference between Category I, II, and III vulnerabilities and showed how to automate the validation process for containers.

This is a must-read for any vendor aiming to operate within the Department of Defense network. It turns a daunting set of requirements into a manageable checklist for your DevSecOps pipeline.

1 | How Syft Scans Software to Generate SBOMs

And finally, taking the number one spot for 2025, is the ultimate technical deep dive!

How Syft Scans Software to Generate SBOMs peeled back the layers of our open source engine to show you exactly how the magic happens. It explained Syft’s architecture of catalogers, how stereoscope parses image layers, and the logic Syft uses to determine what is actually installed in your container.

Trust requires understanding. By showing exactly how we build an SBOM, we empower teams to trust the data they rely on for critical security decisions.

Wrap-Up

That wraps up the top ten Anchore blog posts of 2025! From deep dives into scanning logic to high-level regulatory strategy, this year was about bridging the gap between knowing you need security and doing it effectively.

The common thread? Whether it’s complying with the EU CRA or optimizing a GitHub Action, the goal remains the same: security and speed at scale. We hope these posts serve as a guide as you refine your DevSecOps practice and steer your organization toward a more secure future.

Stay ahead of the curve in 2026. Subscribe to the Anchore Newsletter or follow us on your favorite social platform to catch the next big update:

• LinkedIn
• Bluesky
• Mastodon
• X

If you’ve spent any time in the software security space recently, you’ve likely heard the comparison: a Software Bill of Materials (SBOM) is essentially an “ingredients list” for your software. Much like the label on a box of crackers, an SBOM tells you exactly what components, libraries, and dependencies make up your application.

But as any developer knows, a simple label can be deceptive. “Spices” on a food label could mean anything; “tomatoes” could be fresh, canned, or powdered. In software, the challenge is moving from a vague inventory to a detailed, machine-readable explanation of what is truly inside.

In a recent Cloud Native Now webinar, Anchore’s VP of Security, Josh Bressers, demystified the process of generating these critical documents using free, open source tools. He demonstrated the practical “how-to” for a world where SBOMs have moved from “nice-to-have” to “must-have.”

From Security Novelty to Compliance Mandate

For years, early adopters used SBOMs because they were “doing the right thing.” It was a hallmark of a high-maturity security program; a way to gain visibility that others lacked. But the landscape shifted recently.

“Before 2025, SBOMs were ‘novelties;’ they were ‘doing the right thing’ for security. Now they are mandatory due to compliance requirements.”

Global regulations like the EU’s Cyber Resilience Act (CRA) and FDA mandates in the U.S. have changed the math. If you want to sell software into the European market, or the healthcare sector, an SBOM is no longer a gold star on your homework; it’s the price of admission. The “novelty” phase is over. We are now in the era of enforcement.

Why Compliance is the New Proof

We often talk about SBOMs in the context of security. They are vital for identifying vulnerabilities like Log4j in minutes rather than months. However, the primary driver for adoption across the industry isn’t a sudden surge in altruism. It’s the need for verifiable evidence.

“So compliance is why we’re going to need SBOMs. That’s the simple answer. It’s not about security. It’s not about saying we are doing the right thing. It’s proof.”

Security is the outcome, but compliance is the driver. An SBOM provides the machine-readable “proof” that regulators and customers now demand. It proves you know what you’re shipping, where it came from, and that you are monitoring it for risks. In the eyes of a regulator, if it isn’t documented in a standard format like SPDX or CycloneDX, it doesn’t exist.

Getting Started: The Crawl, Walk, Run Approach

When teams realize they need an SBOM strategy, the first instinct is often to over-engineer. They look for complex database integrations or expensive enterprise platforms before they’ve even generated their first file. My advice is always to start with the simplest path possible.

“To start, store the SBOM in the project’s directory. This is one of those situations where you crawl, walk, run. Start putting them somewhere easy. Don’t overthink it.”

You don’t need a massive infrastructure to begin. Using open source tools like Syft, you can generate an SBOM from a container image or a local directory in seconds.

1. Crawl: Generate an SBOM manually using the CLI and save it as a JSON file in your project repo.
2. Walk: Integrate that generation into your CI/CD pipeline (e.g., using a GitHub Action) so an SBOM is created automatically with every release.
3. Run: Generate an SBOM for multiple stages of the DevSecOps pipeline, store them in a central repository and query them for actionable supply chain insights.

The Pursuit of Perfection in an Imperfect World

Software is messy. Dependencies have dependencies and scanners sometimes miss things or produce false positives. While the industry is working hard to improve the accuracy of software supply chain tools, transparency about our limitations is key.

“Our goal is perfection. We know it’s unattainable, but that’s what we’re working towards.”

We strive for a 100% accurate inventory, but “perfect” should never be the enemy of “better.” Having a 95% accurate SBOM today is infinitely more valuable during a zero-day event than having no SBOM at all while you wait for a perfect solution.

Wrap-Up

The transition from manual audits to automated, compliance-driven transparency is the biggest shift in software security this decade. By starting small with open source tooling, focusing on compliance as your baseline, and iterating toward better visibility, you can transform your security posture from reactive to proactive.

Ready to generate your first SBOM?

• Download Syft: The easiest way to generate an SBOM for containers and filesystems.
• Try Grype: Vulnerability scanning that works seamlessly with your SBOMs.
• Watch the full webinar below.

Stay ahead of the next regulatory mandate: Follow Anchore on LinkedIn for more insights into the evolving world of software supply chain security.

The transition from physical servers to Infrastructure as Code fundamentally transformed operations in the 2010s—bringing massive scalability alongside new management complexities. We’re witnessing history repeat itself with software supply chain security. The same pattern that made manual server provisioning obsolete is now playing out with Software Bill of Materials (SBOM) management. This pattern is creating an entirely new category of operational debt for organizations that refuse to adapt.

The shift from ad-hoc security scans to continuous, automated supply chain management is not just a technical upgrade. At enterprise scale, you simply cannot secure what you cannot see. You cannot trust what you cannot verify. Automation is the only mechanism that delivers consistent visibility and confidence in the system.

“Establishing trust starts with verifying the provenance of OSS code and validating supplier SBOMs. As well as, storing the SBOMs to track your ingredients over time.”

The Scale Problem: When “Good Enough” Isn’t

Manual processes work fine until they don’t. When you are managing a single application with a handful of dependencies you can get away with lots of unscalable solutions. But modern enterprise environments are fundamentally different. A single monolithic application might have had stable, well-understood libraries but modern cloud-native architectures rely on thousands of ephemeral components that change daily.

This fundamental difference creates a visibility crisis that traditional spreadsheets and manual scans cannot solve. Organizations attempting to manage this complexity with “Phase 1” tactics like manual scans or simple CI scripts typically find themselves buried under a mountain of data.

Supply Chain Security Evolution

• Phase 1: The Ad-Hoc Era (Pre-2010s) was characterized by manual generation and point-in-time scanning. Developers would run a tool on their local machine before a release. This was feasible because release cycles were measured in weeks or months, and dependency trees were relatively shallow.
• Phase 2: The Scripted Integration (2020s) brought entry-level automation. Teams wired open source tools like Syft and Grype into CI pipelines. This exploded the volume of security data without a solution for scaling data management. “Automate or not?” became the debate, but it missed the point. As Sean Fazenbaker, Solution Architect at Anchore, notes: “‘Automate or not?’ is the wrong question. ‘How can we make our pipeline set and forget?’ is the better question.”
• Phase 3: The Enterprise Platform (Present) emerged as organizations realized that generating an SBOM is only the starting line. True security requires managing that data over time. Platforms like Anchore Enterprise transformed SBOMs from static compliance artifacts into dynamic operational intelligence, making continuous monitoring a standard part of the workflow.

The Operational Reality of “Set and Forget”

The goal of Phase 3 is to move beyond the reactive “firefighting” mode of security. In this model, a vulnerability disclosure like Log4j triggers a panic: teams scramble to re-scan every artifact in every registry to see if they are affected.

In an automated, platform-centric model, the data already exists. You don’t need to re-scan the images; you simply query the data you’ve already stored. This is fundamentally different from traditional vulnerability management.

Anchore scans SBOMs built whenever: five months from now, six months ago, 30 years in the future. If a new vulnerability is detected, you’ll know when, where and for how long.

Continuous assessment of historical artifacts is what separates compliance theater from true resilience. It allows organizations to answer the critical question (“Are we affected?”) in minutes rather than months.

The Implementation of Shift Left

Automation also fundamentally changes the developer experience. In traditional models, security is a gatekeeper that fails builds at the last minute, forcing context-switching and delays. In an automated, policy-driven environment, security feedback is immediate.

When automation is integrated correctly into the pull request workflow, developers can resolve issues before code ever merges. “I’ve identified issues. Fixed them. Rebuilt and pushed. I didn’t rely on another team to catch my mistakes. I shifted left instead.”

This is the promise of DevSecOps: security becomes a quality metric of the code, handled with the same speed and autonomy as a syntax error or a failed unit test.

Where Do We Go From Here?

We are still in the early stages of this evolution, which creates both risk and opportunity. First-movers can establish a trust foundation before the next major supply chain incident. Those who wait will face the crushing weight of manual management.

Crawl: The Open Source Foundation

Start with industry standards. Tools like Syft (SBOM generation) and Grype (vulnerability scanning) provide the baseline capabilities needed to understand your software.

1. Generate SBOMs for your critical applications using Syft.
2. Scan for vulnerabilities using Grype to understand your current risk posture.
3. Archive these artifacts to begin building a history, even if it is just in a local filesystem or S3 bucket.

Walk: Integrated Automation

Early adopters can take concrete steps to wire these tools into their daily flow:

1. Integrate scans into GitHub Actions (or your CI of choice) to catch issues on every commit.
2. Define basic policies (e.g., “fail on critical severity”) to prevent new risks from entering production.
3. Separate generation from scanning. It is often more efficient to generate the SBOM once and scan the JSON artifact repeatedly, rather than re-analyzing the heavy container image every time.

Want to bring these steps to life? Watch the full Automate, Generate, and Manage SBOMs webinar to see exactly how to wire this up in your own pipeline.

Anchore Enterprise 5.24 adds native filesystem scanning and policy enforcement for imported SBOMs so platform engineers and security architects can secure non-container assets with the same rigor as containers. With software supply chains expanding beyond registries to include: 

• virtual machine images,
• source code tarballs, and
• directory-based artifacts.

This release focuses on increasing supply chain coverage and active governance. It replaces disparate, manual workflows for non-container assets with a unified approach. And turns passive 3rd-party SBOMs into active components of your compliance strategy.

What’s New in AE 5.24

This release introduces three capabilities designed to unify security operations across your entire software stack:

• Native Filesystem Scanning: Ingest and analyze VMs, source directories, and archives directly via anchorectl, removing the need for manual SBOM generation steps.
• Policy Enforcement for Imported SBOMs: Apply vulnerability policy gates to 3rd-party SBOMs to automate compliance decisions for software you didn’t build.
• Advanced Vulnerability Search: Instantly locate specific CVEs or Advisory IDs across your entire asset inventory for rapid zero-day response.

Watch a walkthrough of new features including a demo with Alex Rybak, Director of Product.

Watch Now

Native Filesystem Scanning & Analysis

Anchore Enterprise now natively supports the ingestion and analysis of arbitrary filesystems. Previously, users had to run Syft independently to generate an SBOM and then upload it. Now, the platform handles the heavy lifting directly via anchorectl.

This streamlines the workflow for hybrid environments. You can now scan a mounted VMDK, a tarball of source code, or a build directory using the same pipeline logic used for container images.

Using the updated anchorectl CLI, you can point directly to a directory or mount point. Anchore handles the SBOM generation and ingestion in a single step.

# Example: Ingesting a mounted VM image for analysis

anchorectl sbom add \

  --from ./my_vmdk_mount_point \

  --name my-vm-image \

  --version 1.0 \

  --sbom_type file-system

# Example: Ingesting a mounted VM image for analysis

anchorectl sbom add \

  --from ./my_vmdk_mount_point \

  --name my-vm-image \

  --version 1.0 \

  --sbom_type file-system

Active Compliance for Imported SBOMs (BYOS)

Imported SBOMs (Bring Your Own SBOM) have graduated from read-only data artifacts to fully governed assets. AE 5.24 introduces vulnerability policy gates for imported SBOMs.

Visibility without enforcement is noise. By enabling policy assessments on imported SBOMs, you can act as a gatekeeper for vendor-supplied software. For example, you can now automatically fail a build or flag a vendor release if the provided SBOM contains critical vulnerabilities that violate your internal security standards (e.g., Block if Critical Severity count > 0).

Rapid Response with Advanced Search

When a major vulnerability (like Log4j or OpenSSL) is disclosed, the time to identify affected assets is critical. AE 5.24 adds a unified search filter to the Vulnerabilities List View that accepts both Vulnerability IDs (CVE) and Advisory IDs.

This reduces triage time during zero-day incidents. Security teams can paste a specific ID into a single filter to immediately identify exposure across all managed SBOMs and images, regardless of the asset type.

Expanded STIG Compliance Support

Continuing our support for public sector and regulated industries, this release expands the library of out-of-the-box compliance profiles. AE 5.24 adds support for:

• Apache Tomcat 9
• NGINX v2.3.0

These profiles map directly to DISA STIG standards, allowing teams to automate the validation of these ubiquitous web server technologies.

How to Get Started

1. Upgrade to Anchore Enterprise 5.24. Release notes →
2. Ingest a Filesystem: Use the new anchorectl sbom add --from <path> command to test scanning a local directory or VM mount.
3. Enforce Policy: Navigate to the Policies tab and verify that your default vulnerability rules are now evaluating your imported SBOMs.
4. Validate Compliance: Run a report against the new Tomcat or NGINX profiles if applicable to your stack.

Ready to Upgrade?

Anchore Enterprise 5.24 provides the universal visibility and active governance required to secure modern, hybrid software supply chains.

• Existing customers: Contact support or your account manager to plan your upgrade.
• New to Anchore? Request a demo to see the new features in action.
• Community: Explore our open-source tools Syft and Grype for local SBOM generation and scanning.

Watch a walkthrough of new features including a demo with Alex Rybak, Director of Product.

Watch Now

Using DevSecOps principles to approach software development is always the ideal. We love “secure by design” at Anchore but…unfortunately there are limits to how far this practice can stretch before it breaks. The messy reality of user needs and operational constraints often forces organizations to veer off the “golden path” paved by the best intentions of our security teams.

This is precisely where comprehensive software supply chain security and compliance solutions become critical. A start safe, stay secure approach can bridge the gap between the platonic ideal of security as it collides with the mess of real-world complexity.

Today, Anchore and Chainguard are expanding their partnership to bring that same philosophy to application dependencies. With Anchore Enterprise now integrated with Chainguard Libraries for Python, joint customers can validate the critical and high-severity CVEs Chainguard remediates. This reduces risk, eliminates unnecessary triage work, and secures dependencies without disrupting existing workflows.  

What Chainguard Libraries Means for Supply Chain Security

Chainguard Libraries extends the company’s “golden path” philosophy from minimal OS images to the application dependencies built on top. It provides a set of popular open source libraries, starting with Java, Python and JavaScript. The libraries are built from source in a tamper-proof, SLSA L2-certified environment that’s immune to build-time and distribution-stage malware injections. The goal is to provide developers with a set of trusted building blocks from the very start of the development process.

Anchore Enterprise users depend on continuous scanning and policy enforcement to manage software supply chain risk. But public package registries produce a relentless stream of alerts; many of them noisy, many irrelevant, and all of them requiring investigation. Even simple patching cycles become burdensome, reactive workstreams. This integration changes that.

More details about the integration:

• Validate Chainguard Python Library CVE Remediation in Anchore Enterprise Workflows: Anchore Enterprise users can now use their existing scanning pipelines to validate that CVEs remediated by Chainguard Libraries for Python correctly show up as fixed or absent. This brings trusted upstream content directly into Anchore; no new workflows and no operational friction. Just fewer critical vulnerabilities for your team to deal with.
• Strengthen Dependency Security and Reduce Malware Risk: Chainguard Libraries are built in a tamper-proof environment and free from supply chain refuse. This benefits Anchore customers by eliminating unverified/compromised packages and reducing dependency triage workload.  Recent ecosystem attacks like ultralytics or num2words underscore the importance of this integration.

Teams no longer start their security journey by cleaning up unknown packages from public registries. They begin with dependencies that are already vetted, traceable, and significantly safer.

Start Safe, Stay Secure, and Stay Compliant: From Golden Path to Real-World Operations

This is where Anchore Enterprise provides the critical framework to ‘Stay Secure and Compliant,’ bridging the gap between a secure-by-design foundation and the fluid realities of day-to-day operations.

Software Supply Chain Policy Scanning and Enforcement

Chainguard Libraries enable organizations to start safe. But applications evolve. Developers regularly need to diverge from these golden bases for legitimate business reasons.

How do we stay secure, even as we take a necessary side quest from the happy path? The answer is moving from static prevention to continuous policy enforcement. Anchore Enterprise enables organizations to stay both secure and compliant by enforcing risk-based policies, even when the security principles embedded in the Chainguard artifacts conflict with the immediate needs of the organization.

Zero-Day Disclosure Alerts on Chainguard OSes & Libs

A library or OS is only secure up until a zero-day disclosure is published. Chainguard publishes a security advisory feed (an OpenVEX feed) which provides a list of vulnerabilities associated with the libraries they distribute. When a new vulnerability is disclosed, Anchore Enterprise will detect this and flag it against the relevant content. This can be used to either drive a manual or automated pull of newer content from the Chainguard Libraries repo. Anchore Enterprise’s Policy Engine allows you to filter these out using simple rules to ensure you are not distracted except for the most critical of issues.

Proprietary & Compiled Binaries Vulnerability Scanning

The visibility challenge extends far beyond open source language libraries. Modern enterprise applications often integrate proprietary components where the content is not in a packaged form: think 3rd-party observability (or security runtime) agents, proprietary SDKs, compiled binaries from vendors, and custom in-house tooling. Organizations still require the ability to track and remediate vulnerabilities within these closed source components.

Anchore Enterprise solves this critical gap by employing deep binary analysis techniques. This capability allows the platform to analyze compiled files (binaries) and non-standard packages to identify and report vulnerabilities, licenses, and policy violations, ensuring a truly comprehensive security posture across every layer of the stack, not just the known-good base components.

Ingest Chainguard OS & Libraries SBOMs for Full Supply Chain Visibility

Ultimately, supply chain risk visibility, compliance and risk management allow a business to make informed decisions about when and how to allocate resources. To do this well, you need a system to store, query, and generate actionable insights from your evidence.

This presents another “buy vs. build” decision. An organization can build this system itself, or it can deploy a turnkey system like Anchore Enterprise. Anchore can generate SBOMs from Chainguard OS/Libraries or ingest the SBOMs from the Chainguard Registry, providing a single system to store, query, and manage risk across your entire software supply chain.

For a closer look, please connect with us or Chainguard for a demo. 

If you follow the software supply chain space, you’ve heard the noise. The industry often gets stuck in a format war loop; debating schema rather than focusing on the utility of the stored data. It’s like arguing about font kerning on a nutrition label while the ingredients list is passed over.

We recently hosted Steve Springett, Chair of the CycloneDX Core Working Group, to cut through this noise. The conversation moved past the basic definition of an SBOM and into the mechanics of true software transparency.

Here are four takeaways on where the industry is heading—and why the specific format doesn’t matter.

1. Content is king

For years, the debate has centered on “which standard will win.” But this is the wrong question to ask. The goal isn’t to produce a perfectly formatted SBOM; the goal is to reduce systemic risk and increase software transparency.

As Springett noted during the session:

“The format doesn’t really matter as long as that format represents the use cases. It’s really about the content.”

When you focus on form over function, you end up generating an SBOM to satisfy a regulator even while your security team gains no actionable intelligence. The shift we are witnessing is from generation to consumption.

Does your data describe the components? Does it capture the licensing? More importantly, does it support your specific use case, whether that’s procurement, vulnerability management, or forensics? If the content is empty, the schema validation is irrelevant.

2. When theory and reality diverge

In physical manufacturing, there is often a gap between the engineering diagrams and the finished product. Software is no different. We have the source code (the intent) and the compiled binary (the reality).

Springett ran into a situation where a manufacturer needed a way to model the dependencies of the process that created a product:

“We created a manufacturing bill of materials (MBOM) to describe how something should be built versus how it was actually built.”

This distinction is critical for integrity. A “Design BOM” tells you what libraries you intended to pull in. In this case, the Design MBOM and the Build MBOM were able to explain what parts of the process were diverging from the ideal path. Capturing this delta allows you to verify the integrity of the pipeline itself, not just the source that entered it.

3. Solving the compliance cascade

Security teams are drowning in standards. From SSDF to FedRAMP to the EU CRA, the overlap in requirements is massive, yet the evidence collection remains manual and disjointed. It is the classic “many-to-many” problem.

Machine-readable attestations are the mechanism to solve this asymmetry.

“A single attestation can attest to multiple standards simultaneously. This saves a lot of hours!”

Instead of manually filling out a spreadsheet for every new regulation, you map a single piece of evidence—like a secure build log—to multiple requirements. If you prove you use MFA for code changes, that single data point satisfies requirements in FedRAMP, PCI DSS 4.0, and SSDF simultaneously.

This shifts compliance from a manual, document-based operation to an automated process. You attest once, and the policy engine applies it everywhere.

4. Blueprints and behavioral analysis

Reproducible builds are a strong defense, but they aren’t a silver bullet. A compromised build system can very accurately reproduce the malware that has been pulled in from a transitive dependency. To catch this, you need to understand the intended behavior of the system, not just its static composition.

This is where the concept of “blueprints” comes into play.

“Blueprints are the high-level architecture AND what the application does. This is critically important because reproducible builds are fine, but can also be compromised.”

A blueprint describes the expected architecture. It maps the data flows, the expected external connections, and the boundary crossings. If your SBOM says “Calculator App,” but the runtime behavior opens a socket to an unknown IP, a static scan won’t catch it.

By comparing the architectural blueprint against the runtime reality, you can detect anomalies that standard composition analysis misses. It moves the defense line from “what is in this?” to “what is this doing?”

The Path Forward

We’ve moved past the era of format wars. The takeaways are clear: prioritize content over schema, capture the “as-built” reality, automate your compliance evidence, and start validating system behavior, not just static ingredients.

But this is just the baseline. In the full hour, Steve Springett dives much deeper into the mechanics of transparency. He discusses how to handle AI model cards to track training data and bias, how to manage information overload so you don’t drown in “red lights,” and what’s coming next in CycloneDX 1.7 regarding threat modeling and patent tracking.

To get the complete picture—and to see how these pieces fit into a “system of systems” approach—watch the full webinar. It’s the fastest way to move your strategy from passive documentation to active verification.

Learn about how SBOMs, and CycloneDX specifically, planning for the future. Spoiler alert: compliance, attestations and software transparency are all on deck.

Watch Now

The modern software supply chain is more complex and critical than ever. In an age of high-profile breaches and new global regulations like the EU’s Cyber Resilience Act, software supply chain security has escalated from an IT concern to a top-level business imperative for every organization. In this new landscape, transparency is foundational, and the Software Bill of Materials (SBOM) has emerged as the essential element for achieving that transparency and security.

Perhaps no single individual has been more central to the global adoption of SBOMs than Dr. Allan Friedman which only serves to increase our excitement to announce that Allan has joined Anchore as a Board Advisor.

A Shared Vision for a Secure Supply Chain

For years, Anchore has partnered with Allan to help build the SBOM community he first envisioned at NTIA and CISA. From active participation in his flagship “SBOM-a-Rama” events as an “SBOM-Solutions Showcase” to contributing to the Vulnerability Exploitability eXchange (VEX) standard.

Our VP of Security, Josh Bressers, has even taken over stewardship of Allan’s weekly SBOM community calls in a new form via the OpenSSF SBOM Coffee Club.

We’re thrilled to codify the partnership that has been built over many years with Allan and his vision for software supply chain security.

An In-Depth: A Conversation with Allan Friedman

We sat down with Allan to get his candid thoughts on the future of software supply chain security, the challenges that remain, and why he’s betting on Anchore.

You’ve been one of the primary architects of SBOM and software transparency policy at the federal level. What motivated you to join in the first place and what have you accomplished throughout your tenureship?

Security relies on innovation, but it also depends on collective action, building out a shared vision of solutions that we all need. My background is technical, but my PhD was actually on the economics of information security, and there are still some key areas where collective action by a community can make it easier and cheaper to do the right thing with respect to security. 

Before tackling software supply chain security, I launched the first public-private effort in the US government on vulnerability disclosure, bringing together security researchers and product security teams, and another effort on IoT “patchability.”

I certainly wasn’t the first person to talk about SBOM, but we helped build a common space where experts from across the entire software world could come together to build out a shared vision of what SBOM could look like. Like most hard problems, it wasn’t just technical, or business, or policy, and we tried to address all those issues in parallel. 

I also like to think we did so in a fashion that was more accessible than a lot of government efforts, building a real community and encouraging everyone to see each other as individuals. Dare I say it was fun? I mean, they let me run an international cybersecurity event called “SBOM-a-Rama.”

SBOM is a term that’s gone from a niche concept to a mainstream mandate. For organizations still struggling with adoption, what is the single most important piece of advice you can offer?

Even before we get to compliance, let’s talk about trust. Why would your customers believe in the security–or even the quality or value–of your products or processes if you can’t say with confidence what’s in the software? We also have safety in numbers now–this isn’t an unproven idea, and not only will peer organizations have SBOMs, your potential customers are going to start asking why you can’t do this if others can.

How do you see the regulatory environment developing in the US, Europe, or Asia as it relates to SBOMs over the next few years?

SBOM is becoming less of its own thing and more part of the healthy breakfast that is broader cybersecurity requirements and third party risk management. Over 2025, the national security community has made it clear that SBOM requirements are not just not fading away but are going to be front and center. 

Organizations that trade globally should already be paying attention to the SBOM requirements in the European Union’s Cyber Resilience Act. The requirements are now truly global: Japan has been a leader in sharing SBOM guidance since 2020, Korea integrated SBOM into their national guidance, and India has introduced SBOM requirements into their financial regulations.

Beyond government requirements, supply chain transparency has been discussed in sector-specific requirements and guidance, including PCI-DSS, the automotive sector, and telecommunications equipment.

Now that we see the relative success of SBOMs, as you look three to five years down the road, what do you see as the next major focus area, or challenge, in securing the software supply chain that organizations should be preparing for today?

As SBOM has gone from a controversial idea to a standard part of business, we’re seeing pushes for greater transparency across the software-driven world, with a host of other BOMs. 

Artificial intelligence systems should have transparency about their software, but also about their data, the underlying models, the provenance, and maybe even the underlying infrastructure. As quantum decryption shifts from “always five years away” to something we can imagine, we’ll need inventories of the encryption tools, libraries, and algorithms across complex systems. 

It would be nice if we can have transparency into the “how” as well as the “what,” and secure attestation technologies are transitioning from research to accessible automation-friendly processes that real dev shops can implement. 

And lastly, one of my new passions, software runs on hardware, and we are going to need to pay a lot more attention to where those chips are from and why they can be trusted: HBOM!

What do you hope to bring to the Anchore team and its strategy from your unique vantage point in government and policy?

I’m looking forward to working with the great Anchore team on a number of important topics. For their customers, how do we help them prioritize, and use SBOM as an excuse to level up on software quality, efficiency, and digital modernization. 

We also need to help the global community, especially policy-makers, understand the importance of data quality and completeness, not just slapping an SBOM label on every pile of JSON handy. This can be further supported by standardization activities, where we can help lead on making sure we’re promoting quality specifications. VEX is another area where we can help facilitate conversations with existing and potential users to make sure its being adopted, and can fit into an automated tool chain. 

And lastly, security doesn’t stop with the creation of SBOM data, and we can have huge improvements in security by working with cybersecurity tooling to make sure they understand SBOM data and can deliver value with better vulnerability management, asset management, and third party risk management tooling that organizations already use today.

Building the Future of Software Security, Together

We are incredibly excited about this partnership and what it means for our customers and the open-source community. With Allan’s guidance, Anchore is better positioned than ever to help every organization build trust in their software.To stay current on the progress that Allan Friedman and Anchore are making to secure the software industry’s supply chain, sign-up for the Anchore Newsletter.

Anchore Enterprise 5.23 adds CycloneDX VEX and VDR support, completing our vulnerability communication capabilities for software publishers who need to share accurate vulnerability context with customers. With OpenVEX support shipped in 5.22 and CycloneDX added now, teams can choose the format that fits their supply chain ecosystem while maintaining consistent vulnerability annotations across both standards.

This release includes:

• CycloneDX VEX export for vulnerability annotations
• CycloneDX VDR (Vulnerability Disclosure Report) for standardized vulnerability inventory
• Expanded policy gates for one-time scans (see below for full list)
• STIG profiles delivered via Anchore Data Service

The Publisher’s Dilemma: When Your Customers Find “Vulnerabilities” You’ve Already Fixed

Software publishers face a recurring challenge: customers scan your delivered software with their own tools and send back lists of vulnerabilities that your team already knows about, has mitigated, or that simply don’t apply to the deployed context. Security teams waste hours explaining the same fixes, architectural decisions, and false positives to each customer—time that could be spent on actual security improvements.

VEX (Vulnerability Exploitability eXchange) standards solve this by allowing publishers to document vulnerability status alongside scan data—whether a CVE was patched in your internal branch, affects a component you don’t use, or is scheduled for remediation in your next release. With two competing VEX formats—OpenVEX and CycloneDX VEX—publishers need to support both to reach their entire ecosystem. Anchore Enterprise 5.23 completes this picture.

How CycloneDX VEX Works in Anchore Enterprise

The vulnerability annotation workflow remains identical to the OpenVEX implementation introduced in 5.22. Teams can add annotations through either the UI or API, documenting whether vulnerabilities are:

• Not applicable to the specific deployment context
• Mitigated through compensating controls
• Under investigation for remediation
• Scheduled for fixes in upcoming releases

The difference is in the export. When you download the vulnerability report, you can now select CycloneDX VEX format instead of (or in addition to) OpenVEX. The annotation data translates cleanly to either standard, maintaining context and machine-readability.

Adding Annotations

Via UI: Navigate to the Vulnerability tab for any scanned image, select vulnerabilities requiring annotation, and choose Annotate to add status and context.

Via API: Use the /vulnerabilities/annotations endpoint to programmatically apply annotations during automated workflows.

Exporting CycloneDX VEX

After annotations are applied:

1. Navigate to the Vulnerability Report for your image
2. Click the Export button above the vulnerability table
3. In the export dialog, select CycloneDX VEX (JSON or XML format)
4. Download the machine-readable document for distribution

The exported CycloneDX VEX document includes all vulnerability findings with their associated annotations, PURL identifiers for precise package matching, and metadata about the scanned image. Customers can import this document into CycloneDX-compatible tools to automatically update their vulnerability databases with your authoritative assessments.

VDR: Standardized Vulnerability Disclosure

The Vulnerability Disclosure Report (VDR) provides a complete inventory of identified vulnerabilities in CycloneDX format, regardless of annotation status. Unlike previous raw exports, VDR adheres to the CycloneDX standard for vulnerability disclosure, making it easier for security teams and compliance auditors to process the data.

VDR serves different use cases than VEX:

• VEX communicates vulnerability status (not applicable, mitigated, under investigation)
• VDR provides comprehensive vulnerability inventory (all findings with available metadata)

Organizations can export both formats from the same Export dialog: VDR for complete vulnerability disclosure to auditors or security operations teams, and VEX for communicating remediation status to customers or downstream consumers.

To generate a VDR, click the Export button above the vulnerability table and select CycloneDX VDR (JSON or XML format). The resulting CycloneDX document includes vulnerability identifiers, severity ratings, affected packages with PURLs, and any available fix information.

Enforce Gates Policy Support for One-Time Scans

Anchore One-Time Scans now support eight additional policy gates beyond vulnerability checks, enabling comprehensive compliance evaluation directly in CI/CD pipelines without persistent SBOM storage. The newly supported gates include:

• Distro
• Dockerfile
• Files
• Image Metadata
• Licenses
• Packages
• Password File
• Retrieved Files

This expansion allows teams to enforce compliance requirements—NIST SSDF, CIS Benchmarks, FedRAMP controls—at build time through the API. Evaluate Dockerfile security practices, verify license compliance, check for exposed credentials, and validate package integrity before artifacts reach registries.

STIG profiles delivered via Anchore Data Service

STIG profiles are now delivered through Anchore Data Service, replacing the previous feed service architecture. DoD customers receive DISA STIG updates with the same enterprise-grade reliability as other vulnerability data, supporting both static container image evaluations and runtime Kubernetes assessments required for continuous ATO processes.

The combination means organizations can implement policy-as-code for both commercial compliance frameworks and DoD-specific requirements through a single, streamlined scanning workflow.

Get Started with 5.23

Existing Anchore Enterprise Customers:

• Contact your account manager to upgrade to Anchore Enterprise 5.23
• Review implementation documentation for CycloneDX VEX/VDR configuration
• Reach out to your Customer Success for guidance on annotation workflows

The EU’s Cyber Resilience Act (CRA) is fundamentally changing how we buy and build software. This isn’t just another regulation; it’s re-shaping the market landscape. We sat down with industry experts Andrew Katz (CEO, Orcro Limited & Head of Open Source, Bristows LLP), Leon Schwarz (Principal, GTC Law Group), and Josh Bressers (VP of Security, Anchore) to discuss how to best take advantage of and prepare for this coming change .

The key takeaway? You can either continue to view compliance as a “regulatory burden” or invert the narrative and frame it as a “competitive differentiator.” The panel revealed that market pressure is already outpacing regulation, and a verifiable, automated compliance process is the new standard for winning deals and proving your company’s value.

The “Compliance Cascade” is Coming

Long before a regulator knocks on your door, your biggest customer will. The new wave of regulations creates a shared responsibility that cascades down the entire supply chain.

As Leon Schwarz explained, “If you sell enough software… you’re going to find that your customers are going to start asking the same questions that all of these regulations are asking”. Andrew Katz noted that this responsibility is recursive: “[Your] responsibility will actually be for all components at all levels of the stack. You know, it doesn’t matter which turtle you’re sitting on” .

The panel made it clear: the “compliance cascade” is about to begin. Once one major enterprise in your supply chain takes the EU CRA seriously, they will contractually force that requirement onto every supplier they have. This is a fundamentally different pressure than traditional, internal audits.

EU CRA Compliance as Market Differentiator

During the discussion, Leon Schwarz described the real-world pressure this compliance cascade creates for suppliers. His “big fear is that during diligence, somebody’s going to come in and say, ‘You didn’t do the reasonable thing here. You didn’t do what everybody else is doing'”.

That fear is the sound of the market setting a new baseline. As the “compliance cascade” forces responsibility down the supply chain, “doing what everyone else is doing” becomes the new definition for what is “reasonable” compliance expectations during procurement. Any supplier who isn’t falling in line becomes the odd one out—a high-risk partner. You will be disqualified from contracts before you even get a chance to demonstrate your value.

But this creates a fundamental, short-term opportunity.

In the beginning, many vendors and suppliers won’t be compliant. Proactive, EU CRA-ready suppliers will be the exception. This is the moment to re-frame the challenge: compliance isn’t a hurdle to be cleared; it’s a competitive differentiator that wins you the deal.

Early adopters will partner with other suppliers who take this change seriously. By having a provable process, they will be the first to adapt to the new compliance landscape, giving them the ability to win business while their competitors are still scrambling to catch up.

A Good Process Increases Your Acquisition Valuation

This new standard of diligence impacts more than just sales; it will materially affect your company’s value during an M&A event.

As Andrew Katz explained, “An organization that’s got a well-run [compliance] process is actually going to be much more valuable; different than an organization where they have to retrofit the process after the transaction has closed”.

An acquirer isn’t just buying your product; they are also buying your access to markets. A company that needs compliance tacked-on has a massive, hidden liability, and the buyer will discount your valuation to compensate for the additional risk.

The Real Goal Isn’t the SBOM; It’s the Evidence

For those new to this, the most critical change is that the new requirement is creating evidence. Just as compliance is shifting from an “annual ritual” to a continuous process, new standards are demanding evidence be collected continuously.

Leon Schwarz summed up the new gold standard for auditors and acquirers: “It’s not enough to have a policy. It’s not enough to have a process. You have to have materials that prove you follow it”. Your process is the “engine” that creates this continuous stream of evidence; an SBOM is just one piece of that evidence. 

As Andrew Katz noted, an SBOM is “just a snapshot” , which is insufficient in a world of “continuous development”. But a process that generates SBOMs for every commit, build or artifact, creates a never ending stream of compliance evidence.

CompOps is How You Automate Trust

This new, continuous demand for proof requires a fundamentally different approach: CompOps (Compliance Operations).

With the EU CRA demanding SBOMs for every release and PCI-DSS 4 requiring scans every three months, compliance must become “part of our development and operations processes” . This is where CompOps, which borrows its “resilient and repeatable” principles from DevOps, becomes essential. It’s not about manual checks; it’s about building automated feedback loops.

Leon described this perfectly: “As developers figure out that if [they] use the things in this bucket of compliant components that their code  is automatically checked in; those are the components they will default to”. That “bucket” is CompOps in action—an automated process that shapes developer behavior with a simple, positive incentive (a green checkmark) and generates auditable proof at the same time.

Are You Building a Speed Bump or a Navigation System?

The experts framed the ultimate choice: you can treat compliance as a “speed bump” that slows developers and creates friction. Or, you can build a “navigible system”.

A good CompOps process acts as that navigation, guiding developers to the path of least resistance that also happens to be the compliant path. This system makes development faster while automatically producing the evidence you need to win deals and prove your value.

This is a fundamentally different way of thinking about compliance, one that moves it from a cost center to a strategic asset.

This was just a fraction of the insights from this expert discussion. The full webinar covers how to handle deep-stack dependencies, specific license scenarios, and how to get buy-in from your leadership.

To learn how to turn compliance from a burden into your biggest competitive advantage, watch the complete on-demand webinar, “The Regulation and Liability of Open Source Software,” today.

Watch Now

RepoFlow was created with a clear goal: to provide a simple package management alternative that just works without the need for teams to manage or maintain it. Many existing solutions required constant setup, tuning, and oversight. RepoFlow focused on removing that overhead entirely, letting organizations run a reliable system that stays out of the way. 

As adoption grew, one request came up often: built-in vulnerability scanning.

When “Nice-to-Have” Became Non-Negotiable

Package management complexity has reached a breaking point. Developers context-switch between npm registries, container repositories, language-specific package systems, and artifact storage platforms. Each ecosystem brings its own interface, authentication model, and workflow patterns. Tomer Cohen founded RepoFlow in 2024 to collapse this fragmentation into a single, intuitive interface where platform teams could manage packages without cognitive overhead.

Early traction validated the approach. Development teams appreciated the consolidation. But procurement conversations kept hitting the same obstacle: “We can’t adopt this without vulnerability scanning.”

This wasn’t a feature request, it was a compliance requirement. Security scanning has become table stakes for developer tooling in 2025, not because it provides competitive differentiation, but because organizations can’t justify purchases without it. The regulatory landscape around software supply chain security, from NIST SSDF to emerging EU Cyber Resilience Act requirements, means security visibility isn’t optional anymore.

But here’s the problem that most tool builders fail to solve: security tools are notorious for adding back the complexity they’re meant to protect against. Slow scans block workflows. Heavy resource consumption degrades performance. Separate interfaces force context switching. Authentication complexity creates friction. For a product whose entire value proposition centered on reducing cognitive load, adding security capabilities meant walking a tightrope. Ship it wrong, and the product’s core promise evaporates.

RepoFlow needed vulnerability scanning that was fundamentally different from traditional security tooling; fast enough not to disrupt workflows, lightweight enough not to burden infrastructure, and integrated enough to avoid context switching.

The Solution: Grype and Syft to the Rescue

RepoFlow’s engineers started from a blank slate. Two options surfaced:

1. Build a custom scanner: maximum control, but months of work and constant feed maintenance.
2. Integrate an open source tool: faster delivery, but only if the tool met strict performance and reliability bars.

They needed something fast, reliable, and light enough to run alongside package operations. Anchore’s Grype checked every box.

Grype runs as a lightweight CLI directly inside RepoFlow. Scans trigger on demand, initiated by developers rather than background daemons. It handles multiple artifact types: containers, npm, Ruby gems, PHP packages, and Rust cargo crates, without consuming extra resources.

Under the hood, results flow through a concise pattern:

1. Generate SBOMs (Software Bills of Materials) with Syft.
2. Scan those SBOMs with Grype for known CVEs (Common Vulnerabilities and Exposures).
3. Parse the JSON output, deduplicate results, and store in RepoFlow’s database.
4. Surface findings in a new Security Scan tab, right beside existing package details.

Parallel execution and caching keep even large-image scans under a minute. The UI remains responsive; users never leave the page.

This looks straightforward, run a scan, show a table but the user experience determines whether developers embrace it or work around it.

The Payoff: Context Without Complexity

Developers now see vulnerabilities in the same pane where they manage packages. No new credentials, no separate dashboards, no waiting for background jobs to finish. Security became part of the workflow rather than a parallel audit.

Adoption followed. Enterprise prospects who had paused evaluations re-engaged. Support tickets dropped. Teams stopped exporting data between tools just to validate package risk.

Anchore’s open-source stack, Syft for SBOMs, Grype for vulnerability scanning, proved that open foundations can deliver enterprise-grade value without enterprise-grade overhead.

Getting Started

For RepoFlow Users

Vulnerability scanning is available in RepoFlow version 0.4.0 and later. The Security Scan tab appears in package detail views for all supported artifact types.

RepoFlow website: repoflow.io

Documentation and configuration guidance: docs.repoflow.io

For Tool Builders Considering Similar Integrations

Anchore’s open source projects provide the foundation RepoFlow leveraged:

• Syft: SBOM generation for containers and packages (github.com/anchore/syft)
• Grype: Vulnerability scanning with CLI and library interfaces (github.com/anchore/grype)

The Anchore OSS community maintains active discussions on integration patterns, configuration approaches, and implementation guidance. Contributing improvements and reporting issues benefits the entire ecosystem; just as RepoFlow’s database update feedback improved the tools for all users.

Anchore Enterprise 5.22 introduces three capabilities designed to make vulnerability management clearer, cleaner, and more trustworthy: 

• VEX annotations with OpenVEX export
• PURLs by default, and
• RHEL Extended Update Support (EUS) indicators.

Each of these features adds context and precision to vulnerability data—helping teams reduce noise, speed triage, and strengthen communication across the supply chain.

Security teams are flooded with vulnerability alerts that lack actionable context. A single CVE may appear in thousands of scans—even if it’s already fixed, mitigated, or irrelevant to the deployed package. The emerging VEX (Vulnerability Exploitability eXchange) standards aim to fix that by allowing publishers to communicate the status of vulnerabilities alongside scan data.

Anchore Enterprise 5.22 builds on this movement with better data hygiene and interoperability: improving how vulnerabilities are described (via annotations), identified (via PURLs), and evaluated (via RHEL EUS awareness).

VEX Annotations and OpenVEX Support

Anchore Enterprise users can now add annotations to individual vulnerabilities on an image—via either the API or the UI—to record their status with additional context. These annotated findings can be exported as an OpenVEX document, enabling teams to share accurate vulnerability states with downstream consumers.

When customers scan your software using their own tools, they may flag vulnerabilities that your team already understands or has mitigated. Annotations let publishers include authoritative explanations—such as “not applicable,” “patched in internal branch,” or “mitigated via configuration.” Exporting this context in OpenVEX, a widely recognized standard, prevents repetitive triage cycles and improves trust across the supply chain.

(CycloneDX VEX support is coming next, ensuring full compatibility with both major standards.)

The annotation workflow supports multiple status indicators that align with VEX standards, allowing teams to document whether vulnerabilities are:

• Not applicable to the specific deployment context
• Mitigated through compensating controls
• Under investigation for remediation
• Scheduled for fixes in upcoming releases

Once annotations are applied to an image, users can download the complete vulnerability list with all contextual annotations in OpenVEX format—a standardized, machine-readable structure that security tools can consume automatically. Read the docs →

PURLs by Default

All Anchore Enterprise APIs now return Package URLs (PURLs) by default for software components where one exists. A PURL provides a canonical, standardized identity for a package—combining its ecosystem, name, and version into a single unambiguous reference.

The PURL format follows the specification:

pkg:ecosystem/namespace/name@version (e.g., pkg:npm/[email protected])

Unlike older CPE identifiers, PURLs precisely map vulnerabilities to the correct package—even when names or versions overlap across ecosystems. This precision improves downstream workflows such as VEX annotations, ensuring that vulnerability status is attached only to the intended software component, not an entire family of similarly named packages. This leads to more reliable matching, fewer false correlations, and a cleaner chain of evidence in SBOM and VEX exchanges.

For packages without ecosystem-specific PURLs, Anchore Enterprise continues to provide alternative identifiers while working toward comprehensive PURL coverage.

PURLs + VEX Workflows

PURLs significantly improve the precision of VEX annotations. When documenting that a vulnerability is not applicable or has been mitigated, the PURL ensures the annotation applies to exactly the intended package—not a range of similarly-named packages across different ecosystems.

This precision prevents misapplication of vulnerability status when:

• Multiple ecosystems contain packages with identical names
• Different versions exist across a software portfolio
• Vulnerability annotations need to be narrowly scoped
• Automated tools process VEX documents

For organizations distributing software to customers with their own security scanning tools, PURLs provide the unambiguous identifiers necessary for reliable vulnerability communication.

RHEL EUS Indicators

Anchore Enterprise now detects and flags RHEL Extended Update Support (EUS) content in container images, applying the correct EUS vulnerability data automatically.

RHEL EUS subscribers receive backported fixes for longer lifecycles than standard RHEL releases. Without this visibility, scanners can misclassify vulnerabilities—either missing patches or reporting false positives. The new EUS indicators verify that vulnerability assessments are based on the right lifecycle data, ensuring consistent and accurate reporting.

If an image is based on an EUS branch (e.g., RHEL 8.8 EUS), Anchore now displays that context directly in the vulnerability report, confirming that all findings use EUS-aware data feeds.

How to Get Started

1. Upgrade to Anchore Enterprise 5.22. Release notes →
2. Add annotations: via UI (Vulnerability tab → Annotate) or API (/vulnerabilities/annotations).
3. Export OpenVEX: from the Vulnerability Report interface or CLI to share with partners.
4. Check EUS status: in the Vulnerability Report summary—look for “EUS Detected.”
5. Integrate PURLs: via API or SBOM exports for precise package mapping.

Ready to Upgrade?

Anchore Enterprise 5.22 delivers the vulnerability communication and software identification capabilities that modern software distribution requires. The combination of OpenVEX support, PURL integration, and RHEL EUS detection enables teams to manage vulnerability workflows with precision while reducing noise in security communications.

Existing customers: Contact your account manager to upgrade to Anchore Enterprise 5.22 and begin leveraging OpenVEX annotations, PURL identifiers, and EUS detection.

Technical guidance: Visit our documentation site for detailed configuration and implementation instructions.

New to Anchore? Request a demo to see these features in action.

Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain.

Download Now

We’re excited to share a new case study highlighting how Sabel Systems transformed their security review process while scaling their Code Foundry platform to support Department of Defense (DoD) missions.

Sabel Systems provides managed DevSecOps pipeline-as-a-service for DoD contractors developing mission-critical vehicle systems. With a lean team of 10 supporting over 100 developers across hundreds of applications, they faced a critical challenge: their manual vulnerability review process couldn’t keep pace with growth.

⏱️ Can’t wait till the end?
📥 Download the case study now 👇👇👇

Download Now

The Challenge: Security Reviews That Couldn’t Scale

When you’re providing platform-as-a-service for DoD vehicle systems, security isn’t optional—it’s mission-critical. But Sabel Systems was facing a bottleneck that threatened their ability to serve their growing customer base.

Their security team spent 1-2 weeks manually reviewing vulnerabilities for each new build of Code Foundry. As Robert McKay, Digital Solutions Architect at Sabel Systems, explains: “We’d have to first build the actual software on the image and then go through all the different connection points and dependencies.”

This wasn’t just slow—it was unsustainable. Code Foundry serves Army, Air Force, and Navy contractors who need to achieve Authority to Operate (ATO) for their systems. These customers operate in IL5 (controlled unclassified) environments on NIPR networks, with strict requirements for zero critical vulnerabilities. The manual process meant delayed deliveries and limited capacity for growth.

Adding to the complexity, Code Foundry is designed to be cloud-agnostic and CI/CD-agnostic, deploying across different DoD-approved cloud providers and integrating with various version control systems (GitLab, Bitbucket, GitHub) and CI/CD tools (GitLab CI, Jenkins). Any security solution would need to work seamlessly across this diverse technical landscape—all while running in air-gapped, government-controlled environments.

The Solution: Automated Security at DoD Scale

Sabel Systems selected Anchore Enterprise to automate their vulnerability management without compromising their strict security standards. The results speak for themselves: vulnerability review time dropped from 1-2 weeks to just 3 days—a 75% reduction that enabled the same 10-person team to support exponentially more applications.

Here’s what made the difference:

Automated scanning integrated directly into CI/CD pipelines. Anchore Enterprise scans every container image immediately after build, providing instant feedback on security posture. Rather than security reviews becoming a bottleneck, they now happen seamlessly in the background while developers continue working.

On-premises deployment built for DoD requirements. Anchore Enterprise runs entirely within government-approved infrastructure, meeting IL5 compliance requirements. Pre-built policy packs for FedRAMP, NIST, and STIG frameworks enable automated compliance checking—no external connectivity required.

API-first architecture that works anywhere. Deploying via Helm charts into Kubernetes clusters, Anchore Enterprise integrates with whatever CI/CD stack each military branch prefers. Sabel Systems embedded AnchoreCTL directly into their pipeline images, keeping all connections within the cluster without requiring SSH access to running pods.

Perhaps most importantly for DoD work, Anchore Enterprise enables real-time transparency for government auditors. Instead of waiting weeks for static compliance reports, reviewers access live security dashboards showing the current state of all applications.

As Joe Bem, Senior Manager at Sabel Systems, notes: “The idea is that you can replace your static contract deliverables with dynamic ones—doing review meetings based on live data instead of ‘here’s my written report that took me a week to write up on what we found last week,’ and by the time the government gets it, it’s now 2-3 weeks old.”

Results: Security That Enables Growth

The implementation of Anchore Enterprise transformed how Code Foundry operates:

• 75% faster vulnerability reviews allowed the security team to scale without adding headcount
• Zero critical vulnerabilities maintained across 100+ applications in multiple IL5 environments
• Real-time audit transparency replaced weeks-old static reports with live compliance dashboards
• Faster ATO processes for DoD contractors through proactive security feedback

This isn’t just about efficiency—it’s about enabling Sabel Systems to serve more DoD missions without compromising security standards. Rather than security reviews constraining business growth, they now happen seamlessly as part of the development workflow.

Learn More

The full case study dives deeper into the technical architecture, specific compliance requirements, and implementation details that enabled these results. Whether you’re supporting defense contractors, operating in regulated environments, or simply looking to scale your security operations, Sabel Systems’ experience offers valuable insights.

Download the complete Sabel Systems case study to see how automated vulnerability management can transform your security posture while enabling growth.

Questions about implementing Anchore Enterprise in your environment? Get in touch with our team—we’re here to help.

Learn how to harden your containers and make them “STIG-Ready” with our definitive guide.

Download Now

We’re excited to announce that Anchore Enterprise is now SDPX 3 ready. If you’re a native to the world of SBOMs this may feel a bit confusing given that the Linux Foundation announced the release of SPDX 3 last year. While this is true, it is also true that the software ecosystem is still awaiting reference implementations which is blocking the SBOM tools community from rolling out the new format. Regardless of this dynamic situation, Anchore is hearing demand from existing customers to stay at the cutting edge of the evolution of SBOMs. To that end, Anchore Enterprise now includes initial support for SPDX 3. These forward looking enterprises are seeking to future-proof their software development process and begin building a fine-grained historical record of their software supply chain while the software ecosystem matures.

Organizations can now upload, store, and download SPDX 3 formatted SBOMs. SBOM formats are in transition from traditional software-oriented standards to future service-oriented and AI-native formats that can capture AI infused, distributed system complexities. In this blog, we’ll walk you through how to navigate this transition, why it’s important to begin now and how Anchore Enterprise is enabling organizations to accomplish this.

The Dual-Track Future of SBOM Standards

Organizations today rely predominantly on two established SBOM standards: SPDX and CycloneDX. Many organizations mix-and-match these formats to address different aspects of modern security and risk management requirements, from increasing transparency into software component supply chains and managing third-party dependency vulnerabilities to enforcing regulatory compliance controls and software license management.

These traditional software-oriented formats continue to deliver significant enterprise value and remain essential for current operational needs. However, the software ecosystem is evolving toward distributed systems and AI-native applications that require a corresponding transformation of SBOM capabilities.

SPDX 3 represents this next generation, designed to capture complex interdependencies in modern distributed architectures that interweave AI features. Since the ecosystem is still awaiting an official reference implementation for SPDX 3 early adopters are experiencing significant turbulence.

For now, organizations need a dual-track approach: maintaining proven standards like SPDX 2.3 and CycloneDX for immediate vulnerability and license scanning needs while beginning to collect SPDX 3 documents in preparation for the ecosystem’s maturation. This parallel strategy ensures operational continuity while positioning organizations for the advanced capabilities that next-generation formats will enable.

The Value of Starting Your SPDX 3 Collection Today

While SPDX 3 processing capabilities are still maturing across the ecosystem, there’s compelling value in beginning collection today. Just as Anchore customers benefit from comprehensive SBOM historical records during zero-day vulnerability investigations, starting your SPDX 3 collection today creates an auditable trail that will power future service-oriented and AI specific use cases as they emerge.

The development lifecycle generates valuable state information at every stage—information that becomes irreplaceable during incident response and compliance audits. By collecting SPDX 3 SBOMs now, organizations ensure they have the historical context needed to leverage new capabilities as the ecosystem matures, rather than starting from zero when scalable SPDX 3 SBOM processing becomes available.

Anchore Enterprise, SPDX 3 Ready: Upgrade Now

As of version 5.20, Anchore Enterprise provides SPDX 3 document storage. This positions organizations for a seamless transition as the ecosystem matures. Users can upload, store, and retrieve valid SPDX 3 SBOMs through existing interfaces while maintaining operational workflows with battle-tested standards.

Organizations can now easily implement the dual-track approach that will allow them to have their SBOM cake and eat it too. The latest releases of Anchore Enterprise deliver the foundational capabilities organizations need to stay ahead of evolving supply chain security requirements. The combination of SPDX 3 support and enhanced SBOM management positions teams for success as software architectures continue to evolve toward distributed, AI-native systems.

Ready to upgrade?

• Existing customers should reach out to their account manager to access the latest version of Anchore Enterprise and begin storing SPDX 3 SBOMs

New to Anchore? Request a guided demo to see this new feature in action

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

When Log4Shell hit, one Anchore Enterprise customer faced the same nightmare scenario as thousands of organizations worldwide: Where is log4j hiding in our infrastructure?

The difference? While most organizations spent weeks manually hunting through systems, this customer ran a single API command and identified every instance of log4j across their entire environment in five minutes.

That’s the transformation Josh Bressers (VP of Security, Anchore) and Brian Thomason (Solutions Engineering Manager, Anchore) demonstrated in their recent webinar on rapid incident response to zero-day vulnerabilities—and it represents a fundamental shift in how security teams can respond to critical threats.

TL;DR: Traditional vulnerability management treats SBOMs as compliance artifacts, but modern incident response requires treating them as operational intelligence.

This technical deep-dive covers three critical scenarios that every security team will face:

• Proactive Threat Hunting: How to identify vulnerable components before CVE disclosure using SBOM archaeology
• Runtime Vulnerability Prioritization: Real-time identification of critical vulnerabilities in production Kubernetes environments
• CI/CD Security Blindness: The massive attack surface hiding in build environments that most teams never scan

Ready to see the difference between reactive firefighting and strategic preparation? Keep reading for the technical insights that will change how you approach zero-day response.

The CUPS Case Study: Getting Ahead of Zero-Day Disclosure

In September 2024, security researchers began dropping hints on Twitter about a critical Linux vulnerability affecting systems “by default.” No CVE. No technical details. Just cryptic warnings about a two-week disclosure timeline.

The security community mobilized to solve the puzzle, eventually identifying CUPS as the target. But here’s where most organizations hit a wall: How do you prepare for a vulnerability when you don’t know what systems contain the affected component?

Traditional approaches require manual system audits—a process that scales poorly and often misses transitive dependencies buried deep in container layers. The SBOM-centric approach inverts this narrative.

“One of the examples I like to use is when log4j happened, we have an Anchore enterprise customer that had all of their infrastructure stored inside of Anchore Enterprise as SBOMs. Log4Shell happens and they’re like, holy crap, we need to search for log4Shell. And so we’re like, ah, you can do that here, run this command. And literally in five minutes they knew where every instance of log4j was in all of their environments.“
—Josh Bressers, VP of Security, Anchore

The Technical Implementation

What was the command they used? The webinar demonstrates this live against thousands of stored SBOMs to locate CUPS across an entire infrastructure:

$ curl -u admin:password \
  "https://enterprise.example.com/v1/images/by_package?name=cups" \
  | jq '.results[] | .tag_history[0].tag'

$ curl -u admin:password \
  "https://enterprise.example.com/v1/images/by_package?name=cups" \
  | jq '.results[] | .tag_history[0].tag'

This single command returns every container image containing CUPS, complete with version information, registry details, and deployment metadata. The query executes against historical and current SBOMs, providing comprehensive coverage across the entire software supply chain.

Security teams can begin impact assessment and remediation planning before vulnerability details become public, transforming reactive incident response into proactive threat management.

What Else You’ll Discover

This proactive discovery capability represents just the foundation of a comprehensive demonstration that tackles the blind spots plaguing modern security operations.

Runtime Vulnerability Management: The Infrastructure You Don’t Control

Josh revealed a critical oversight in most security programs; vulnerabilities in Kubernetes infrastructure components that application teams never see.

The demonstration focused on a critical CVE in the nginx ingress controller—infrastructure deployed by SRE teams but invisible to application security scans. Using Anchore Enterprise’s Kubernetes runtime capabilities, the team showed how to:

• Identify running containers with critical vulnerabilities in real-time
• Prioritize remediation based on production deployment status
• Bridge the visibility gap between application and infrastructure security

“I could have all of my software tracked in Anchore Enterprise and I wouldn’t have any insight into this — because it wasn’t my code. It was someone else’s problem. But it’s still my risk.”
—Josh Bressers, VP of Security, Anchore

CI/CD Archaeology: When the Past Comes Back

The most eye-opening demonstration involved scanning a GitHub Actions runner environment—revealing 13,000 vulnerabilities across thousands of packages in a standard build environment.

The technical process showcased how organizations can:

• Generate comprehensive SBOMs of build environments using filesystem scanning
• Maintain historical records of CI/CD dependencies for incident investigation
• Identify potentially compromised build tools (like the TJ Actions backdoor incident)

“This is literally someone else’s computer building our software, and we might not know what’s in it. That’s why SBOM archaeology matters.”
—Josh Bressers, VP of Security, Anchore

Why SBOMs Are the Strategic Differentiator

Four truths stood out:

• Speed is critical: Minutes, not months, decide outcomes.
• Visibility gaps are real: Runtime and CI/CD are blind spots for most teams.
• History matters: SBOMs are lightweight evidence when past build logs are gone.
• Automation is essential: Manual tracking doesn’t scale to millions of dependencies.

Or as Josh put it:

“Storing images forever is expensive. Storing SBOMs? Easy. They’re just JSON documents—and we’re really good at searching JSON.”

The Bottom Line: Minutes vs. Months

When the next zero-day hits your infrastructure, will you spend five minutes identifying affected systems or five months hunting through manual inventories?

The technical demonstrations in this webinar show exactly how SBOM-driven incident response transforms security operations from reactive firefighting into strategic threat management. This is the difference between organizations that contain breaches and those that make headlines.

Stay ahead of the next disclosure:

1. 👉 Watch the full webinar on-demand
2. Follow Anchore on LinkedIn and X for zero-day analysis and SBOM best practices.
3. Subscribe to our newsletter for exclusive insights into supply chain security, automation, and compliance.

Zero-day vulnerabilities aren’t slowing down. But with SBOM-driven response, your timeline doesn’t have to be measured in months.

Learn how SBOMs enable organizations to react to zero-day disclosures in minutes rather than days or weeks.

Watch Now

Powered by Anchore’s Syft & Grype, IBM’s Platform Development Environment Factory delivers DevSecOps-as-a-Service for federal agencies seeking operational readiness without the integration nightmare.

Federal agencies are navigating a complex landscape: while DevOps has delivered on its promise of increased velocity, modern compliance frameworks like EO 14028 and continuous Authority to Operate (cATO) requirements introduce new challenges that demand sophisticated DevSecOps practices across civilian agencies and the Defense Industrial Base (DIB). For many teams, maintaining both speed and compliance requires careful orchestration of security tools, visibility platforms, and audit processes that can impact development resources.

The challenge often lies in implementation complexity. Software development platforms built from disparate components that should integrate seamlessly often require significant customization work. Teams can find themselves spending valuable time on integration tasks—configuring YAML files, writing connectivity code, and troubleshooting compatibility issues—rather than focusing on mission-critical capabilities. Building and managing a standards-compliant DevSecOps platform requires specialized expertise to deliver the reliability that developers need, while compliance audit processes add operational overhead that can slow time to production.

Net effect: Projects stall in glue-code purgatory long before a single security control is satisfied.

IBM Federal’s PDE Factory changes this equation entirely. This isn’t another pick-your-own-modules starter repository—it’s a fully composed DevSecOps platform you can deploy in hours, not months, with SBOM-powered supply chain security baked into every layer.

Challenge: Tool Sprawl Meets Compliance Deadlines

An application stack destined for federal deployment might need a vulnerability scanner, SBOM generator, signing service, policy engine, and runtime monitoring—each potentially from different vendors. Development teams burn entire sprints wiring these modules together, patching configuration files, and writing custom integration code to resolve subtle interoperability issues that surface during testing.

Every integration introduces fresh risk. Versions drift between environments. APIs break without warning. Documentation assumes knowledge that exists nowhere in your organization. Meanwhile, compliance frameworks like NIST’s Secure Software Development Framework (SSDF) demand comprehensive coverage across software bill of materials (SBOM) generation, continuous vulnerability management, and policy enforcement. Miss one pillar, and the entire compliance review fails.

The US Air Force Platform One learned the lessons above early. Their container ecosystem, now secured with Anchore Enterprise, required extensive tooling integration to achieve the operational readiness standards demanded by mission-critical workloads. Similarly, Iron Bank—the DoD’s hardened container repository—relies on Anchore Enterprise to maintain the security posture that defense contractors and military units depend on for operational continuity.

Solution: A Pre-Wired Factory, No Yak-Shaving Required

IBM Federal’s PDE Factory eliminates the integration nightmare by delivering a fully composed DevSecOps platform deployable in hours rather than months. This isn’t about faster setup—it’s about operational readiness from day one.

Architecture at a glance:

• GitLab CI orchestrates every build with security gates enforced at each stage
• Harbor registry stores signed container images with embedded SBOMs
• Argo CD drives GitOps-based deployments into production Kubernetes clusters
• Terraform automation executes the entire stack deployment with enterprise-grade reliability
• Syft & Grype by Anchore: comes integrated with the PDE Factory giving users SBOM-powered vulnerability scanning “out of the box”

Outcome: A production-ready DevSecOps environment that supports the code-to-cloud kill chain federal agencies need, deployable in hours instead of the weeks-to-months typical of greenfield builds.

Anchore Inside: The SBOM Backbone

Before any container image reaches your registry, Anchore’s battle-tested supply chain tools attach comprehensive security and compliance metadata that travels through your entire deployment pipeline.

How the integration works:

1. Syft performs deep software composition analysis, cataloging every component down to transitive dependencies and generating standards-compliant SBOMs
2. Grype ingests those SBOMs and enriches them with current vulnerability data from multiple threat intelligence feeds
3. Policy enforcement blocks non-compliant builds before they can compromise downstream systems
4. Evidence collection happens automatically—when auditors arrive, you hand them signed JSON artifacts instead of manually compiled documentation

SBOM = portable mission truth. Because SBOMs are machine-readable and cryptographically signed, PDE Factory can automate both rapid “shift-left” feedback loops and comprehensive audit trail generation. This aligns directly with CISA’s Secure by Design initiative—preventing insecure builds from entering the pipeline rather than detecting problems after deployment.

The US Navy’s Black Pearl Factory exemplifies this approach in action. Working with Sigma Defense, they reduced audit preparation time from three days of manual evidence gathering to two minutes of automated report generation—a force multiplier that redirects valuable engineering resources from compliance overhead back to mission delivery.

Day-in-the-Life: From Commit to Compliant Deploy

Here’s how operational readiness looks in practice:

1. Developer commits code to GitLab, triggering the automated security pipeline
2. Container build includes Syft SBOM generation and cryptographic signing
3. Grype vulnerability scanning correlates SBOM components against current threat data
4. Policy gates enforce NIST SSDF requirements before allowing registry promotion
5. Argo CD deployment validates runtime security posture against DoD standards
6. Kubernetes admission controller performs final compliance verification using stored SBOM and vulnerability data

Result: A hardened deployment pipeline that maintains operational readiness without sacrificing development velocity.

For agencies requiring enhanced security posture, upgrading to Anchore Enterprise unlocks Compliance-as-a-Service capabilities:

Operational Payoff: Mission Metrics That Matter

This isn’t just about developer productivity—it’s about mission continuity. When federal agencies can deploy secure software faster and maintain compliance posture without operational overhead, they can focus resources on capabilities that directly serve citizens and national security objectives.

Your Operational Readiness Path Forward

Federal agencies have an opportunity to streamline their development processes by adopting proven infrastructure that the DoD already trusts.

IBM Federal’s PDE Factory, powered by Anchore’s SBOM-first approach, delivers the operational readiness federal agencies need while reducing the integration complexity that often challenges DevSecOps initiatives. Start with the open source foundation—Syft and Grype provide immediate value. Scale to Anchore Enterprise when you need Compliance-as-a-Service capabilities that accelerate your Authority to Operate timeline.

Ready to see proven DoD software factory security in action?

Anchore brings deep expertise in securing mission-critical software factories across the Department of Defense, from Platform One to Iron Bank to the Navy’s Black Pearl Factory. Our battle-tested SBOM-powered approach has enabled DoD organizations to achieve operational readiness while maintaining the security standards required for defense environments.

Book an Anchore Enterprise demo to see how our proven software supply chain security integrates with IBM’s PDE Factory to deliver “no SBOM, no deploy” enforcement without compromising development velocity.

Fortify your pipeline. Harden your releases. Accelerate your operational readiness.

The mission demands secure software. Your developers deserve tools that deliver it.

Learn how to harden your containers and make them “STIG-Ready” with our definitive guide.

Download Now

An exclusive look at insights from the ITGRC Forum’s latest webinar on demonstrating the value of cybersecurity investments.

Three cybersecurity veterans with a combined 80+ years of experience recently gathered for a Forum webinar that challenged everything we thought we knew about the funding of enterprise security investments. 

• Colin Whitaker (30+ years, Informed Risk Decisions), 
• Paulo Amarol (Senior Director GRC, Diligent), 
• Dirk Shrader (25+ years, Netwrix), and 
• Josh Bressers (VP Security, Anchore) delivered insights that explain why some organizations effortlessly secure millions for security initiatives while others struggle for basic tool budgets.

The central revelation? Compliance isn’t just regulatory burden—it’s become the primary pathway for security investment in modern enterprises.

The 75-minute discussion covered critical territory for any security or GRC professional trying to demonstrate value to leadership:

• When Compliance Became the Gateway to Security Investment: How regulatory requirements transformed from cost centers to business enablers
• The Software Supply Chain Compliance Revolution: Why SBOM mandates are forcing visibility that security teams have wanted for decades
• Death by a Thousand Cuts: The Hidden Costs of Fragmented Compliance: The true operational impact of manual compliance processes
• The Future of Compliance-Driven Security Investment: Where emerging regulations are heading and how to get ahead

Not ready to commit to a full webinar? Keep reading to get a taste for the discussion and how it will change your perspective on the relationship between cybersecurity and regulatory compliance.

⏱️ Can’t wait till the end?
📥 Watch the full webinar now 👇👇👇

Watch Now

When Compliance Became the Gateway to Security Investment

For decades, security professionals have faced an uphill battle for executive attention and funding. While IT budgets grew and development teams expanded, security often fought for scraps—forced to justify theoretical risks against concrete revenue opportunities.

Traditional security arguments relied on preventing abstract future threats. Leadership heard endless presentations about potential breaches, theoretical vulnerabilities, and statistical possibilities.

When the business is deciding between allocating resources toward revenue-generating features that will generate an ROI in months versus product security features that will reduce—BUT never eliminate—the possibility of a breach; it’s not difficult to figure out how we got into this situation. Meanwhile, regulatory compliance offered something security never could: immediate business necessity.

Modern compliance frameworks (e.g., EU CRA, DORA, NIS2) invert this narrative by making penalties certain, quantifiable, and time-sensitive. Annual non-compliance penalties and the threat of losing access to sell into European markets shift the story from “possible future breach” to “definite revenue loss.”

“I think now that there’s regulators saying you have to do this stuff or you can’t sell your product here now we have business incentive right because just from a purely practical perspective if a business can’t sell into one of the largest markets on the planet that has enormous consequences for the business.”
—Josh Bressers, VP of Security, Anchore

Not only does modern regulatory compliance create the “financial teeth” needed to align business incentives but it has also evolved the security requirements to be at parity with current DevSecOps best practices. The days of laughable security controls and checkbox compliance are past. Modern laws are now delivering on the promise of “Trust, but verify.”

The Strategic Partnership Opportunity

These two fundamental changes—business-aligned incentives and technically sound requirements—create an unprecedented opportunity for security and compliance teams to partner in reducing organizational risk. Rather than working in silos with competing priorities, both functions can now pursue shared objectives that directly support business goals.

Security teams gain access to executive attention and budget allocation through compliance mandates. Compliance teams benefit from security expertise and automation capabilities that reduce manual audit overhead. Together, they can implement comprehensive risk management programs that satisfy regulatory requirements while building genuine security capabilities.

The result transforms both functions from cost centers into strategic business enablers—compliance ensures market access while security protects the operations that generate revenue.

“However when security and compliance work together now security has a story they can start to tell that gets you the funding you need that get you the support you need from your leadership.”
—Josh Bressers, VP of Security, Anchore

What Else You’ll Discover in the Full Webinar

This transformation in security funding represents just one thread in a comprehensive discussion that tackles the most pressing challenges facing security and GRC professionals today.

The Software Supply Chain Compliance Revolution

Josh Bressers reveals why organizations with proper SBOM capabilities identified Log4j vulnerabilities in 10 minutes while others needed 3 months—and how compliance mandates are finally forcing the software supply chain visibility security teams have wanted for decades.

“Between 70-90% of all code is open source [and] … 95% of products have open source inside of them. The numbers are just absolutely staggering.”
—Josh Bressers, VP of Security, Anchore

Death by a Thousand Cuts: The Hidden Costs of Fragmented Compliance

Dirk Shrader breaks down the operational disruption costs that 54% of organizations recognize but haven’t calculated, including the “mangled effort” of manual compliance processes that diverts skilled staff from strategic initiatives.

“Security and IT teams spend excessive time pulling data from disparate systems: correlating activities, generating audit reports … chasing that individual rabbit.”
—Dirk Shrader, Global VP Security Research, Netwrix

The Future of Compliance-Driven Security Investment

Paulo Amarol demonstrates how GRC platforms are evolving from “evidence lockers” into strategic business intelligence systems that translate technical security data into executive-ready risk assessments.

“We’re able to slice and combine data from various sources—apps, operational security tooling, awareness training, even identity provider data—in ways that our leaders can bring this risk data into their decision-making. You can really automate the process of bringing data in, normalizing it, and mapping it to bigger picture strategic risks.”
—Paulo Amarol, Senior Director GRC, Diligent Corporation

The panelists also explore:

• Poll insights revealing where most organizations stand on compliance cost calculations
• Regulatory proliferation across global markets and how to find common ground
• Automation imperatives for continuous compliance monitoring
• Cultural transformation as security and GRC functions converge
• Implementation strategies for aligning security programs with business objectives

Ready to Transform Your Security Investment Strategy?

This isn’t another theoretical discussion about security ROI. It’s a practical guide from practitioners who’ve solved the funding challenge by repositioning security as a compliance-driven business enabler.

Watch the full ITGRC Forum webinar on-demand to access all 75 minutes of expert insights, poll results, and audience Q&A.

Stay ahead of the compliance-security convergence: Follow Anchore on LinkedIn and Bluesky for ongoing analysis of emerging regulations, industry trends, and practical implementation guidance from software supply chain security experts.

Subscribe to our newsletter for exclusive insights on SBOM requirements, compliance automation, and the strategic intersection of security and regulatory requirements.

The convergence of security and compliance isn’t just happening—it’s accelerating. Don’t get left behind.

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

Just as the open source software revolution fundamentally transformed software development in the 2000s—bringing massive productivity gains alongside unprecedented supply chain complexity—we’re witnessing history repeat itself with Large Language Models (LLMs). The same pattern that caused organizations to lose visibility into their software dependencies is now playing out with LLMs, creating an entirely new category of supply chain risk.

Not to worry though, The Linux Foundation has been preparing for this eventuality. SPDX 3.0 provides the foundational metadata standard needed to extend proven DevSecOps practices to applications that integrate LLMs. 

By introducing AI and Dataset Profiles, it enables organizations to apply the same supply chain security practices that have proven effective for software dependencies to the emerging world of AI supply chains. History may be repeating itself but this time, we have the opportunity to get ahead of it.

LLMs Create New Supply Chain Vulnerabilities That Traditional Security Tools Can’t Grok

The integration of LLMs into software applications has fundamentally altered the threat landscape. Unlike traditional software vulnerabilities that exploit code weaknesses, LLM-era attacks target the unique characteristics of AI systems: 

• their training data is both data and code, and
• their behavior (i.e., both data and code) can be manipulated by users.

This represents a paradigm shift that requires security teams to think beyond traditional application security.

LLMs merge data and code + a second supply chain to secure

LLMs are fundamentally different from traditional software components. Where conventional code follows deterministic logic paths. LLMs operate on statistical patterns learned from “training” on datasets. This fundamental difference creates a new category of “code” that needs to be secured—not just the model weights and architecture, but the training data, fine-tuning datasets, and even the prompts that guide model behavior.

When organizations integrate LLMs into their applications, they’re not just adding another software dependency. They’re creating an entire second supply chain—the LLM data supply chain—that operates alongside their traditional software supply chain. 

The challenge is that this new supply chain operates with fundamentally different risk patterns. Where software vulnerabilities are typically discrete and patchable, AI risks can be subtle, emergent, and difficult to detect. 

• A single compromised dataset can introduce bias that affects all downstream applications. 
• A prompt injection attack can manipulate model behavior without touching any traditional code. 
• Model theft can occur through API interactions that leave no trace in traditional security logs.

Data poisoning and model theft: Novel attack vectors

The emergence of LLMs has introduced attack vectors that simply didn’t exist in traditional software systems, requiring security teams to expand their threat models and defensive strategies.

1. Data Poisoning Attacks represent one of the most intractable new threat categories. Training data manipulation can occur at multiple points in the AI supply chain.
   
   Consider this: what’s stopping a threat actor from modifying a public dataset that’s regularly used to train foundational LLM models? Popular datasets hosted on platforms like Hugging Face or GitHub can be edited by contributors, and if these poisoned datasets are used in model training, the resulting models inherit the malicious behavior.
   
   RAG poisoning attacks take this concept further by targeting the retrieval systems that many production LLM applications rely on. Attackers can create SEO-optimized content and embed hidden text with instructions designed to manipulate the model’s behavior.
   
   When RAG systems retrieve this content as context for user queries, the hidden instructions can override the model’s original alignment, leading to unauthorized actions or information disclosure. Recent research has demonstrated that attackers can inject as few as five poisoned documents into datasets of millions and achieve over 90% success rates in manipulating model outputs.
   
2. Model Theft and Extraction attacks exploit the API-accessible nature of modern LLM deployments. Through carefully crafted queries, attackers can extract valuable intellectual property without ever accessing the underlying model files. API-based extraction attacks involve sending thousands of strategically chosen prompts to a target model and using the responses to train a “shadow model” that replicates much of the original’s functionality.
   
   Self-instruct model replication takes this further by using the target model to generate synthetic training data, effectively teaching a competitor model to mimic the original’s capabilities.

These attacks create new categories of business risk that organizations must consider. Beyond traditional concerns about data breaches or system availability, LLM-integrated applications face risks of intellectual property theft, reputational damage from biased or inappropriate outputs, and regulatory compliance violations in increasingly complex AI governance environments.

Enterprises are losing supply chain visibility as AI-native applications grow

Organizations are mostly unaware of the fact that the data supply chain for LLMs is equally as important to track as their software supply chain. As teams integrate foundation model APIs, deploy RAG systems, and fine-tune models for specific use cases, the complexity of LLM data supply chains is exploding. 

Traditional security tools that excel at scanning software dependencies for known vulnerabilities are blind to LLM-specific risks like bias, data provenance, or model licensing complications.

This growing attack surface extends far beyond what traditional application security can address. When a software component has a vulnerability, it can typically be patched or replaced. When an AI model exhibits bias or has been trained on problematic data, the remediation may require retraining, which can cost millions of dollars and months of time. The stakes are fundamentally different, and the traditional reactive approach to security simply doesn’t scale.

So how do we deal with this fundamental shift in how we secure supply chains?

Next-Gen SBOM Formats Extend Proven Supply Chain Security to AI-Native Applications

The answer is—unsurprisingly—SBOMs. But more specifically, next-generation SBOM formats like SPDX 3.0. While Anchore doesn’t have an official tagline, if we did, there’s a strong chance it would be “you can’t secure your supply chain without knowing what is in it.” SPDX 3.0 has updated the SBOM standard to store AI model and dataset metadata, extending the proven principles of software supply chain security to the world of LLMs.

AI Bill of Materials: machine-readable security metadata for LLMs

SPDX 3.0 introduces AI and Dataset Profiles that create machine-readable metadata for LLM system components. These profiles provide comprehensive tracking of models, datasets, and their relationships, creating what’s essentially an “LLM Bill of Materials” that documents every component in an AI-powered application.

The breakthrough is that SPDX 3.0 increases visibility into AI systems by defining the key AI model metadata—read: security signals—that are needed to track risk and define enterprise-specific security policies. This isn’t just documentation for documentation’s sake; it’s about creating structured data that existing DevSecOps infrastructure can consume and act upon. 

The bonus is that this works with existing tooling: SBOMs, CI/CD pipelines, vulnerability scanners, and policy-as-code evaluation engines can all be extended to handle AI profile metadata without requiring organizations to rebuild their security infrastructure from scratch.

Learn about how SBOMs have adapted to the world of micro-services architecture with the co-founder of SPDX and SBOMs.

Watch Now

3 novel security use-cases for AI-native apps enabled by SPDX 3.0

1. Bias Detection & Policy Enforcement becomes automated through the knownBias field, which allows organizations to scan AI BOMs for enterprise-defined bias policies just like they scan software SBOMs for vulnerable components.
   
   Traditional vulnerability scanners can be enhanced to flag models or datasets that contain documented biases that violate organizational policies. Policy-as-code frameworks can enforce bias thresholds automatically, preventing deployment of AI systems that don’t meet enterprise standards.
   
2. Risk-Based Deployment Gates leverage the safetyRiskAssessment field, which follows EU risk assessment methodology to categorize AI systems as serious, high, medium, or low risk.
   
   This enables automated risk scoring in CI/CD pipelines, where deployment gates can block high-risk models from reaching production or require additional approvals based on risk levels. Organizations can set policy thresholds that align with their risk tolerance and regulatory requirements.
   
3. Data Provenance Validation uses fields like dataCollectionProcess and suppliedBy to track the complete lineage of training data and models. This enables allowlist and blocklist enforcement for data sources, ensuring that models are only trained on approved datasets.
   
   Supply chain integrity verification becomes possible by tracking the complete chain of custody for AI components, from original data collection through model training and deployment.

An SPDX 3.0 SBOM hierarchy for an AI-native application might look like this:

The key insight is that SPDX 3.0 makes AI systems legible to existing DevSecOps infrastructure. Rather than requiring organizations to build parallel security processes for AI workflows and components, it extends current security investments to cover the new AI supply chain. This approach reduces adoption friction by leveraging familiar tooling and processes that security teams already understand and trust.

History Repeats Itself: The Supply Chain Security Story

This isn’t the first time we’ve been through a transition where software development evolution increases productivity while also creating supply chain opacity. The pattern we’re seeing with LLM data supply chains is remarkably similar to what happened with the open source software explosion of the 2000s.

Software supply chains evolution: From trusted vendors to open source complexity to automated security

• Phase 1: The Trusted World (Pre-2000s) was characterized by 1st-party code and trusted commercial vendors. Organizations primarily wrote their own software or purchased it from established vendors with clear support relationships.
  
  Manual security reviews were feasible because dependency trees were small and well-understood. There was high visibility into what components were being used and controlled dependencies that could be thoroughly vetted.
  
• Phase 2: Open Source Software Explosion (2000s-2010s) brought massive productivity gains from open source libraries and frameworks. Package managers like npm, Maven, and PyPI made it trivial to incorporate thousands of 3rd-party components into applications.
  
  Dependency trees exploded from dozens to thousands of components, creating a visibility crisis where organizations could no longer answer the basic question: “What’s actually in my application?”
  
  This led to major security incidents like the Equifax breach (Apache Struts vulnerability), the SolarWinds supply chain attack, and the event-stream npm package compromise that affected millions of applications.
  
• Phase 3: Industry Response (2010s-2020s) emerged as the security industry developed solutions to restore visibility and control.
  
  SBOM standards like SPDX and CycloneDX provided standardized ways to document software components. Software Composition Analysis (SCA) tools proliferated, offering automated scanning and vulnerability detection for open source dependencies. DevSecOps integration and “shift-left” security practices made supply chain security a standard part of the development workflow.

LLM supply chains evolution: Same same—just faster

We’re now seeing this exact pattern repeat with AI systems, just compressed into a much shorter timeframe.

Phase 1: Model Gardens (2020-2023) featured trusted foundation models from established providers like OpenAI, Google, and Anthropic. LLM-powered application architectures were relatively simple, with limited data sources and clear model provenance.

Manual AI safety reviews were feasible because the number of models and data sources was manageable. Organizations could maintain visibility into their AI components through manual processes and documentation.

Phase 2: LLM/RAG Explosion (2023-Present) has brought foundation model APIs that enable massive productivity gains for AI application development.

Complex AI supply chains now feature transitive dependencies where models are fine-tuned on other models, RAG systems pull data from multiple sources, and agent frameworks orchestrate multiple AI components.

We’re currently re-living the same but different visibility crisis where organizations have lost the ability to understand the supply chains that power their production systems. Emerging attacks like data poisoning, and model theft are targeting these complex supply chains with increasing sophistication.

Phase 3: Industry Response (Near Future) is just beginning to emerge. SBOM standards like SPDX 3.0 are leading the charge to re-enable supply chain transparency for LLM supply chains constructed from both code and data. AI-native security tools are starting to appear, and we’re seeing the first extensions of DevSecOps principles to AI systems.

Where do we go from here?

We are still in the early stages of new software supply chain evolution, which creates both risk and opportunity for enterprises. Those who act now can establish LLM data supply chain security practices before the major attacks hit, while those who wait will likely face the same painful lessons that organizations experienced during the software supply chain security crisis of the 2010s.

Crawl: Embed SBOMs into your current DevSecOps pipeline

A vital first step is making sure you have a mature SBOM initiative for your traditional software supply chains. You won’t be ready for the future transition to LLM supply chains without this base.

This market is mature and relatively lightweight to deploy. It will power software supply chain security or up-level current software supply chain security (SSCS) practices. Organizations that have already invested in SBOM tooling and processes will find it much easier to extend these capabilities to an AI-native world.

Walk: Experiment with SPDX 3.0 and system bills of materials

Early adopters who want to over-achieve can take several concrete steps:

1. Upgrade to SPDX 3.0 and begin experimenting with the AI and Dataset Profiles. Even if you’re not ready for full production deployment, understanding the new metadata fields and how they map to your LLM system components will prepare you for the tooling that’s coming.
   
2. Begin testing AI model metadata collection by documenting the models, datasets, and AI components currently in use across your organization. This inventory process will reveal gaps in visibility and help identify which components pose the highest risk.
   
3. Insert AI metadata into SBOMs for applications that already integrate AI components. This creates a unified view of both software and LLM dependencies, enabling security teams to assess risk across the entire application stack.
   
4. Explore trends and patterns to extract insights from your LLM component inventory. Look for patterns in data sources, model licensing, risk levels, and update frequencies that can inform policy development.

This process will eventually evolve into a full production LLM data supply chain security capability that will power AI model security at scale. Organizations that begin this journey now will have significant advantages as AI supply chain attacks become more sophisticated and regulatory requirements continue to expand.

The window of opportunity is open, but it won’t remain that way indefinitely. Just as organizations that ignored software supply chain security in the 2000s paid a heavy price in the 2010s, those who ignore AI supply chain security today will likely face significant challenges as AI attacks mature and regulatory pressure increases.

Follow us on LinkedIn or subscribe to our newsletter to stay up-to-date on progress. We will continue to update as this space evolves, sharing practical guidance and real-world experiences as organizations begin implementing LLM data supply chain security at scale.

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

The latest release of Anchore Enterprise 5.19 features two major enhancements that address critical needs in government, defense, and enterprise environments:

• Anchore STIG for Container Images, and 
• Anchore One-Time Scan. 

Anchore STIG for Container Images automates the process of running a STIG evaluation against a container image to shift compliance “left”. By embedding STIG validation directly into the CI/CD pipeline as automated policy-as-code rules, compliance violations are detected early, reducing the time to reach compliance in production.

Anchore One-Time Scan is a new API which is optimized for scanning in CI/CD by removing the persistence requirement for storing the SBOM. Now security and software engineers can get stateless scanning, comprehensive vulnerability assessment and policy evaluation through a single CLI command or API call.

These new features bring automated compliance validation and flexible scanning options directly into your DevSecOps workflows, enabling organizations to maintain security standards without sacrificing development velocity.

Anchore STIG for Container Images: Compliance Automation at Scale

Before we jump into the technical details, it’s important to understand the compliance challenges that government and defense organizations face daily. Security Technical Implementation Guides (STIGs) represent the gold standard for cybersecurity hardening in federal environments, providing detailed configuration requirements that systems must meet to operate securely. However, traditional STIG compliance has been a largely manual process—time-consuming, error-prone, and difficult to integrate into automated CI/CD pipelines.

What is STIG and Why It Matters

STIGs are cybersecurity best practices developed by the Defense Information Systems Agency (DISA) that focus on proactive system configuration and hardening.

The challenge for modern development teams is that STIG evaluations have traditionally required manual assessment and configuration validation, creating bottlenecks in deployment pipelines and increasing the risk of non-compliant systems reaching production. For organizations pursuing FedRAMP authorization or operating under federal compliance mandates, this manual overhead can significantly slow development cycles while still leaving room for human error.

For a real-world example of how STIG compliance challenges are being solved at scale, check out our Cisco Umbrella case study, which details how Cisco uses Anchore Enterprise with STIG for Container Images on their AWS EC2 base images.

Learn how to harden your containers and make them “STIG-Ready” with our definitive guide.

Download Now

Why Adopt Anchore STIG for Container Images?

Anchore STIG for Container Images delivers immediate value across multiple organizational levels: 

• Development teams gain access to “STIG Ready” base images
• Security teams can access STIG evaluation documents in a single location

The automated approach eliminates the manual audit overhead that traditionally slows compliance workflows, while the policy gate integration prevents images which are not evaluated from reaching production. This proactive compliance model significantly reduces the risk of security violations and streamlines the path to regulatory compliance authorizations such as FedRAMP or DoD ATO.

How Anchore STIG for Container Images Works

Anchore STIG for Container Images automates the entire STIG evaluation process through seamless integration with Cinc (i.e., open source Chef IaC system) and AnchoreCTL orchestration. The solution provides a four-step workflow that transforms manual compliance checking into an automated pipeline component:

1. Install Cinc on your scanning host alongside AnchoreCTL
2. Extract supported STIG profiles

$ anchorectl image stig write-profiles  [--include-experimental]

3. Execute STIG checks using specific profiles through AnchoreCTL commands

$ anchorectl image stig run <FULLY_QUALIFIED_URL_TO_CONTAINER_IMAGE> \
--stig-profile ./<DIRECTORY_PATH_TO_EXTRACTED_STIG_PROFILES>/ubi8/anchore-ubi8-disa-stig-1.0.0.tar.gz

4. Upload results directly to Anchore Enterprise for centralized management and reporting

The add-on supports comprehensive profiles for RHEL 8/9 and Ubuntu 22.04/24.04, with tech preview profiles available for critical applications including: 

• PostgreSQL
• Apache Tomcat
• MongoDB Enterprise
• Java Runtime Environment

New API endpoints provide full programmatic access to STIG evaluations, while the integrated policy gate ensures that only compliant images can progress through your deployment pipeline. The screenshot below shows an example gate that can evaluate whether a STIG evaluation exists for a container and if the age of the evaluation is older than a specified number of days.

Anchore Enterprise One-Time Scan: Lightweight Security for Agile Workflows

Not every security scanning scenario requires persistent data storage in your Anchore Enterprise deployment. Modern DevSecOps teams often need quick vulnerability assessments for third-party images, temporary validation in CI/CD pipelines, or rapid security triage during incident response. Traditional scanning approaches that persist all data can create unnecessary overhead for these ephemeral use-cases.

CI/CD pipeline flexibility is particularly important for organizations operating at scale, where resource optimization and scanning speed directly impact development velocity. Teams need the ability to perform comprehensive security evaluation without the infrastructure overhead of full data persistence, especially when assessing external images or performing one-off security validations.

Why and Where to Utilize the One-Time Scan Feature

One-Time Scan significantly reduces scanning overhead by eliminating the storage and processing requirements associated with persistent image data. This approach is particularly valuable for organizations scanning large numbers of ephemeral workloads or performing frequent one-off assessments.

Primary Use Cases:

• CI/CD Pipeline Validation: Quick security checks for ephemeral build environments
• Third-Party Image Assessment: Evaluate external images without adding them to your inventory
• Incident Response: Rapid vulnerability assessment during security investigations
• Compliance Verification: Policy evaluation for images that don’t require long-term tracking

The stateless operation of One Time Scan provides faster scanning results for time-sensitive workflows, while the new stateless_sbom_evaluation metric enables teams to track usage patterns and optimize their scanning strategies. This flexibility supports diverse operational requirements without compromising security analysis quality.

How One Time Scan Works

Anchore Enterprise’s One Time Scan feature introduces a stateless scanning capability that delivers comprehensive vulnerability assessment and policy evaluation without persisting data in your Anchore Enterprise deployment. The feature provides a single API endpoint (POST /v2/scan) that accepts image references and returns complete security analysis results in real-time.

The stateless operation includes full policy evaluation against your active policy bundles, specifically leveraging Anchore Secure’s gates for vulnerabilities and secret scans. This ensures that even temporary scans benefit from your organization’s established security policies and risk thresholds. 

For CLI-based workflows, the new AnchoreCTL command anchorectl image one-time-scan <image> provides immediate access to stateless scanning capabilities.

$ anchorectl image one-time-scan python:latest --from registry
 ✔ Completed one time scan                                                                                                                             python:latest
Tag: python:latest
Digest: sha256:238379aacf40f83bfec1aa261924a463a91564b85fbbb97c9a96d44dc23bebe7
Policy ID: anchore_secure_default
Last Evaluation: 2025-07-08T14:29:47Z
Evaluation: pass
Final Action: warn
Reason: policy_evaluation

Policy Evaluation Details:
┌─────────────────┬─────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ GATE            │ TRIGGER │ DESCRIPTION                                                                                                                                                                                   │ ACTION │ RECOMMENDATION                                                                                                                                                                   │
├─────────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre-text-3.5.28-2 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367)   │ warn   │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │
│ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre21-3.5.28-2+b1 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367)   │ warn   │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │
│ vulnerabilities │ package │ MEDIUM Vulnerability found in non-os package type (binary) - /usr/local/bin/python3.13 (fixed in: 3.14.0b3)(CVE-2025-6069 - https://nvd.nist.gov/vuln/detail/CVE-2025-6069)                   │ warn   │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │
│ vulnerabilities │ package │ HIGH Vulnerability found in os package type (dpkg) - libdjvulibre-dev-3.5.28-2+b1 (fixed in: 3.5.28-2.1~deb12u1)(CVE-2025-53367 - https://security-tracker.debian.org/tracker/CVE-2025-53367) │ warn   │ Packages with low, medium, and high vulnerabilities present can be upgraded to resolve these findings. If upgrading is not possible the finding should be added to an allowlist. │
└─────────────────┴─────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Upgrade to Anchore Enterprise 5.19

Anchore Enterprise 5.19 represents a significant advancement in container security automation, delivering the compliance capabilities and scanning flexibility that modern organizations require. The combination of automated STIG compliance and stateless scanning options enables teams to maintain rigorous security standards without creating a drag on development velocity.

Whether you’re pursuing FedRAMP authorization, managing compliance requirements in government environments, or simply need more flexible scanning options for your DevSecOps workflows, these new capabilities provide the foundation for scalable, automated container security.

Ready to upgrade?

• Existing customers should reach out to their account manager to access Anchore Enterprise 5.19 and begin leveraging these new capabilities. 
• For technical implementation guidance and detailed configuration instructions, visit our documentation site.
• New to Anchore? Start with our 15-day free trial or request a guided demo to see these features in action.

We are excited to announce two significant milestones that further strengthen our partnership with Amazon Web Services (AWS):

• Anchore has achieved AWS Security Competency in Application Security — SBOM Use-case
• Anchore Enterprise AWS Machine Image (AMI) is now available for streamlined deployment

These announcements represent another major step in Anchore and AWS’s deepening collaboration to help Fortune 2000 enterprises, federal agencies, and defense contractors secure their software supply chains.

AWS Security Competency: SBOM Leadership Validation

The AWS Security Competency validates what Anchore customers have known for many years — Anchore is ready to provide SBOM management, container security and automated compliance enforcement to Fortune 2000 enterprises, federal agencies, and defense contractors who require a bullet-proof software supply chain.

This competency represents technical validation of Anchore’s SBOM-powered security capabilities through a rigorous AWS assessment of our solution architecture and customer success stories. AWS evaluated our platform’s ability to deliver comprehensive software supply chain transparency, vulnerability management, and automated compliance enforcement at enterprise scale.

Real-world validation comes from customers like:

Cisco Umbrella leveraged Anchore’s SBOM-powered container security to accelerate meeting all six FedRAMP requirements. They deployed Anchore into a high-security environment that had to meet stringent compliance standards, including STIG compliance for Amazon EC2 nodes backing their Amazon EKS deployment.

DoD Iron Bank adopted Anchore for SBOM-powered container security and DoD software factory compliance, validating our platform’s ability to meet the most demanding security requirements in government and defense environments.

For decision makers, the AWS Security Competency provides confidence in solution reliability and seamless AWS integration. It streamlines procurement through verified partner status and ensures enhanced support through our strengthened AWS partnership.

Anchore Enterprise Cloud Image: Simplifying Deployment with an AWS AMI

The Anchore Enterprise Cloud Image represents a pre-built, virtual appliance deployment option that serves as an alternative to the popular Kubernetes Helm chart deployments for use-cases that require a lightweight, batteries-included integration. This isn’t about reducing features—it’s about eliminating complexity where Kubernetes expertise isn’t readily available or necessary.

Technical advantages include:

Dramatically reduced deployment complexity through a ready-to-run Amazon Machine Image (AMI) that eliminates the need for a PhD in Kubernetes. The AMI delivers optimized performance on select AWS instance types, with deterministic performance guidelines for better capacity planning and cost management.

Anchore’s interactive Cloud Image Manager provides guided setup that intelligently assesses your AWS environment, ensures correct resource provisioning, and automates installation with appropriate configurations. Integrated compliance policy packs for NIST, SSDF and FedRAMP frameworks ensure your container security posture aligns with regulatory requirements from day one.

Business benefits that matter to leadership:

Faster time-to-value for container security initiatives means your teams can focus on securing containers rather than managing infrastructure. Reduced operational overhead frees up resources for strategic security initiatives rather than deployment troubleshooting.

This prescriptive solution is ideal for teams without extensive Kubernetes expertise, proof-of-concept deployments, and smaller-scale implementations that need enterprise-grade security without enterprise-level complexity.

Strengthening Our AWS Partnership for Customer Success

These milestones build on our growing AWS collaboration, including our AWS Marketplace availability and ISV Accelerate Program membership. This represents our broader commitment to enterprise and public sector customers who rely on AWS infrastructure for their most critical applications.

The joint value proposition is clear: seamless AWS infrastructure integration combined with enhanced support through our combined AWS and Anchore expertise. We’re addressing the full spectrum of deployment preferences, whether you need the scale-out capabilities of EKS or the simplified deployment of our EC2 AMI option.

This partnership strengthening directly benefits our mutual customers through validated integration patterns, streamlined support channels, and deployment flexibility that matches your team’s expertise and requirements.

Moving Forward Together

The combination of AWS Security Competency validation and simplified AMI deployment options demonstrates our commitment to comprehensive support for enterprise and government security requirements. These milestones strengthen our partnership and enable customer success at scale, whether you’re securing containers for a commercial enterprise or meeting compliance requirements for federal agencies.

Our deepening AWS partnership ensures you have the deployment flexibility, validated security capabilities, and enterprise support needed to secure your software supply chain with confidence.

Ready to get started?

• For AMI deployment: Contact our sales team for Cloud Image deployment consultation tailored to your AWS environment
• For general inquiries: Connect with our team to discuss how AWS Security Competency benefits and deployment options can accelerate your software supply chain security initiatives

The next phase of software supply chain security isn’t about better software supply chain inventory management—it’s the realization that distributed, micro-services architecture expands an application’s “supply chain” beyond the walls of isolated, monolithic containers to a dynamic graph of interconnected services working in concert.

Kate Stewart, co-founder of SPDX and one of the most influential voices in software supply chain security, discovered this firsthand while developing SPDX 3.0. Users were importing SBOMs into databases and asking interconnection questions that the legacy format couldn’t answer. Her key insight drove the development of SPDX 3.0: “It’s more than just software now, it really is a system.” The goal became transforming the SBOM format into a graph-native data structure that captures complex interdependencies between constellations of services.

In a recent interview with Anchore’s Director of Developer Relations on the Future of SBOMs, Stewart shared insights, shaped by decades of collaboration in the trenches with SBOM users and the sculpting of SBOM standards based on ground truth needs. Her perspectives are uniquely tailored to illuminate the challenge of adapting traditional security models designed for fully self-contained applications to the world of distributed micro-services architectures.

The architectural evolution from monolithic, containerized application to interconnected constellations of single-purpose services doesn’t just change how software is built—it fundamentally changes what we’re trying to secure.

Learn about how SBOMs have adapted to the world of micro-services architecture with the co-founder of SPDX and SBOMs.

Watch Now

When Software Became Systems

Thing to scan 👇
================

+-------------------------------------------------+
|                    Container                    |
|  +-------------------------------------------+  |
|  |          Monolithic Application           |  |
|  |  +----------+  +---------+  +----------+  |  |
|  |  | Frontend |  | Backend |  | Database |  |  |
|  |  +----------+  +---------+  +----------+  |  |
|  +-------------------------------------------+  |
+-------------------------------------------------+

Thing to scan 👇
================

+-------------------------------------------------+
|                    Container                    |
|  +-------------------------------------------+  |
|  |          Monolithic Application           |  |
|  |  +----------+  +---------+  +----------+  |  |
|  |  | Frontend |  | Backend |  | Database |  |  |
|  |  +----------+  +---------+  +----------+  |  |
|  +-------------------------------------------+  |
+-------------------------------------------------+

       [ User ]
          |
          v
    +------------+
    |  Frontend  |  (container)      👈 Thing...
    +------------+
          |
          v
    +--------------+
    |  API Server  |  (container)    👈 [s]...
    +--------------+
        /    \
       v      v
+----------+ +--------+
| Auth Svc | | Orders | (container)  👈 to...
+----------+ +--------+
       \      /
        v    v
    +------------+
    |  Database  | (container)       👈 scan.
    +------------+

Even with this evolution in software systems, the fundamental question of software supply chain security hasn’t evolved. Security teams still need to know, “what showed up; at what point in time AND do it at scale.” The new challenge is that system complexity has exploded exponentially and the legacy SBOM standards weren’t prepared for it.

Supply chain risk now flows through connections, not just components. Understanding what you’re securing requires mapping relationships, not just cataloging parts.

But if the structure of risk has changed, so has the nature of vulnerabilities themselves.

Where Tomorrow’s Vulnerabilities Will Hide

The next generation of critical vulnerabilities won’t just be in code—they’ll emerge from the connections and interactions between complex webs of software services.

Traditional security models relied on a castle-and-moat approach: scan containers at build time, stamp them for clearance, and trust them within the perimeter. But distributed architectures expose the fundamental flaw in this thinking. When applications are decomposed into atomic services the holistic application context is lost. A low severity vulnerability in one system component that is white listed for the sake of product delivery speed can still be exploited and alter a payload that is benign to the exploited component but disastrous to a downstream component.

The shift to interconnected services demands a zero-trust security paradigm where each interaction between services requires the same level of assurance as initial deployment. Point-in-time container scans can’t account for the dynamic nature of service-to-service communication, configuration changes, or the emergence of new attack vectors through legitimate service interactions.

In order to achieve this new security paradigm, SPDX needed a facelift. The new idea about an SBOM that can store the entire application context across independent services is sometimes called a SaaSBOM. SPDX 3.0 implements this idea via a new concept called profiles, where application profiles can be built from a collection of individual service profiles and operations or infrastructure profiles can also capture data on the build and runtime environments.

Your risk surface isn’t just your code anymore—it’s your entire operational ecosystem from hardware component supplier to data providers to third-party cloud service.

Understanding these expanding risks requires a fundamental shift from periodic snapshots (i.e., castle-and-moat posture) to continuous intelligence (i.e., zero-trust posture).

From Periodic Audits to Continuous Risk Intelligence

The shift to zero-trust architectures requires more than just changing security policies—it demands a fundamental reimagining of how we monitor and verify the safety of interconnected systems in real-time.

Traditional compliance operates on snapshot thinking: quarterly audits, annual assessments, point-in-time inventories. This approach worked when applications were monolithic containers that changed infrequently. But when services communicate continuously across network boundaries, static assessments become obsolete before they’re complete. By the time audit results are available, dozens of deployments, configuration changes, and scaling events have already altered the system’s risk profile.

Kate Stewart’s vision of “continuous compliance” addresses this fundamental mismatch between static assessment and dynamic systems. S—System—BOMs capture dependencies and their relationships in real-time as they evolve, enabling automated policy enforcement that can keep pace with DevOps-speed development. This continuous visibility means teams can verify that each service-to-service interaction maintains the same security assurance as initial deployment, fulfilling the zero-trust requirement.

The operational transformation is profound. Teams can understand blast radius immediately when incidents occur, tracing impact through the actual dependency graph rather than outdated documentation. Compliance verification happens inline with development pipelines rather than as a separate audit burden. Most importantly, security teams can identify and address misconfigurations or policy violations before they create exploitable vulnerabilities.

This evolution transforms security from a periodic checkpoint into continuous strategic intelligence, turning what was once a cost center into a competitive advantage that enables faster, safer innovation.

The Strategic Imperative—Why This Matters Now

Organizations that adapt to system-level visibility will have decisive advantages in risk management, compliance, and operational resilience as the regulatory and competitive landscape evolves.

The visibility problem remains foundational: you can’t secure what you can’t see. Traditional tools provide (system) component visibility, but emergent system risks only emerge through relationship mapping. Kate emphasizes this idea noting that “safety is a system property”. If you want to achieve system-level guarantees of security or risk, being able to see only the trees and not the forest won’t cut it.

Regulatory evolution is driving urgency around this transition. Emerging regulations (e.g., EO 14028, EU CRA, DORA, FedRAMP, etc.) increasingly focus on system-level accountability, making organizations liable for the security of entire systems, including interactions with trusted third-parties. Evidence requirements are evolving from point-in-time documentation to continuously demonstrable evidence, as seen in initiatives like FedRAMP 20x. Audit expectations are moving toward continuous verification rather than periodic assessment.

Competitive differentiation emerges through comprehensive risk visibility that enables faster, safer innovation. Organizations achieve reduced time-to-market through automated compliance verification. Customer trust builds through demonstrable security posture. Operational resilience becomes a competitive moat in markets where system reliability determines business outcomes.

Business continuity integration represents perhaps the most significant strategic opportunity. Security risk management aligns naturally with business continuity planning. System understanding enables scenario planning and resilience testing. Risk intelligence feeds directly into business decision-making. Security transforms from a business inhibitor into an enabler of agility.

This isn’t just about security—it’s about business resilience and agility in an increasingly interconnected world.

The path forward requires both vision and practical implementation.

The Path Forward

The transition from S—software—BOMs to S—system—BOMs represents more than technological evolution—it’s a fundamental shift in how we think about risk management in distributed systems.

Four key insights emerge from this evolution. 

1. Architectural evolution demands corresponding security model evolution—the tools and approaches that worked for monoliths cannot secure distributed systems. 
2. Risk flows through connections, requiring graph-based understanding that captures relationships and dependencies. 
3. Continuous monitoring and compliance must replace periodic audits to match the pace of modern development and deployment. 
4. System-level visibility becomes a competitive advantage for organizations that embrace it early.

Organizations that make this transition now will be positioned for success as distributed architectures become even more complex and regulatory requirements continue to evolve. The alternative—continuing to apply monolithic security thinking to distributed systems—becomes increasingly untenable.

The future of software supply chain security isn’t about better inventory—it’s about intelligent orchestration of system-wide risk management.

If you’re interested in how to make the transition from generating static software SBOMs to dynamic system SBOMs, check out Anchore SBOM or reach out to our team to schedule a demo.

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

Your sales team just got off a call with a major prospect. The customer is asking for an SBOM—a software bill of materials—and they want it written directly into the contract. The request is escalated to the executive team and from there directly into your inbox. Maybe it’s a government agency responding to new federal mandates, a highly regulated enterprise implementing board-level security requirements, or a large EU-based SaaS buyer preparing for upcoming regulatory changes.

Suddenly, a deal that seemed straightforward now hinges on your ability to deliver comprehensive software supply chain transparency. If this scenario sounds familiar, you’re definitely not alone. SBOM requirements are increasing across industries, fueled by new regulations like the US Executive Order 14028 and the EU Cyber Resilience Act. For most software vendors, this represents entirely new territory where the stakes—revenue, reputation, and customer trust—are very real.

This development isn’t entirely negative news, however. Organizations that proactively build robust SBOM capabilities are discovering they’re not just avoiding lost deals—they’re actually building a significant competitive advantage. Early adopters consistently report faster sales cycles with security-conscious prospects and access to previously unreachable government contracts that require supply chain transparency. 

Don’t believe me? I’ve brought the receipts:

We’re seeing a lot of traction with data warehousing use-cases. Security is absolutely critical for these environments. Being able to bring an SBOM to the conversation at the very beginning completely changes the conversation and allows CISOs to say, ‘let’s give this a go’.

—CEO, API Management Vendor

>> Read whole customer case study here >>

This blog post will walk you through the critical steps needed to meet customer SBOM demands effectively, help you avoid costly implementation mistakes, and even show you how to turn compliance requirements into genuine business advantages.

5-Minute Decision Framework: Are SBOMs Urgent for Your Organization?

High urgency signals: Government prospects, enterprise RFPs mentioning SBOMs, existing customers asking software supply chain security questions, competitors promoting SBOM capabilities.

Medium urgency signals: Industry peers discussing SBOM strategies, security questionnaires becoming more detailed, procurement teams asking about vulnerability management.

Preparation signals: Strong CI/CD pipelines, good dependency management, existing security tooling, cross-functional project execution capability.

Red flags: Legacy systems with unknown dependencies, manual build processes, siloed teams, limited engineering bandwidth.

Why Customers Are Demanding SBOMs—And What That Means For You

SBOMs aren’t a passing trend. In fact, the regulatory pressure from governments around the world are steadily driving SBOM adoption outside of the public sector. These new regulations have forced vendors, especially those selling to the US government and in the EU, to scrutinize what’s in the software.

• US Government: EO 14028 requires federal agencies to collect SBOMs from vendors
• EU Enterprises: The EU Cyber Resilience Act (CRA) requires an SBOM for any enterprise that sells “products with software components” in the EU market
  • BUT won’t be fully enforced until December 2027—you still have time to get ahead of this one!
• Highly regulated industries: Meaning defense (continuous ATO), healthcare (FDA approval) and finance (DORA, PCI DSS 4.0) all require SBOMs

But what are your customers really after? Most are looking for:

• A clear, standardized inventory of what’s in your software (open source, third-party, proprietary)
• Evidence you’re proactively remediating supply chain vulnerabilities
• A baseline for risk assessment and future incident response

Some customers will have strict formats or frequent asks; others are just “checking the box.” It’s important to clarify what’s really required.

Decoding the Request for an SBOM: What’s Actually Required?

When a customer asks for an SBOM, don’t assume you know what they want. Here’s how to get clarity:

Ask these questions

• Format: Do you require SPDX, CycloneDX, or will any standard SBOM format do?
• Update Frequency: Is a one-time SBOM sufficient, or do you require continuous updates with every new release?
  • NOTE: If your customer is FedRAMP authorized or a US federal agency (including DoD) continuous monitoring (ConMon) is required
• Depth: Do you want only direct dependencies, or transitive (all sub-dependencies) as well?
• Delivery: How do you want to receive the SBOM—portal, API, email, physical media?

Minimum requirements

Most regulated buyers accept SPDX or CycloneDX formats as long as they meet the NTIA’s Minimum Elements. One SBOM per major release is typical, unless otherwise specified.

Red Flags

• Unreasonably frequent update requests (e.g., “every nightly build”)
• Requests for highly granular or proprietary information you can’t legally or safely disclose

Contract language examples

• “Vendor shall provide an SBOM in SPDX or CycloneDX format at product release.”
• “Vendor will update the SBOM within 30 days of any significant component change.”

Key Risks and Negotiation Tactics

The biggest risk? Overcommitting—contractually agreeing to deliver what you can’t. 

Contract negotiations around SBOM requirements present unique challenges that combine technical complexity with significant business risk. Understanding common problematic language and developing protective strategies prevents overcommitment and reduces legal exposure.

Here’s how to stay safe:

Risks

• Operational: You lack fully instrumented software development pipeline with integrated SBOM generation and can’t meet the update frequency as promised.
• Legal: You don’t have complete supply chain transparency and risk exposing proprietary or third-party code you’re not allowed to disclose.
• Reputational: Missing deadlines or failing to deliver undermines customer trust.

Red flags in contracts

1. Unlimited liability clauses for SBOM accuracy 

• 100% accurate SBOMs create impossible standards—no automated tool achieves this level of accuracy, and manual verification is prohibitively expensive

2. Penalty clauses for incomplete or inaccurate SBOMs

• You should be able to remediate mistakes in a reasonable timeframe

3. Real-time or continuous SBOM update requirements ignoring practical development and release cycles
4. Requirements for complete proprietary component disclosure 

• May violate third-party licensing agreements or expose competitive advantages

5. No provision for IP protection

• If you’re increasing their supply chain transparency they need to reciprocate and protect your interests

6. Vague standards (“must provide industry best-practice SBOMs” without specifics)

How to negotiate

Push back on frequency: 

“We can provide an updated SBOM at each major release, but not with every build.”

Standard delivery timelines should align with existing release cycles—quarterly updates for stable enterprise software, per-release delivery for rapidly evolving products.

Don’t roll over on accuracy:

“We can generate SBOMs automatically as part of our normal software development process, provide reasonable manual validation and correct any identified issues.”

Reasonable accuracy standards acknowledge tool limitations while demonstrating good faith effort.

Protect sensitive info: 

“SBOM details do not extend to proprietary components or components protected by confidentiality.”

Redact or omit sensitive components, and communicate this upfront.

Quick-Start: Fast Path to SBOM Compliance (for Resource-Constrained Teams)

You don’t need to boil the ocean. Here’s how to get started—fast:

First Five Moves

1. Clarify the ask: Use the questions above to pin down what’s really required.
2. Inventory your software: Identify what you build, ship, and what major dependencies you include.
3. Choose your tooling:

• For modern apps, consider open source tools (e.g., Syft) or commercial platforms (e.g., Anchore SBOM).
• For legacy systems, some manual curation may be needed.

4. Assign ownership: Clearly define who in engineering, security, or compliance is responsible.
5. Pilot a single SBOM: Run a proof of concept for one release, review, and iterate.

Pro tips:

• Automate where possible (integrate SBOM tools into CI/CD).
• Don’t over-engineer for the first ask—start with what you can support.

Handling legacy/complex systems:

Sometimes, a partial or high-level SBOM is enough. Communicate limitations honestly and document your rationale.

Efficient Operationalization: Making SBOMs Work in Your Workflow

When you’re ready to operationalize your SBOM initiative, there are four important topics to consider:

1. Automate SBOM creation:
   Integrate tools into your build pipeline; trigger SBOM creation with each release.
2. SBOM management:
   Store SBOMs in a central repository for easy search and analysis.
3. Version and change management:
   Update SBOMs when major dependencies or components change.
4. Delivery methods:
   • Secure portal
   • Customer-specific API
   • Encrypted email attachment

This is also a good time to consider the build vs buy question. There are commercial options to solve this challenge if building a homegrown system would be a distraction to your company’s core mission.

Turning Compliance into Opportunity

SBOMs aren’t just a checkbox—they can help your business:

• Win deals faster: “Having a ready SBOM helped us close with a major public sector buyer ahead of a competitor.”
• Shorten security reviews: Automated SBOM delivery means less back-and-forth during customer due diligence.
• Build trust: Demonstrate proactive risk management and transparency.

Consider featuring your SBOM readiness as a differentiator in sales and marketing materials.

SBOM Readiness Checklist

::Checklist::

Have we clarified the customer’s actual SBOM requirements?

✅: Continue

❌: Send request back to customer account team with SBOM requirements

Do we know which SBOM format(s) are acceptable?

✅: Continue

❌: Send request back to customer account team with SBOM requirements

Have we inventoried all shipped software and dependencies?

✅: Continue

❌: Send to engineering to build a software supply chain inventory

Have we selected and tested an SBOM generation tool?

✅: Continue

❌: Send to engineering to select and integrate an SBOM generation tool into CI/CD pipeline

Do we have clear roles for SBOM creation, review, and delivery?

✅: Continue

❌: Work with legal, compliance, security and engineering to document SBOM workflow

Are our contractual obligations documented and achievable?

✅: Continue

❌: Work to legal to clarify and document obligations

Do we have a process for handling sensitive or proprietary code?

✅: You’re all good

❌: Work with engineering and security to identify sensitive or proprietary information and develop a redaction process

Conclusion: From Reactive to Strategic

SBOM requirements are here to stay—but meeting them doesn’t have to be painful or risky.

The most forward-thinking organizations are transforming SBOM compliance from a burden into a strategic advantage. By proactively developing robust SBOM capabilities, you’re not just checking a box—you’re positioning your company as a market leader in security maturity and transparency. As security expectations rise across all sectors, your investment in SBOM readiness can become a key differentiator, driving higher contract values and protecting your business against less-prepared competitors.

Ready to take the first step?

“Most SBOMs are barely valid, few meet minimum government requirements, and almost none are useful.”

Harsh. But this is still a common sentiment by SBOM users on LinkedIn. Software bills of materials (SBOMs) often feel like glorified packing slips—technically present but practically worthless.

Yet Kate Stewart, one of the most respected figures in open source, has dedicated over a decade of her career to SBOMs. As co-founder of SPDX and a Linux Foundation Fellow, she’s guided this standard from its inception in 2010 through multiple evolutions. Why would someone of her caliber pour years into something supposedly “useless”?

Because Stewart, the Linux Foundation and the legion of SDPX contributors see something the critics don’t: today’s limitations aren’t a failure of vision—they’re a foundation for the growing complexity of the software supply chain of the future.

Because Stewart, the Linux Foundation and the legion of SDPX contributors see something the critics don’t: today’s limitations aren’t a failure of vision—they’re a deliberate strategy. They’re following the classic startup playbook: nail a minimal use-case first, achieve critical mass, then expand horizontally. The “uselessness” critics complain about? That’s a feature, not a bug.

Death by a Thousand Cuts

To understand where we’re headed, we need to start where it all began: back in 2009 with Kate and a few of her key software architects at Freescale Semiconductor spending their weekends manually scanning software packages for licenses before the launch of a new semiconductor chip.

Stewart and her team faced what seemed like a manageable challenge—tracking open source software (OSS) licenses for roughly 500 dependencies. But as she recalls, “It was death by a thousand cuts.” Every weekend, they’d pore over packages, hunting for license information, trying to avoid the legal landmines hidden in their newest chip’s software supply chain.

The real shock came from discovering how naive their assumptions were. “Everyone assumes the top-level license is all there is,” Stewart explains, “but surprise!” Buried deep in transitive dependencies—the dependencies of dependencies—were licenses that could torpedo entire projects. GPL code hidden three layers deep could force a proprietary product open source. MIT licenses with unusual clauses could create attribution nightmares.

This wasn’t just Freescale’s problem. Across the industry, companies were hemorrhaging engineering hours on manual license compliance.

The Counterintuitive Choice

Here’s where the story takes an unexpected turn. When the Linux Foundation’s FOSSBazaar working group came together to design a solution, they made a choice that still frustrates people today: they went minimal. Radically minimal.

The working group—including Stewart and other industry experts—envisioned SBOMs as “software metadata containers”—infinitely expandable vessels for any information about software components. The technology could support hashing, cryptographic attestations, vulnerability data, quality metrics, and more. But instead of trying to predict every potential use-case they chose to pare the original SPDX spec down to only its essentials.

Stewart knew that removing these features would make SBOMs “appear” almost useless for any purpose. So why did they proceed?

The answer lies in a philosophy that would define SBOM’s entire evolution:

“[We framed] SBOMs as simply an “ingredients list”…but there’s a lot more information and metadata that you can annotate and document to open up significant new use-cases. [The additional use-cases are] really powerful BUT we needed to start with the minimum viable definition.”

The goal wasn’t to solve every problem on day one—it was to get everyone speaking the same language. They chose adoption over the overwhelming complexity of a fully featured standard.

Why the ‘Useless’ Jab Persists

By launching SPDX with a minimal definition to encourage broad adoption and make the concept approachable, the industry began evaluating it equally as minimally—seeing SBOMs as simple ingredient lists rather than an extensible framework. The simplicity of the standard made it easier to grasp, but also easier to dismiss.

Today’s critics have valid points:

• Most SBOMs barely meet government minimums
• They’re treated as static documents, generated once and forgotten
• Organizations create them purely for compliance, extracting zero operational value
• The tools generating them produce inconsistent, often invalid outputs

But here’s what the critics miss: SBOMs aren’t truly static documents—at least, not in practice. They’re more like Git version-controlled files: static snapshots that form a dynamic record over time. Each one captures the meta state of an application at a given moment, but their value emerges from their evolution. As Stewart emphasizes, “Every time you apply a security fix you are revving your package. A new revision needs a new SBOM.” Just as Git commits accumulate to form a living history of a codebase, SBOMs should accumulate and evolve to reflect the ongoing lifecycle of an application.

The perception problem is real, but it’s also temporary.

The HTTP Playbook

To understand why the minimal SBOMs strategy is powerful, consider the evolution of HTTP.

In 1991, the original HTTP/0.9 protocol could only request a document using a GET method and receive raw HTML bytes in return. There were no status codes, no headers, and no extensibility. Critics at the time leveled familiar critiques against the fledgling protocol—”barely functional”, “useless”, etc. But that simplicity was its genius. It was a minimum viable definition that was easy to implement and rapidly adopted. 

And because it was adopted, it grew and evolved.

Today, HTTP headers handle:

• Security policies (Content‑Security‑Policy, Strict‑Transport‑Security)
• Performance optimization (caching, compression)
• State management (cookies and session handling)
• Authentication and authorization
• Client hints and feature detection

Nobody in 1991 imagined we’d use HTTP headers to prevent cross‑site scripting attacks or optimize mobile performance. But the extensible design made it possible.

SBOMs are following the exact same playbook. The industry expected them to solve license management—the original Package Facts vision. Instead, the killer app turned out to be vulnerability management, driven by the explosion of software supply chain attacks like SolarWinds and Log4j.

“SPDX has grown use‑case by use‑case,” Stewart notes. And each new use-case doesn’t just add features—it enables entirely new categories of applications.

SBOMs today are where HTTP was in 1991—functionally limited but primed for explosion.

The Expansion Is Already Here

The evolution from SPDX 2.x to 3.0 proves this strategy is working. The changes aren’t incremental—they’re transformational:

From Documents to Graphs: SPDX 3.0 abandons the monolithic document model for knowledge graph model. Instead of one big file, you have interconnected metadata that can be queried, analyzed, and visualized as a network.

From Software to Systems: The new specification handles…

• Service profiles for cloud infrastructure
• AI model and dataset profiles (tracking what data trained your models)
• Hardware BOMs for IoT and embedded systems
• Build profiles that cryptographically link source to binary
• End-of-life metadata for dependency lifecycle management

Real-World Implementations: This isn’t theoretical. The Yocto project already generates build-native SBOMs. The Zephyr project produces three interlinked SBOMs:

1. Source SBOM for the Zephyr RTOS itself
2. Source SBOM for your application
3. Build SBOM that cryptographically links everything together

These implementations show SBOMs evolving from compliance checkboxes to operational necessities.

The Endgame: Transparency at Scale

Kate Stewart summarizes the vision in seven words: “Transparency is the path to minimizing risk.”

But transparency alone isn’t valuable—it’s what transparency enables that matters. When every component in your software supply chain has rich, queryable metadata, you can:

• Instantly identify affected systems when a zero-day disclosure drops
• Prove compliance with regulations automatically
• Track technical debt and maintenance burden in real-time
• Make informed decisions about component selection
• Automate security policy enforcement

The platform effect is already kicking in. More adoption drives more use-cases. More use-cases drive better tooling. Better tooling drives more adoption. It’s the same virtuous cycle that turned HTTP from a simple network protocol into the nervous system of the web.

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

Playing the Long Game

The critiques of SBOMs as they are today suffer from a failure of imagination. Yes, they’re minimal. Yes, they’re often poorly implemented. Yes, they feel like “compliance theater”. All true.

The founders of SPDX made a calculated bet: it’s better to have adoption of a simple but potentially “useless” standard that can evolve than to have a perfect standard that nobody uses. By starting small, they avoided the fate of countless over-engineered standards that died in committee.

Now, with the cold start overcome and adoption growing, the real expansion begins. As software supply chains grow more complex—incorporating AI models, IoT devices, and cloud services—the metadata infrastructure to manage them must evolve as well.

The teams generating “barely valid” SBOMs today are building the muscle memory and tooling that will power tomorrow’s software transparency infrastructure. Every “useless” SBOM is a vote for an open, transparent, secure software ecosystem.

The paradox resolves itself: SBOMs are useless today precisely so they can become essential tomorrow.

Learn about SBOMs, how they came to be and how they are used to enable valuable use-cases for modern software.

Watch Now

This blog post has been archived and replaced by the supporting pillar page that can be found here: https://anchore.com/wp-admin/post.php?post=987475325&action=edit

The blog post is meant to remain “public” so that it will continue to show on the /blog feed. This will help discoverability for people browsing the blog and potentially help SEO. If it is clicked on it will automatically redirect to the pillar page.