Anchore Enterprise 5.25 introduces a completely rewritten scanning engine and comprehensive upgrades to imported SBOM management. This release is designed to streamline your software supply chain security by delivering consistent analysis across developer and production workflows, advanced EPSS and CISA KEV vulnerability filtering, and automated artifact lifecycle policies. As organizations scale their supply chain security, this update helps DevSecOps teams maintain absolute accuracy while significantly reducing vulnerability noise.

Organizations today are ingesting thousands of SBOMs from 3rd-party vendors, open source projects, and internal builds. The challenge is no longer just generating or collecting these documents; it is managing, filtering, and prioritizing the vulnerabilities within them without drowning in noise or paying for unnecessary storage bloat. Platform engineers require absolute consistency between what a developer sees in their local CLI and what the enterprise backend reports in production.

Anchore Enterprise 5.25 addresses these challenges directly through two major platform upgrades.

The Unified Scanning Engine: Native Syft and Grype Alignment

Organizations often face friction when developer CLI tools and enterprise backend systems utilize different underlying analysis pathways. This can occasionally lead to inconsistent SBOM generation or varying vulnerability results across different workflows, eroding developer trust.

Anchore Enterprise’s image analysis and vulnerability scanning engine has been completely rewritten to align natively with Syft and Grype (Anchore’s flagship open source tools).

• Unified Accuracy: SBOMs generated via AnchoreCTL and Anchore Enterprise’s backend are now perfectly consistent, utilizing the same underlying library. You get the exact same results regardless of the workflow. (Note: Because of this alignment, you may observe slight differences in SBOM content and vulnerability results when comparing images analyzed prior to v5.25 against the same image analyzed with v5.25).
  
• Performance & Cost Efficiency: The rewritten engine yields significant performance improvements during analysis and reduces object storage size due to smaller data artifacts, directly controlling infrastructure costs at scale.

Elevating Imported SBOMs to First-Class Citizens

Traditionally, imported SBOMs have been treated as somewhat opaque flat files compared to natively scanned container images. Anchore Enterprise 5.25 fundamentally changes this, bringing the deep context, discoverability, and lifecycle management previously reserved for container images directly to imported SBOMs.

These upgrades reflect the reality that modern supply chain security extends far beyond containers.

• Deep Context via SBOM “Type” Attribute: A new required field classifies exactly what an imported SBOM represents (e.g., Application, Container, Device, File System, Firmware, Library, Virtual Machine Disk). This transforms flat files into context-rich assets, providing immediate clarity on what type of codebase element is being analyzed.
  
• Enhanced Discoverability: New filters on the imported SBOMs page allow teams to search by Name, Version, and Type. As organizations scale to thousands of stored SBOMs, security teams can instantly pinpoint the exact assets they need to review.
  
• High-Signal Vulnerability Filters: New filters on the imported SBOMs vulnerability page include Minimum CVSS, Minimum EPSS Score, On CISA KEV List, Vulnerability Name/ID, and Severity. Cures vulnerability fatigue. By filtering for highly exploitable vulnerabilities (via EPSS and CISA KEV), security teams can focus their remediation efforts on what actually poses a risk, rather than drowning in low-severity CVEs.
  
• Automated Artifact Lifecycle Policies: Support for Imported SBOMs has been added to the Artifact Lifecycle Policy engine. Platform engineers can automate the cleanup of “old” or stale imported SBOMs based on user-defined criteria, maintaining strict control over object storage bloat.

How It Works: Managing Imported SBOM Lifecycles

To prevent storage bloat, you can now configure lifecycle policies for imported SBOMs directly alongside your container image policies.

For example, you can automatically purge imported SBOMs of an “Unknown” type that are older than 90 days. This can be configured via the API or directly in the UI under Policies → Artifact Lifecycle.

anchorectl system lifecycle policy add \
  --name "auto-delete-unknown-sboms" \
  --description "Purge imported SBOMs typed as Unknown older than 90 days" \
  --artifact-type imported_sbom \
  --days_since_analyzed 90 \
  --action delete

anchorectl system lifecycle policy add \
  --name "auto-delete-unknown-sboms" \
  --description "Purge imported SBOMs typed as Unknown older than 90 days" \
  --artifact-type imported_sbom \
  --days_since_analyzed 90 \
  --action delete

Use Cases by Role

• Developers: Benefit from “Unified Accuracy.” By using AnchoreCTL locally, developers see the exact same SBOM and vulnerability results that the security team will see in the enterprise backend, eliminating the “it passed on my machine” friction.
  
• Security Architects: Can apply modern, exploit-driven prioritization metrics (CISA KEV and EPSS) to third-party software and firmware, dramatically reducing triage time.
  
• Platform Engineers: Gain programmatic control over storage costs with automated Artifact Lifecycle Policies for thousands of imported SBOMs.

Ready to Upgrade?

Anchore Enterprise 5.25 delivers the unified consistency developers want and the comprehensive, scalable supply chain security that enterprise platform and security teams demand.

Existing Customers:

• Upgrade to Anchore Enterprise 5.25 today. Reach out to your Account Manager for upgrade support.
• Check the Anchore Enterprise Documentation for specifics on configuring Artifact Lifecycle Policies.

New to Anchore?

Request a guided demo to see the new Syft/Grype unified engine and imported SBOM management in action.

Why “Set It and Forget it” No Longer Works

The one-and-done approach to cybersecurity compliance has been obsolete for more than a decade. Even periodic, audit-driven assessments of an organization’s compliance posture are no longer sufficient in modern environments.

In recent years, this urgency has only intensified. The pace of technological change, the expansion of the software supply chain, and escalating regulatory scrutiny have made automation and continuous compliance not just best practices, but operational necessities. Here’s why:

Constantly Evolving Threat Landscape

New vulnerabilities are discovered every day, from zero-day exploits to newly disclosed CVEs in widely used software. A system that met compliance requirements last quarter may already contain exploitable weaknesses today. At the same time, attackers are increasingly using automation and AI to scan for vulnerabilities at scale, dramatically shortening the window between disclosure and exploitation. In this environment, static controls quickly become outdated.

Dynamic Infrastructure (Cloud & Containers)

Modern infrastructure is no longer static. Cloud resources, containers, and serverless functions are constantly spinning up and down, meaning the environment you audited last month may not even exist today. Infrastructure as Code enables rapid changes, but a single misconfiguration pushed through a CI/CD pipeline can introduce compliance violations across an entire environment in minutes. Continuous visibility is required to maintain control.

Software Supply Chain Complexity

Today’s applications are built on layers of open source dependencies, many of which include nested, transitive components. A newly discovered vulnerability in any one of those dependencies can introduce risk long after your software is deployed. Additionally, organizations increasingly rely on third-party vendors and SaaS providers, expanding the compliance boundary beyond internal systems and requiring ongoing vendor risk management rather than one-time assessments.

The Shifting Sands of Regulatory Requirements

Compliance frameworks are not static documents. Standards such as SOC 2, ISO 27001, FedRAMP, PCI DSS, and NIST regularly update their guidance to reflect emerging threats and best practices. At the same time, new regulations—particularly around data privacy and cybersecurity reporting—continue to emerge across different jurisdictions. Organizations must continuously adapt to remain compliant.

Rapid DevOps & CI/CD Pipelines

Development cycles have accelerated dramatically. Code is deployed weekly, daily, or even multiple times per day, meaning compliance controls must operate at the same speed. Security can no longer be a checkpoint at the end of a release cycle; it must be integrated into development workflows from the beginning. Without automation and embedded validation, compliance quickly falls behind deployment velocity.

What is Continuous Compliance Monitoring?

Continuous compliance monitoring is the practice of validating security and regulatory controls on an ongoing basis across the software lifecycle—not just at audit time. Rather than relying on static reports or periodic assessments, it embeds automated policy enforcement, vulnerability detection, and configuration checks directly into CI/CD pipelines and runtime environments. The objective is to maintain real-time evidence that controls are functioning as intended as code, dependencies, and infrastructure evolve. 

Continuous compliance doesn’t happen by accident. It requires intentional design: systems that can scale with modern software delivery, surface meaningful signals from noise, and reduce dependency on manual oversight. Those capabilities rest on three foundational pillars.

The 3 Key Pillars of Continuous Compliance

At its core, continuous compliance monitoring rests on three foundational pillars:

• Compliance automation: Manual processes are slow, prone to human error, and simply can’t keep up with the pace of change. Automation is the engine that drives continuous monitoring, gathering data, checking configurations, and identifying deviations without constant human intervention.
• Real-time visibility: This isn’t about looking at yesterday’s reports. It’s about having an immediate view into your compliance posture. If a critical system’s configuration drifts out of compliance, you know about it now, not next week. This visibility allows for immediate corrective action.
• Actionable insights: Raw data isn’t enough. Continuous monitoring systems don’t just collect information; they analyze it, correlate events, and present you with clear, actionable insights. This means distinguishing between minor anomalies and critical violations, empowering security teams to prioritize remediation while providing clear reporting and evidence to key stakeholders.

Together, these pillars create a robust defense that constantly checks your systems, networks, and data against your defined compliance standards, ensuring deviations are caught and addressed promptly.

How to Implement Continuous Compliance Monitoring: A Step-by-Step Approach

Embarking on continuous compliance monitoring might seem daunting, but like any significant journey, it becomes manageable when broken down into clear, actionable steps.

Step 1: Define Your Compliance Scope and Objectives

Before you can monitor anything, you need to know what you’re monitoring for and why. Begin by clearly identifying all relevant regulatory frameworks, industry standards, and internal policies that apply to your organization. This might include FedRAMP, NIST 800-53, GDPR, HIPAA (for healthcare organizations), PCI DSS, ISO 27001, or a combination thereof. For each, articulate specific, measurable compliance objectives. What does “compliant” look like for each requirement? This foundational step ensures your efforts are focused and aligned with your organizational goals.

Step 2: Identify Key Controls and Metrics

Once your scope is defined, translate those compliance requirements into specific technical and administrative controls. For example, if a requirement is “data must be encrypted at rest,” your control might be “ensure all database storage volumes are encrypted using AES-256.” For each control, establish clear metrics that indicate its health and compliance status. How will you measure if encryption is enabled? What defines “successful” patch management? These metrics will be the data points your monitoring system relies on.

Step 3: Select the Right Technology and Tools

Continuous compliance is only as strong as the systems enforcing it. If your controls depend on manual reviews, disconnected scanners, or point-in-time reporting, you’re not operating a continuous model—you’re layering automation onto a compliance audit workflow. The right tooling must integrate directly into how software is built, delivered, and run.

To operationalize continuous compliance effectively, organizations should look for automated tools that provide:

• Software composition visibility & SBOM management: Modern applications are built on complex open source ecosystems, and compliance requirements increasingly demand traceability across dependencies. Tools should generate accurate, reproducible Software Bills of Materials (SBOMs) and allow teams to manage and evaluate them over time.
  
  🛡️ How Anchore helps: Generate SBOMs, centralize SBOM management, and enforce policy against them at scale.
  
  
• Policy-driven vulnerability & compliance enforcement: Detecting CVEs is table stakes. The real requirement is the ability to codify compliance frameworks (whether federal, internal, or otherwise) into enforceable policies that run automatically in CI/CD pipelines and registries.
  
  🛡️ How Anchore helps: Anchore allows you to deploy a ready-to-use policy to achieve compliance with a variety of federal standards. Each rule is mapped to the specific control version for easy report and evidence generation. 
  
  
• Lifecycle-wide risk evaluation: Cybersecurity compliance cannot stop at build time. The risk profile of deployed software changes as new vulnerabilities are disclosed. Tools should continuously re-evaluate existing artifacts against updated vulnerability intelligence to identify newly introduced risk.
  
  🛡️ How Anchore helps: Anchore continuously analyzes stored SBOMs against fresh vulnerability feeds, ensuring you’re alerted when previously compliant software becomes non-compliant.
  
  
• Actionable, context-rich intelligence: Security teams don’t need more dashboards—they need prioritization. Tools should correlate vulnerabilities with severity, exploitability, and policy impact so teams can focus on meaningful remediation.
  
  🛡️ How Anchore helps: Anchore makes it easy to prioritize vulnerability rating based on CVSS Score and Severity, EPSS, and CISA KEV data, reduce noise and drastically improve triage time.
  
  
• Developer-aligned, automation-first integration: Continuous compliance only works when it integrates seamlessly into CI/CD pipelines, artifact registries, and cloud-native workflows without slowing delivery.
  
  🛡️ How Anchore helps: Anchore offers a wide variety of integrations to make it quick and easy to incorporate Anchore compliance checks into your existing DevOps toolchain.
  

In short, continuous compliance isn’t achieved by running more scans—it’s achieved by embedding enforceable, automated policy controls into the fabric of software delivery. The right tools don’t just help you pass an audit; they help you maintain provable compliance as your software and threat landscape evolve.

Step 4: Establish Automated Monitoring and Alerting

With your tools in place, set up continuous data collection and automated checks against your defined controls and metrics. This means configuring your systems to constantly scan for misconfigurations, policy violations, unauthorized access attempts, and other deviations from your compliance baselines. Crucially, establish a robust alerting system. Who needs to be notified when a critical control fails? How are alerts prioritized? Define clear thresholds and escalation paths so that issues are promptly brought to the attention of the right personnel.

Step 5: Integrate with Incident Response and Remediation

Monitoring is only useful if detected issues are addressed. Integrate your continuous compliance system with your existing incident response and remediation processes. When an alert fires, it should trigger a predefined workflow. This might involve automatically creating a ticket in your service desk system, notifying a specific security or operations team, or even triggering automated remediation actions (e.g., reverting a misconfigured setting). The goal is to move seamlessly from detection to resolution, minimizing the window of non-compliance.

Step 6: Regularly Review and Refine Your Program

Compliance isn’t a one-time project; it’s an ongoing journey. Regularly review the effectiveness of your continuous compliance monitoring program. Are your controls still relevant? Are your metrics accurate? Are there new regulations or threats that require adjustments? Conduct periodic internal audits of your monitoring system itself. Gather feedback from the teams responsible for responding to alerts. This iterative process of review and refinement ensures your program remains robust, relevant, and continuously improves over time.

Getting Started with Continuous Compliance Monitoring

In a world where software changes daily and regulatory expectations evolve just as quickly, continuous compliance is no longer optional. Anchore Enterprise helps organizations move beyond audit-driven security by embedding automated, policy-based enforcement directly into the software supply chain. Contact us today for a personalized demo. 

Watch our customer Dreamfactory explain how Anchore Enterprise simplifies and automates their compliance needs.

Watch Video

For a decade, the security industry’s rallying cry was “you can’t secure, what you can’t see.” We demanded to know what was in our software. But now that we have it, we are discovering a harsh truth: visibility without context is just noise. Security teams are currently drowning in a flood of disjointed manifests and static spreadsheets, creating a paradox where we have more data than ever, yet remain unable to answer the fundamental question: “Are we safe?”

This paradox, where more artifacts lead to less clarity, is what we term “SBOM Sprawl.” In our recent webinar, How to Identify and Tackle SBOM Sprawl, Alex Rybak (Anchore) and Russ Eling (OSS Consultants) dissected this growing challenge, outlining how organizations can move from simple compliance generation to intelligent orchestration.

Key takeaways from their discussion include:

• The Assembly Paradox: Why modern software development mirrors the tiered supply chain of Boeing’s aerospace manufacturing
• The Map vs. The Territory: Why a static SBOM is merely a roadmap, and how its value depends entirely on the tools that consume it
• The 4-Day Clock: How SEC material event regulations are forcing security teams to prioritize query speed over data volume
• Realistic Scope: Understanding that SBOMs are tools for managing known vulnerabilities, not magic wands for unforeseen threats

The Complexity Trap: Lessons from Aerospace

Alex Rybak, Director of Product Management at Anchore, notes a critical parallel between physical and digital supply chains.

An airplane has 10s of millions of parts, and Boeing ultimately builds the tail fin, rear fuselage and wing fairings…that’s it.

This observation highlights a fundamental reality: modern engineering is an assembly challenge, not a fabrication challenge. In the software world, dependency trees have exploded from dozens of libraries to thousands of direct and transitive components.

This complexity is fundamentally different from the monolithic applications of the past. Where traditional software was written in-house with a few trusted libraries, modern cloud-native applications are assembled from global, open source supply chains. When an organization generates SBOMs without a strategy for this complexity, they don’t gain visibility; they simply generate noise.

The Evolution of SBOM Sprawl

This isn’t the first time the industry has faced a visibility crisis. The pattern we’re seeing with SBOM regulation is remarkably similar to the early days of open source adoption. First came the explosion of usage, followed by the scramble for governance.

From Static Files to Dynamic Systems

• Phase 1: The Artifact Era (Pre-2021) was characterized by sporadic, manual inventory tracking. Organizations viewed SBOMs as “nice-to-have” documentation. Security reviews were manual because release cadences were slower. Visibility was limited, but so was the volume of data.
• Phase 2: The Regulatory Explosion (2021-2024) brought transformation via EO 14028 and the EU Cyber Resilience Act. Requirements exploded, leading to “SBOM Sprawl.” Every customer demanded different formats (SPDX 2.3 vs. CycloneDX), fields, and delivery mechanisms. This led to data conflicts, where the SBOM generated by engineering didn’t match the one scanned in production, complicating response to incidents like Log4j.
• Phase 3: The Systemization Era (2025-Present) emerged as standards like SPDX 3.0 and ISO 5230 provided structure. Organizations realized that generation is a commodity; the value lies in ingestion, analysis, and VEX (Vulnerability Exploitability eXchange) implementation.

We are now seeing this evolution compressed into a much shorter timeframe, driven by aggressive regulatory deadlines.

Learn how to transform your SBOMs from a compliance checkbox into a strategic asset, with the controls needed to prevent sprawl and maximize value.

Watch Now

The Roadmap Reality

The presence of an SBOM file does not equate to security posture. As Rybak emphasizes:

“Just having an SBOM doesn’t fix problems, it gives you a roadmap on your parts…an SBOM is only as good as the tools or people that built it.”

A static SBOM is fundamentally different from a managed software supply chain. A file on a disk ages the moment it is generated. If that roadmap is inaccurate, outdated, or disconnected from vulnerability intelligence, it becomes a liability rather than an asset.

Effective governance requires moving from “having an SBOM” to maintaining a dynamic inventory that maps assets to risks. This means integrating SBOM generation into the CI/CD pipeline, ensuring that every build produces a high-fidelity record that can be queried when the next zero-day hits.

The Financial Imperative: The 4-Day Clock

The stakes for accurate data have shifted from technical debt to legal liability. Rybak points out the specific pressure created by the SEC:

“If you look at SEC regulations, if there has been a material security event, the clock starts. You have four days to create an 8K report.”

This requirement fundamentally alters the role of the security team. Incident response is no longer just a technical triage; it is a financial disclosure workflow.

When a material event occurs, organizations cannot afford to spend days grep-ing through repositories or emailing engineering leads to ask, “Do we use this library?” The 4-day window requires instant, queryable visibility. Sprawl the enemy of speed.

Pragmatism and Scope

While SBOMs are essential, Russ Eling, Founder of OSS Consultants, offers a necessary reality check regarding their capabilities:

“SBOMs are not a cybersecurity cure-all. They’re effective at managing known vulnerabilities. They don’t necessarily extend to detecting unforeseen threats.”

An SBOM provides transparency into known components and allows organizations to map them against known vulnerabilities (CVEs). It does not inherently detect zero-day exploits or behavioral anomalies in runtime.

However, the key insight is that without an SBOM, you cannot effectively manage the knowns, which leaves zero bandwidth to hunt for the unknowns. By automating the management of known vulnerabilities through high-quality SBOMs and VEX, security teams free up human capital to focus on advanced threat hunting and architectural security.

Where Do We Go From Here?

To tame SBOM sprawl and turn compliance artifacts into security assets, organizations must adopt a phased approach.

Crawl: Standardization and Governance

1. Define the Standard: Select a primary internal format (e.g., SPDX 2.3 or 3.0) for storage, regardless of what customers request. Use converters for export only.
2. Establish Ownership: As Eling suggests, define whether the OSPO, Product Security, or Engineering owns the SBOM process.
3. Align with ISO 5230: Use the OpenChain standard to establish the foundational governance required to produce trusted data.

Walk: Automation and Context

1. Automate Generation: Integrate tools like Syft or Anchore Enterprise into the build pipeline. No manual generation.
2. Centralize Ingestion: Feed all SBOMs into a central management platform. A dispersed inventory is a useless inventory.
3. Implement VEX: Stop chasing false positives. Use VEX to communicate which vulnerabilities are not exploitable, reducing noise for downstream consumers.

The Strategic Imperative

The window of opportunity to establish these systems is open, but it won’t remain that way indefinitely. Just as organizations that ignored open source governance paid a heavy price during the Log4j crisis, those who ignore SBOM sprawl will face compounding technical debt and regulatory friction.

Organizations that transition from generating files to managing systems will gain significant agility. They will turn the 4-day SEC mandate from a crisis into a standard operating procedure, demonstrating resilience to customers and regulators alike.

Learn how to transform your SBOMs from a compliance checkbox into a strategic asset, with the controls needed to prevent sprawl and maximize value.

Watch Now

If you look at the trajectory of the software supply chain over the last few years, one thing becomes painfully clear: the old playbook is broken. For a decade, our industry has operated under the assumption that if we just hired enough people, bought enough scanners, and worked hard enough, we could reach a state of “perfect” security. We chased a clean dashboard with zero CVEs and a fortress-like perimeter.

But as we look toward 2026, that goal isn’t just difficult; it is mathematically impossible. We are facing a convergence of pressures that no amount of manual effort can withstand. The winners of the next era won’t be the ones with the cleanest reports. They will be the ones who have automated their compliance and built the engines to upgrade faster than the bad actors can attack.

To be honest, we don’t have a crystal ball. Nobody does. But we are trying our best to skate to where the puck is going. We want to share what we’re seeing so we can all navigate this shift together.

Reachability is not a silver bullet

For a long time, we pinned our hopes on “reachability.” The idea was simple: if a vulnerability isn’t reachable in the code, we don’t need to fix it. It was a triage strategy born of necessity.

However, the sheer volume of CVEs is growing out of control. Reachability is becoming a noisy, diminishing metric. It struggles to keep up with the flood. Reachability struggles with weakly typed languages like Python and Nodejs, which also happen to be two insanely popular languages. There’s also the problem of while you might not be using the code in question, can an attacker? The infosec world likes to call this “living off the land”. And there’s always the problem where someone starts using code that wasn’t used in the past, now you have a vulnerability that jumps out of nowhere unexpectedly.

We are moving toward a new metric: high velocity hygiene.

The question is shifting from “Is this vulnerable?” to “How fast can we upgrade?” We need to upgrade everything faster, not just the things with red flags attached to them. The goal is general hygiene across all of our code and dependencies. Technology that didn’t exist even a few years ago has come a long way to help us solve this problem. Hardened container images, vendored libraries, and automatic updates can make a gigantic difference. And of course vulnerability scanners that are fast and cover more ecosystems than ever before double check our work.

Supply chain attacks on steroids

Attacks will continue to rise because the fundamental incentives haven’t changed. Attackers still see many package repositories as prime targets, and every package repository is still struggling with resources. The rate of growth is not matching the rate of attacks. In fact, the attackers are about to get an upgrade.

We expect a significant increase in scale and sophistication as attackers leverage Large Language Models (LLMs). There is a distinct asymmetry at play here. Attackers have “zero red tape.” They can adopt new AI tools for exploitation immediately. We saw the start of this behavior with the Shai-Hulud attack in 2025.

Defenders, conversely, are slowed by procurement, legal reviews, and legacy infrastructure integration. This speed gap favors the adversary. While prevention is ideal, rapid response is the only viable reality for 2026.

EU CRA wake-up call

The industry is largely caught off guard regarding the EU Cyber Resilience Act (CRA). Later this year, (specifically; September 11) both vulnerability management and incident response will become law. As most deadlines work, the vast majority of organizations will start working on this around September 10.

This introduces strict reporting obligations (Article 14). Organizations must report actively exploited vulnerabilities and severe incidents to national authorities (CSIRTs) and ENISA within strict timelines.

Beyond reporting, SBOM requirements will be a critical part of this compliance landscape. You cannot report on what you do not know you have. Organizations will be forced to finally understand their software composition in depth, not as a “nice to have,” but to stay legal.

The inevitability of CompOps

“CompOps” (Compliance Operations) sounds like a buzzword nobody wants. Nobody likes compliance work. Also, it’s boring. But that is exactly why it will succeed.

As requirements mount, the only practical way to meet them is by applying DevOps principles to compliance. CompOps emerges as a survival mechanism. It is compliance that “just happens” through automation rather than a manual checklist. Most teams will start doing this by accident as compliance requirements get baked into the existing DevOps process.

We need to stop treating compliance as an annual audit event. It must be a continuous stream of evidence generated by the pipeline itself.

The state of open source in 2026

There will be more open source code than ever before. The graphs are still trending up exponentially.

We need to watch how major foundations like the Python Software Foundation (PSF), Apache, and Eclipse handle this pressure. They are facing the dual challenge of massive growth and new compliance requirements like the CRA demands on open source stewards.

The human element remains a serious risk. Developer burnout and funding are critical issues. We don’t yet know how far automation can take us in mitigating this, but the limit is being tested. We will be keeping an eye on the Sovereign Tech Agency in 2026.

Building the right boat

For too long, software supply chain security has relied on heroics. We relied on security engineers working late nights to triage thousands of CVEs. We relied on release managers scrambling to generate spreadsheets for auditors.

By 2026, that era must close. The sheer scale of the ecosystem means human heroism is no longer a scalable defense strategy.

We must build a system resilient by design. We need to treat the SBOM as a dynamic layer of observability. This allows teams to instantly query their entire software fleet to answer “where is X installed?”

Anchore helps organizations make this shift. We maintain open source tools like Syft (SBOM generation) and Grype (vulnerability scanning) to provide the data layer. For enterprises, the Anchore platform acts as the CompOps engine. It embeds “Policy-as-Code” directly into the CI/CD pipeline, enforcing rules automatically on every commit. This ensures you have the immediate, granular visibility needed to meet strict 24-hour incident reporting timelines without slowing down developers.

The outlook for 2026 isn’t about panic. It’s a “keep calm and carry on” moment. The flood waters are rising, but we are finally building the right boat.

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

Download Now

In the modern theater of digital warfare, the Department of War (DoW) is transitioning to a Zero Trust Architecture (ZTA). At the heart of this transition lies a fundamental principle: “Never Trust, Always Verify.”

For software applications, this means verifying every single component, library, and dependency before it ever touches a mission-critical network. Anchore Enterprise serves as a cornerstone for this verification, providing the deep visibility and continuous monitoring required to satisfy DoW Zero Trust mandates.

Setting the Stage: Zero Trust References

To understand how Anchore fits into the mission, it is important to first understand the context of Zero Trust within the DoW. Here is a breakdown of the critical documents and frameworks:

1. The Foundation (NIST 800-207): Defines the “Logic.” These are the underlying definitions that the Strategy and Reference Architecture are built upon.
2. The Vision (DoW ZT Strategy): Defines the “Why” and “When.” This sets the timeline and establishes the 7 Pillars of Zero Trust.
3. The Blueprint (DoW ZT Ref Arch): Defines the “How.” This outlines the technical capabilities organizations must build and defines the 5 Tenets of Zero Trust.
4. The Measuring Stick (CISA Maturity Model): The “Progress Tracker” used to measure how far along the path you are.

The 7 Pillars of Zero Trust: What We Protect

Anchore Enterprise plays a critical role in securing the pillars that support the DoW’s Zero Trust strategy. While traditional security focuses heavily on the perimeter, Anchore secures the workload itself.

User and Device Integrity

The first line of defense is ensuring that only authorized users and secure devices access the network. Anchore integrates with LDAP and Single Sign-On services (like Okta and Entra ID) to enforce strict identity management. For devices, we go a step further by generating Software Bills of Materials (SBOMs) to evaluate the security posture of the systems themselves. Using CI/CD techniques, virtual machines can have their SBOMs validated using policy-as-code to ensure they meet DoW requirements before they ever reach production.

Applications, Workloads, and Data

Securing the software layer (i.e., containers, virtual machines, and source code) is Anchore’s specialty. We generate SBOMs for containers, filesystems, and source code, applying strict policy checks to ensure compliance. By utilizing a Kubernetes Admission Controller, Anchore can stop non-compliant container deployments in their tracks. Furthermore, we leverage strict Role-Based Access Control (RBAC) to ensure least privilege for data, verifying that containers are built correctly with the right encryption and access parameters every time.

Network, Automation, and Visibility

To prevent lateral movement, Anchore ensures containers are configured with least privilege, exposing only necessary services. We automate this protection via policy packs that check for exposed secrets, malware, and misconfigurations at scale. Finally, we provide deep visibility into container registries and production workloads, logging data to your SIEM to allow for querying across the entire landscape.

Quick Reference: The 7 Pillars

The Five Tenets of Zero Trust: How We Protect

The DoW defines five foundational tenets that influence every aspect of Zero Trust. Anchore Enterprise turns these abstract tenets into operational realities.

Operating in a Hostile Environment

We must assume that the environment is hostile and that all users, devices, and applications are untrusted, regardless of their location. Anchore adopts this mindset by assuming that any software component…even those from “trusted” vendors…could be a vector for attack. We treat source code, containers, and VM images as untrusted until they are explicitly verified against security policies.

Presume Breach and Verify Constantly

Operating with the assumption that an adversary is already present requires constant vigilance. Anchore performs continuous re-scanning not just in registries, but also in Kubernetes using runtime inventory. If a new vulnerability is announced today, Anchore identifies exactly where that threat exists in your currently running environment immediately. We deny access by default, preventing the “trust” of a container image simply because it exists in a registry.

Scrutiny and Unified Analytics

Trust is not given; it is earned through scrutiny. Anchore analyzes multiple attributes to derive high confidence levels for access. This includes secrets, software licenses, and file-level integrity. We centralize this data to provide unified analytics, delivering a searchable, auditable history of every application or virtual machine that has ever touched the mission network.

Quick Reference: The 5 Tenets

Conclusion: Continuous Verification

Zero Trust is not a “one-and-done” checkbox; it is a state of continuous verification. By aligning with the DoW pillars and tenets, Anchore Enterprise allows the Department of War to move faster, innovate with confidence, and protect the mission.

By checking against the National Vulnerability Database (NVD) and specialized feeds like the GitHub Advisory Database, Anchore ensures that the DoW is defended against both common threats and sophisticated supply chain attacks. Furthermore, by incorporating data from the Known Exploited Vulnerability (KEV) catalog and Exploit Protection Scoring System (EPSS), Anchore helps prioritize risk across the organization effectively.

As the DoW continues to mature its Zero Trust strategy, Anchore Enterprise is here to mature and protect your security posture alongside it.

Ready to get started?

1. Generate: Leverage Syft to begin generating SBOMs for container images and file systems using our Getting Started guide.
2. Assess: Use Grype to assess your SBOMs for vulnerabilities and check them against your specific risk tolerance.
3. Enforce: Deploy Anchore Enterprise to bring it all together. Anchore Enterprise visualizes data, conducts STIG checks, and enforces policy-as-code across your SBOMs, container images, and source code.

Get in touch with us!

Understand, Implement & Leverage SBOMs for Stronger Security & Risk Management

Download Now

For years, cATO (continuous Authorization to Operate) was largely aspirational…or maybe, directionally correct but not practical to implement. The public commitment to operationalization of the Software Fast Track (SWFT), moves the reality of cATO within striking distance. The era of static compliance checklists is over, replaced by continuous, automated security evidence; you’ve been put on notice.

Here are the key insights needed to navigate this transition:

• The “Sponsor” Bottleneck: Why you cannot self-register for the Iron Bank and the specific DoD relationship you need to secure first.
• The 2-Week vs. 18-Month Gap: How the centralized reciprocity model creates a massive speed-to-market advantage over legacy RMF.
• The CMMC Trap: Why securing your enterprise network (CMMC) won’t prevent your software product from being rejected at the door.
• The End of PDF Compliance: Why static reports are being rejected in favor of dynamic, machine-readable SBOMs.

The SWFT Initiative Is No Longer an Experiment

The SWFT initiative establishes a centralized reciprocity model for software authorization that is fundamentally different from legacy processes. By validating security compliance once at the enterprise level, the Department eliminates redundant assessments, allowing authorized software to be consumed by any DoD agency immediately.

As noted in the DoD CIO SWFT RFI Combined Summary from December 2025, “The SWFT initiative… will reform the way the Department acquires, tests, and authorizes secure software.”

Implementation Milestone: January 2026

As of January 2026, SWFT has officially transitioned from an experimental “Pilot Program” (which began in May 2025) to an evolving requirement. It is no longer optional. It is the paved road for acquisition. The DoD has signaled that “[SWFT] is shifting from an experimental ‘sprint’ into a permanent, enterprise-wide ecosystem.”

Immediate Liability Under Phase 1 Regulations

Organizations must understand the liability landscape has shifted dramatically between Phase 1 and Phase 2 regulations:

• Phase 1 (Effective Nov 10, 2025): Self-attestation is already mandatory. By signing this assessment, executive leadership (CEO) assumes direct legal liability under the False Claims Act. While enforcement is currently reactive, prosecutors will likely target flagrant violations. As of November 10, 2025, all solicitations must meet this requirement.
• Phase 2 (Effective Nov 10, 2026): Third-party C3PAO certification becomes mandatory. Enforcement shifts from legal liability to automated system validation. Without a passing evaluation, systems will automatically deny eligibility, effectively locking vendors out of the market. The DoD can begin to condition awards on Level 2 assessment requirements starting in late 2026.

Iron Bank is Mandatory for Containerized Software Delivery to DoD

The scope of SWFT is specific and significant: it is mandatory for any vendor delivering containerized software (e.g., Kubernetes) to Platform One, Cloud One, or DoD Software Factories.

According to Platform One, “[The] Iron Bank is the DoD Centralized Artifacts Repository (DCAR)…containers accredited in Iron Bank have DoD-wide reciprocity across classifications.”

Contractual Mandates and Operational Impact

Contracts will explicitly require a “Continuous ATO (cATO)” or “Reciprocity-eligible software.” As outlined in the DoD cATO Memo (Feb 2022), cATOs represent “the gold standard for cybersecurity risk management” and do not have an expiration date.

The operational impact of this requirement creates two distinct pathways:

1. Centralized Pathway (Iron Bank): Use the centralized repository to achieve reciprocity in 2-4 weeks.
2. Decentralized Pathway (Legacy RMF): Attempting a legacy RMF cATO independently typically takes 12-18 months, creating a high risk of ineligibility for FY26 awards.

Iron Bank streamlines this significantly, providing an Acceptance Baseline Criteria (ABC) that “simplifies compliance and eliminates duplication of effort.”

The New Standard Requires Automated SBOMs

The regulatory basis for this shift is NIST SP 800-218 (SSDF). Compliance requires proving your process of writing code is secure from day one, helping “software producers reduce the number of vulnerabilities in released software.”

Transition from Static to Dynamic Artifacts

The DoD now requires machine-readable SBOMs that update with every code change, replacing static PDFs. The SWFT initiative is effectively establishing a “clearinghouse for SBOM data,” demanding dynamic visibility rather than one-off snapshots.

This mirrors the precedent set in February 2025, when the U.S. Army mandated actual data for all new software, rejecting “self-attestations” as insufficient.

Technically, this means organizations must implement automated policy packs to generate compliant SBOMs during the build process. As reinforced by the Secretary of Defense in July 2025, the DoD “will not procure any hardware or software susceptible to adversarial foreign influence.”

SWFT Secures the Product While CMMC Secures the Network Boundary

A common point of confusion is the relationship between CMMC and SWFT. They are fundamentally different compliance domains:

• CMMC protects your enterprise environment (network, laptops, email). It ensures contractor information systems can adequately protect CUI.
• SWFT protects the software deliverable (The binary/code). It reforms how the DoD acquires, tests, and authorizes secure software.

You need both. A secure enterprise environment (CMMC Level 2) is necessary but insufficient if the software deliverable itself is insecure.

Accessing the Iron Bank Requires a Government Sponsor

Access to this ecosystem is gated. Iron Bank is invitation-only; vendors cannot self-register. A Government Sponsor (DoD employee with a CAC) is required to formally request onboarding.

As the Iron Bank Onboarding Guide states, “The Requestor is responsible for Identifying a DoD Mission Owner/Government Sponsor who has a CAC card.”

Sponsorship Strategy

To navigate this, vendors must engage operational sponsors. Find the operational unit (e.g., Army or Air Force customer) that intends to use the software and request that they act as the sponsor. Iron Bank prioritizes “Mission Need,” and sponsorship by an operational unit validates this need, expediting the process.

Pro Tip: When researching SWFT search for “Platform One” or “Iron Bank” to access the correct documentation. This avoids confusion with DCSA SWFT (background checks) or the international SWIFT banking system.

Conclusion & Next Steps

The transition to SWFT represents a massive opportunity for vendors who move quickly, and a barrier to entry for those who wait. To ensure you are eligible for FY26 contracts, take these three steps immediately:

1. Secure Your Sponsor: Identify your government sponsor today and have them submit the onboarding request.
2. Audit Your Artifacts: Implement automated SBOM generation, management, and submission.
3. Pre-validate Compliance: Scan your software against SSDF policies before submission to ensure it passes on the first try.

The “fast track” is open, but only for those who have their data ready.

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

Download Now

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

At its core, any security tool is only as good as the data it uses. This is the age-old principle of “garbage in, garbage out.” If your security tooling is working with stale, incomplete, or inaccurate information, it will produce unreliable results. This leaves you with a false sense of security. 

To protect your software supply chain and wrestle the ever increasing wave of CVEs effectively, you need a constant stream of high-quality, up-to-date and a matched set of vulnerability data to your software and SBOM. This is especially critical for reacting to zero-day vulnerabilities, where every second counts. 

This post will take you “under the hood” to show you how Anchore Enterprise’s hosted data service. Put another way, a stream of vulnerability feeds are engineered to deliver the timely, accurate and enriched data needed to remediate vulnerabilities fast.

A lot has been changing in Anchore to provide better results with more data at your fingertips. From the introduction of KEV and EPSS datasets to the addition of secondary CVSS scores in Anchore Enterprise 5.20 and matched CPEs in 5.24. We also touch on the future of how this data can be further extended with the introduction and support of VEX (Vulnerability Exploitability eXchange) and VDR (Vulnerability Disclosure Report).

Let’s get started!

Introducing the Anchore Data Service

The landscape of software vulnerabilities is never static. New threats emerge daily, data sources are constantly updated, and upstream feeds can suffer from API changes, data inconsistencies, or inaccuracies. 

Managing this high-velocity, often-chaotic stream of information is a full-time job. This is where the Anchore Data Service as a delivery vehicle comes in. The service shoulders the heavy lifting by continuously ingesting, analyzing, and correlating vulnerability data from the latest intelligence from sources like Red Hat, Canonical, GitHub, NVD, CISA KEV, EPSS and much more.

Our security team additionally publishes ‘patches’ for this data, correcting upstream errors, suppressing known false positives, and enriching records to ensure maximum accuracy. The end result is a curated, high-fidelity set of intelligence feeds that are available to your Anchore Enterprise deployment. Whether in the cloud, on-premises, or even fully air-gapped, Anchore Data Service gives you a single, trustworthy source of truth for all your vulnerability scanning. 

We document the curated workflow in detail over on our vulnerability management docs pages, for this article we will unpack how this data is first made available and later how it can be utilized.

How does the Anchore Data Service work?

Anchore Data Service is designed for both robustness and flexibility. As well as catering to both internet-connected or fully air-gapped environments. The magic happens through a dedicated internal service which acts as the central hub for vulnerability data that you can download data from.

In an internet-connected deployment, your Anchore Enterprise deployment pulls data directly from Anchore Data Service, hosted at https://data.anchore-enterprise.com. You only need to allow outbound HTTPS traffic (TCP port 443) from your Anchore instance. The deployments data syncer service periodically reaches out to this endpoint and checks for new feed data. If it finds an update, it downloads and distributes it across your deployment.

For air-gapped deployments with no internet connectivity, Anchore provides a simple, secure mechanism for updating vulnerability data.  Using the command-line tool, anchorectl, on a low side/internet connected machine you can use the tool to download the entire vulnerability data feed as a single bundle. Then simply transfer, or sneaker copy, this bundle into your air-gapped network. Using a local copy of anchorectl in your high side environment you will upload the feed data. This gives you full control over the data flow while maintaining a strict air gap.

The data lifecycle: From publication to matching 

A question we often hear is, ‘When a newly discovered vulnerability is published, how does it and how long does it take to go from security advisory all the way to a finding in an image in your deployment?’ As with most questions in IT the answer is it depends…but the aim now is to go under the hood and look at the nuance as to how this works.

Let’s run through the steps so you can see how this works end to end.

Step 1: Anchore pulls upstream data from vendors and other sources, compiles and then publishes data to the hosted data syncer service. This happens every 6 hours. Our OSS tooling only published data every 24 hours. 

Step 2: The data syncer service in an Anchore Enterprise deployment runs every hour and checks the hosted Anchore Data Service for new vulnerability data.

Step 3: Once downloaded the data syncer service communicates with the Anchore Policy Engine and other internal components to update internal databases. This makes the new dataset, or set of feeds, available within your deployment.

With new data available to an Anchore Enterprise deployment, there are a few mechanics to understand how this new data will be utilized. For ad-hoc requests (web ui/api) for vulnerabilities on an artifact, the system returns the latest results. For example, if the SBOM shows log4j-core-2.14.0.jar, the policy engine searches the latest vulnerability data for any entries where log4j-core is the affected package and 2.14.0 falls within a vulnerable version range. When a match is found, a vulnerability is reported.

The importance of having a high quality SBOM cannot be underrated. If your SBOM is older it can be worth rescanning with the latest version of anchorectl/Syft to get improved SBOM quality and therefore results.

You need not re-scan an image as the SBOM stored acts as the reference point for mapping vulnerabilities. The reporting system by default will re-build the latest vulnerability data on a cycle timer ( anchoreConfig.reports_worker.cycle_timers.reports_image_load). The  default is set to update every 600 seconds. This is configurable if you require fresher reports. 

Finally, if you have a subscription watch for vulnerability data you can get notified of any changes to the vulnerability data. For example, if a user is subscribed to the library/nginx:latest tag and on the 12th of September 2025 a new vulnerability was added to the Debian 9 vulnerability feed which matched a package in the library/nginx:latest image, this would trigger a notification.

Notifications can be configured to hit a webhook, slack, email and/or other endpoints. This subscription will be checked on a cycle of every four hours but is also configurable (anchoreConfig.catalog.cycle_timers.vulnerability_scan). 

Note: the subscription is disabled by default. There are other similar subscriptions for policy and tags that might also play a role here. For example, if you want to notify on changes to policy results about a CVE (e.g., a CVE changes from unknown to critical).

The data lifecycle: Trust but verify…the feeds

As you can see at this point, the Anchore Data Service is critical to your deployment’s continued operation and due to this and the ever changing nature of upstream data, we provide the Anchore Data Service status page. This page offers real-time operational health of all our backend services, including the critical vulnerability data feeds, package information, and security advisories that your Anchore Enterprise instance relies on. 

If you ever suspect an issue with data synchronization or feed updates, this status page should be your first troubleshooting step. It allows you to immediately verify if Anchore is experiencing an outage or performing maintenance, saving your team valuable time in diagnosing whether an issue is local to your environment or an external upstream problem.

You can also easily verify the status of your vulnerability feeds in your own deployment using the anchorectl:

# See a list of all feeds and their last sync time
$ anchorectl system feeds list

# See a list of all feeds and their last sync time
$ anchorectl system feeds list

This command will show you each feed group (e.g., vulnerabilities, clamAV, nvdv2, ubuntu, etc.), the number of records, and when it was last updated. You can also login to the Anchore Enterprise Web UI with admin permissions and head to the System -> Health Page to see the feeds list and timestamps and other details like record count too.

When you see recent timestamps, you know the data is flowing correctly. Importantly each feed has its own timestamp representing the last time the service pulled data from the upstream source. If there has been no new data published upstream, this timestamp won’t be updated. The policy engine and relevant policy packs have a rule set defined to show a policy failure if upstream data is missing or not recently. The FedRAMP policy bundle will flag any instances where an evaluation is using data older than 48 hours old.

What’s in the data and why it matters

The Anchore Data Service distributes a few different types of datasets that can aid prioritizing in your remediation workflow. 

For Malware checks,  Anchore Enterprise utilizes ClamAV, which is disabled by default but can be enabled for all centralized image scans. This data is constantly updated and pulled from upstream ClamAv. Checks on your container image filesystem happen at scan time. This offers extra insight into your container images beyond pure vulnerabilities and as such we won’t dig much further into this here but certainly a strong signal to utilize when determining if your software is safe for production.

Another useful dataset is the Known Exploited Vulnerability (KEV), a dataset produced by CISA. It is a list of known exploited vulnerabilities; meaning if a CVE is actively being exploited in the wild, it will be on this list.

Finally there is the Exploit Prediction Scoring System (EPSS) dataset where you retrieve a score and a percentile rankings. These are based on modelled data and point to the chance of a CVE being exploited in the next 30 days.

Anchore Data Service maintains numerous vulnerability feeds upstream sources. Each entry includes some useful metadata and context, such as:

• Vulnerability Identifiers: CVE or other unique ID (e.g., GHSA ) as well as external data source URLs useful to act as guidance and/or reference.
• Severity Score: The CVSS 2 or 3 score and vectors, helping you prioritize what to fix first. We can also present secondary scores if needed too.
• Affected Type: The type of software/ecosystem the software resides in.
• Affected Package: The name of the software package or library.
• Affected Versions: The specific version or version range that is vulnerable.
• Fix Information: The version in which a fix is available.
• CPE, CPE23 and PURL: CPE, CPE 2.3 and PURL are the primary ways to “name” a piece of software so Anchore can find and match to known vulnerabilities. Both are used and each have strengths and weaknesses, but PURL can help get the most accurate matching. 
• Package path: Where is this package located? Don’t forget you might have multiple instances of the same software
• Feed/feed group: Which upstream data feed was used to match this CVE data. 

Utilizing this information can help matching as well as remediation. It’s the difference between results that just tell you “your container has Log4j” and one that tells you “your container is using log4j-core version 2.15, which is vulnerable to CVE-2021-45046 (GHSA-7rjr-3q55-vv33) with a critical severity 9, and a fix is available in version 2.16 and this fix has been available for 4 years“.

Beyond what is included in the OSS Grype vulnerability feeds, Anchore Enterprise offers additional feeds like Microsoft MSRC vulnerability data and exclusions. 

But wait there is more:

• Severity Score – Secondary CVSS: Anchore can now be configured to show the highest secondary CVSS score if the Primary NVD score has not been provided for a CVE. This becomes useful as some data might have two CNA’s upstream sources associated with the same package/vulnerability.
• Matched CPEs: This field contains a list of CPEs that were matched for the vulnerable package. It provides more context around how the vulnerability was identified. This extra data might help you understand the match Anchore used and identify any false positives.

During the scan, various attributes will be used from the SBOM package artifacts to match to the relevant vulnerability data. Depending on the ecosystem, the most important of these package attributes tend to be Package URL (purl) and/or Common Platform Enumeration (CPE).

The Anchore analyzer attempts to generate a best effort guess of the CPE candidates for a given package as well as the purl based on the metadata that is available at the time of analysis. For example, for Java packages, the manifest contains multiple different version specifications but sometimes stores erroneous version data. 

Luckily there are some processes to help facilitate better matching and get you the most accurate results:

• Enrichment: Due to the known issues with the NVD, Anchore Enterprise enhances the quality of its data for analysis by enriching the information obtained from the NVD. This process involves human intervention to review and correct the data. Once this manual process is completed, the cleaned and refined data is stored in the Anchore Enrichment Database.
• Vulnerability Match Exclusions. These exclusions allow us to remove a vulnerability from the findings for a specific set of match criteria.
• Correction & Hints: Anchore Enterprise provides the capability for you to adapt the SBOM and its contained packages but also provide a correction that will update a given package’s metadata so that attributes (including CPEs and Package URLs) can be corrected at the time that Anchore performs a vulnerability scan.
• Vendor Data First: We surface both NVD and vendor data, but recommend and by default, surface vendor-specific data first. They understand how a package of software has been compiled and installed and therefore the impact of a known vulnerability the best. They also have awareness of accurate fix information too. 

One of the most impactful features, recently released within the Anchore Enterprise ecosystem is the support for open standards VEX (Vulnerability Exploitability eXchange) and VDR (Vulnerability Disclosure Report). While these deserve a deep dive of their own, their core value is simple: they allow you to apply vulnerability annotations, like “this CVE is not applicable or code path not executed” or “investigating” directly to your SBOMs.

Not only this but you can soon also leverage VEX documents provided by upstream vendors like Red Hat if you used UBI9 base images that contained CVEs. Meaning you can eliminate noise and save significant manual triage time with confidence. Because Anchore Enterprise supports image ancestry and inheritance detection, these time savings multiply across every image in your environment. Furthermore, you can share these annotations with customers and auditors, streamlining their adoption and compliance process.

For some, simply being able to leverage a mix of data available like CVSS 2/3 or extract the PURL for downstream use cases is a must. Like matching and publishing discovered vulnerability matches and their data points into other systems like SIEM. In a larger enterprise, this helps to connect data systems, facilitate organizational automation and drive consistency across results from disparate systems.

A common example is that some compliance scenarios require NVD data specific results and whilst we lean on vendor data first, surfacing NVD results is absolutely available. Anchore Enterprise makes this simple and easy with 100% API coverage as well as a powerful notifications system providing rich exposure to the underlying data.

Summary

In vulnerability management, the “garbage in, garbage out” must be avoided as any tooling showing incomplete, outdated, or inaccurate data leads to false positives, missed threats, and wasted effort. In addition to this, having the ability to utilize additional data signals from other data sources like EPSS and KEV can truly assist your remediation and prioritization efforts in the face of the never ending wave of vulnerabilities.

This is why Anchore invests heavily in our vulnerability data feed. We do the relentless, complex work of ingesting, correlating, and curating data so you don’t have to. The result is a reliable, timely, and high-fidelity intelligence feed engineered to power your security operations, no matter your environment. By letting Anchore manage the data chaos, you gain confidence that your entire security posture is based on the latest intelligence. This allows your team to stop chasing data and focus on what matters: finding and fixing vulnerabilities.

Understand, Implement & Leverage SBOMs for Stronger Security & Risk Management

Download 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.

We generate a lot of tooling at Anchore. What started as a few focused utilities has grown into a suite of open source tools for software supply chain security: Syft for SBOM generation, Grype for vulnerability scanning, Grant for license compliance, … and more on the way.

For a while, we made do with putting all content into in-repo READMEs. The reality is, we’ve reached a new inflection point where there is simply too much rich tooling and content to reasonably cram into a handful of README files. We’re growing, we’re expanding, and we need a proper home to capture everything we’re building.

And so, we present the shiny new hub for documenting all things related to Anchore OSS: oss.anchore.com.

Why a separate site?

The short answer: there’s just too much to say.

Our tools have matured. They support dozens of package ecosystems and operating systems. They have configuration options that deserve proper explanation. Users have real workflows: generating SBOMs in CI, scanning container images, and building license compliance reports. All of these workflows deserve guides that walk a user through them properly.

We also wanted a place to share some of the thinking behind how we build things. What component analysis capabilities do we have for each language ecosystem? What’s our philosophy and conventions around building go tools? What are a set of really useful jq recipes when working with Syft JSON output? These are things that don’t fit neatly into a README but are genuinely useful if you’re trying to understand or contribute to the projects.

What you’ll find there

The site is organized around a few main areas:

User Guides cover the things you’re most likely trying to do: generate an SBOM, scan for vulnerabilities, check license compliance. These are task-oriented and walk you through real workflows.

Ecosystem and OS Coverage describes what we support and how. Different package managers and operating systems have their own quirks; this is where we document them.

Per-Tool Reference is where you’ll find the detailed stuff: CLI documentation, configuration file reference, JSON schema definitions. The kind of thing you need when you want to know every nook and cranny of what you can make the tools describe.

Architecture and Philosophy gets into the “why” and “how” behind the tools. How Syft catalogs packages, how Grype matches vulnerabilities, how we think about building Go utilities on the Anchore OSS team.

Contributing Guides are for folks who want to get involved. We’ve tried to lower the barrier to entry for new contributors.

This is where it all lives now

We’re not abandoning READMEs entirely. They’ll still point you in the right direction and cover installation basics. But for anything beyond “here’s how to install it and run a basic command,” oss.anchore.com is the place to find everything else.

The site codebase is open source like everything else we do. If you spot something wrong, something missing, or something confusing about the doc site itself; PRs are welcome. We’d love feedback on what’s helpful and what’s not.

Check it out at oss.anchore.com.

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.

Container image scanning has come a long way over the years, but it still comes with its own set of, often unique, challenges. One of these being the difficulty in analyzing images for vulnerabilities when they contain a Rust payload.

If you’re a big Rust user, you may have found that some software composition analysis (SCA) tools will struggle to report on known vulnerabilities found in your software dependencies. This is typical because these dependencies are not exposed in a consistent manner for cataloging and analysis.

In this blog post we’ll show you how to embed dependency information directly in your images, allowing you to get more accurate SBOM (software bill of materials) and vulnerability results. We’ll cover:

• Why Rust crates are hard to detect inside container images
• How Anchore Enterprise’s image and source catalogers work and can discover dependencies from both source and binary artifacts
• Why the rust-cargo-lock cataloger isn’t enabled for image scans by default
• And how you can use cargo-auditable to embed crate metadata and dependency information directly into your compiled binary — so scanners can pick up every dependency without bloating your image

Why Your Rust Containers Look Empty to Security Scanners and How to Fix It

Your Container Doesn’t Look Anything Like Your Source Tree

Most container scanners can’t see inside compiled Rust binaries because by the time the image is built, it will typically only contain the final compiled Rust binary. This means that all of Cargo’s dependency metadata (cargo.toml and cargo.lock) have already been stripped away. Because of this, your image just looks like one big executable to the scanner with no dependencies. The lock file is the authoritative record of exactly which crates and versions were used to resolve the dependency graph. Without the lock file, the scanner cannot figure out the actual crate versions used at build time.

Opaque, Static Rust Binaries

Rust produces optimized, statically linked binaries. These artifacts don’t naturally contain machine-readable metadata about dependency versions. Without explicit embedding, scanners must rely on things like file names, pattern-matching or trying to infer crate versions from panic messages. This is obviously a less than desirable approach.

Stripped Binaries and Minimal Images for Production

To keep production images lean, teams will often remove any build tools from which would otherwise cause too much extra bloat in the images thus making the image more susceptible to security issues. But from a visibility standpoint, doing this will also remove almost all of the useful metadata that a scanner can use to attempt to reverse-map a binary back to its dependency graph; especially on minimal base images.

Diversity in Deployment

Different teams structure Rust deployment images differently. Some bake the entire Rust toolchain into a single monolithic image; others copy in only the compiled binary. Due to how Syft does cataloging, the filesystem layout may affect crate detection unless the environment still somewhat resembles a Rust workspace.

Even if you do recover a cargo.lock file from somewhere, it may not reflect the binary actually running in production due to potential differences in things like timestamps, environment variables, build machines, etc. This can all potentially lead to non-matching dependency graphs. This highlights why it is important to ensure the dependency graph is included at build time.

How Anchore Enterprise Catalogs Software Components

Anchore Enterprise utilises a modular, cataloger-based approach (powered by its integration of Syft) when it comes to identifying software components for the SBOM. 

Each individual cataloger specializes in extracting package metadata from a specific ecosystem or filesystem structure. Understanding how Anchore Enterprise orchestrates these catalogers is crucial for correctly analyzing challenging artifacts, such as images with a Rust payload for security vulnerabilities.

Different Defaults for Image Scans vs. Source Scans

When scanning a container image, Syft assumes the image is an accurate representation of what is actuallyinstalled, not source code. As a result of this, many source-oriented catalogers such as the rust-cargo-lock-cataloger are disabled by default to avoid false positives. Syft provides the ability for the user to tell it to run additional catalogers that are not set by default for the target type. You can use syft --select-catalogers +rust-cargo-lock-cataloger <img> to run the non-image cataloger against the image by overriding the default behavior.

Image catalogers are optimized for installed package metadata: OS packages, Python wheels, Java archives, and so on. Unless explicitly instructed, Syft will not search for source layouts or lockfiles inside an image; production containers typically do not include them.

But when Syft scans a source code repository, it aggressively looks for manifest files like cargo.lock (Rust), package.json (NPM), gemfile.lock (Ruby). These are the files that reflect the developer’s intended dependency graph. When scanning a source repository Syft applies catalogers that assume a development environment. This includes the Rust lockfile parser, which is able to accurately capture crate version information. That is why scanning a Git repository produces richer Rust dependency data than scanning the image produced by that repository.

If you are only scanning container images and are interested in why you should be checking your source code repositories, be sure to check out our blog post: The Unseen Threat: Why You Need To Scan Your Source Code Repositories

Why Are Lockfile-Based Rust Catalogers Not Enabled for Image Scans?

Given the points mentioned above, hopefully it is starting to become a bit easier to understand why Syft does not run the cargo.lock cataloger during image scans by default. Even if a cargo.lock file exists inside an image, there is no guarantee that it still accurately reflects the binary that is inside the image. It could be outdated or leftover from an unrelated build step. Hence why the cataloger is disabled by default, as parsing a cargo.lock without being able to confirm the validity of it against the binary could lead to incorrect dependency graphs or false positives during the vulnerability scan. As previously mentioned, you can enable lockfile-based cataloging in Syft via the CLI but this will require careful consideration of what is actually contained in the image.

cargo-autidable: A Practical Breakthrough for Creating Complete Rust SBOMs

cargo-auditable addresses all of the challenges mentioned above by embedding dependency metadata directly into Rust binaries at build time. It extracts the full dependency graph and embeds it into a special linker section. The data is a compact, compressed JSON blob containing the crate names and versions. No paths, secrets or source is included, keeping the size overhead small, often to just a few kilobytes, even for large dependency graphs.

Because now using this tool the metadata is embedded into the binary itself, Syft (v1.15+) is able to automatically extract crate metadata and include it in the SBOM.

There is also now an adoption of tools similar to cargo-auditable across the different ecosystems that were previously struggling with the difficulties of metadata being stripped from container images.

Embedding the metadata/dependency graph ensures that scanners don’t need the cargo.lock file or source files, they can just simply inspect the binary itself. This is incredibly important moving forward with the security workflow of container images.

You can adopt auditable builds in two differing models:

1. CLI Wrapper Approach

Install cargo-auditable globally and run: cargo auditable build --release. This is ideal for CI pipelines and container builds.

2. Crate-Level Integration (build.rs)

Add auditable and auditable-build to cargo.toml, then invoke auditable::inject_dependency_list!() from build.rs or the application entrypoint. This doesn’t require installing any additional cargo plugins at runtime.

A Practical Multi-Stage Dockerfile for Auditable Rust Builds

To use rust-secure-code/cargo-auditable in a Rust build (example Dockerfile):

# Stage 1: Builder
FROM rust:1.75 as builder

WORKDIR /usr/src/app

# Copy Cargo.toml and Cargo.lock to leverage Docker's build cache
COPY Cargo.toml Cargo.lock ./

# Create a dummy src/main.rs to compile dependencies and cache them
RUN mkdir src && \
    echo "fn main() {println!(\"Preparing dependency cache...\")}" > src/main.rs && \
    cargo build --locked --release

# Remove the dummy src directory
RUN rm -rf src/

# Copy the actual source code
COPY . .

# Build the project with cargo-auditable
# Ensure cargo-auditable is installed or install it here if not in the base image
# RUN cargo install cargo-auditable # Uncomment if needed
RUN cargo auditable build --release

# Stage 2: Runtime
FROM debian:stable-slim

WORKDIR /app

# Copy the auditable binary from the builder stage
COPY --from=builder /usr/src/app/target/release/<your-binary-name> ./

CMD ["./<your-binary-name>"]# Stage 1: Builder
FROM rust:1.75 as builder

WORKDIR /usr/src/app

# Copy Cargo.toml and Cargo.lock to leverage Docker's build cache
COPY Cargo.toml Cargo.lock ./

# Create a dummy src/main.rs to compile dependencies and cache them
RUN mkdir src && \
    echo "fn main() {println!(\"Preparing dependency cache...\")}" > src/main.rs && \
    cargo build --locked --release

# Remove the dummy src directory
RUN rm -rf src/

# Copy the actual source code
COPY . .

# Build the project with cargo-auditable
# Ensure cargo-auditable is installed or install it here if not in the base image
RUN cargo install cargo-auditable
RUN cargo auditable build --release

# Stage 2: Runtime
FROM debian:stable-slim

WORKDIR /app

# Copy the auditable binary from the builder stage
COPY --from=builder /usr/src/app/target/release/<your-binary-name> ./

CMD ["./<your-binary-name>"]

# Stage 1: Builder
FROM rust:1.75 as builder

WORKDIR /usr/src/app

# Copy Cargo.toml and Cargo.lock to leverage Docker's build cache
COPY Cargo.toml Cargo.lock ./

# Create a dummy src/main.rs to compile dependencies and cache them
RUN mkdir src && \
    echo "fn main() {println!(\"Preparing dependency cache...\")}" > src/main.rs && \
    cargo build --locked --release

# Remove the dummy src directory
RUN rm -rf src/

# Copy the actual source code
COPY . .

# Build the project with cargo-auditable
# Ensure cargo-auditable is installed or install it here if not in the base image
# RUN cargo install cargo-auditable # Uncomment if needed
RUN cargo auditable build --release

# Stage 2: Runtime
FROM debian:stable-slim

WORKDIR /app

# Copy the auditable binary from the builder stage
COPY --from=builder /usr/src/app/target/release/<your-binary-name> ./

CMD ["./<your-binary-name>"]# Stage 1: Builder
FROM rust:1.75 as builder

WORKDIR /usr/src/app

# Copy Cargo.toml and Cargo.lock to leverage Docker's build cache
COPY Cargo.toml Cargo.lock ./

# Create a dummy src/main.rs to compile dependencies and cache them
RUN mkdir src && \
    echo "fn main() {println!(\"Preparing dependency cache...\")}" > src/main.rs && \
    cargo build --locked --release

# Remove the dummy src directory
RUN rm -rf src/

# Copy the actual source code
COPY . .

# Build the project with cargo-auditable
# Ensure cargo-auditable is installed or install it here if not in the base image
RUN cargo install cargo-auditable
RUN cargo auditable build --release

# Stage 2: Runtime
FROM debian:stable-slim

WORKDIR /app

# Copy the auditable binary from the builder stage
COPY --from=builder /usr/src/app/target/release/<your-binary-name> ./

CMD ["./<your-binary-name>"]

Enterprise production build pipelines need reproducible and minimal container images. The above Dockerfile integrates cargo-auditable cleanly into a multi-stage build, ensuring that:

• dependency metadata is embedded,
• the final runtime image is minimal, and
• SBOM tools can extract an accurate crate inventory list.

Seamless SBOM Generation and Analysis with Anchore Enterprise

Using the Dockerfile above as a template, you can build your image (e.g vulnerable-rust-app:latest). Whether the image resides locally or in a container registry, it can be submitted to Anchore Enterprise for SBOM generation and analysis. Because we have used cargo-auditable in the build process, the resulting binary contains embedded audit metadata. Anchore Enterprise, using Syft under the hood, automatically extracts this data to produce an accurate SBOM; including all of the Rust crates used.

$ docker build -t vulnerable-rust-app .
[+] Building 27.1s (19/19) FINISHED                              docker:default
....

$ docker build -t vulnerable-rust-app .
[+] Building 27.1s (19/19) FINISHED                              docker:default
....

Next, we add the image to Anchore Enterprise using anchorectl. During this step, Anchore Enterprise invokes Syft under the hood to generate the SBOM automatically and submit it to the Enterprise services for analysis. Here is what you would see in your terminal:

$ anchorectl image add vulnerable-rust-app --from docker
 ✔ Added Image                                                                                                 vulnerable-rust-app 
 ✔ Imported SBOM                             [adding image]                                                                 docker 
Image:
  status:           not-analyzed (active)
  tag:              docker.io/vulnerable-rust-app:latest
  digest:           sha256:0a4036b071e649ad1b88ad775c6dc77ad6c08c5c6684d88c7c72468e99682f87
  id:               e758d26d9a9d0dc1fa94d4ee15842f424e649ec3e8a2028486845b9ee9f05edd

$ anchorectl image add vulnerable-rust-app --from docker
 ✔ Added Image                                                                                                 vulnerable-rust-app 
 ✔ Imported SBOM                             [adding image]                                                                 docker 
Image:
  status:           not-analyzed (active)
  tag:              docker.io/vulnerable-rust-app:latest
  digest:           sha256:0a4036b071e649ad1b88ad775c6dc77ad6c08c5c6684d88c7c72468e99682f87
  id:               e758d26d9a9d0dc1fa94d4ee15842f424e649ec3e8a2028486845b9ee9f05edd

Using anchorectl we can now inspect the contents of the image and filter specifically for rust-crates. Anchore Enterprise correctly and successfully identifies each of the crates that I added into this particular image via the Dockerfile, due to cargo-auditable embedding the metadata into the image.

$ anchorectl image content docker.io/vulnerable-rust-app:latest --type rust-crate
 ✔ Fetched content                           [7 packages] [0 files]                                         docker.io/vulnerable-rust-app:latest 
Packages:
┌─────────────────────┬─────────┬────────────┬──────┬────────┬──────────────────────────┐
│ PACKAGE             │ VERSION │ TYPE       │ SIZE │ ORIGIN │ LOCATION                 │
├─────────────────────┼─────────┼────────────┼──────┼────────┼──────────────────────────┤
│ bytes               │ 0.5.6   │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ lazy_static         │ 1.5.0   │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ pin-project-lite    │ 0.1.12  │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ serde               │ 1.0.228 │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ serde_core          │ 1.0.228 │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ tokio               │ 0.2.25  │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ vulnerable-rust-app │ 0.1.0   │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
└─────────────────────┴─────────┴────────────┴──────┴────────┴──────────────────────────┘

$ anchorectl image content docker.io/vulnerable-rust-app:latest --type rust-crate
 ✔ Fetched content                           [7 packages] [0 files]                                         docker.io/vulnerable-rust-app:latest 
Packages:
┌─────────────────────┬─────────┬────────────┬──────┬────────┬──────────────────────────┐
│ PACKAGE             │ VERSION │ TYPE       │ SIZE │ ORIGIN │ LOCATION                 │
├─────────────────────┼─────────┼────────────┼──────┼────────┼──────────────────────────┤
│ bytes               │ 0.5.6   │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ lazy_static         │ 1.5.0   │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ pin-project-lite    │ 0.1.12  │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ serde               │ 1.0.228 │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ serde_core          │ 1.0.228 │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ tokio               │ 0.2.25  │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
│ vulnerable-rust-app │ 0.1.0   │ RUST-CRATE │      │ N/A    │ /app/vulnerable-rust-app │
└─────────────────────┴─────────┴────────────┴──────┴────────┴──────────────────────────┘

Here is what you would see in the Anchore Enterprise dashboard:

Finally, we review the vulnerability analysis results. In this example, the image contains one high-severity vulnerability and two low-severity vulnerabilities affecting the tokio crate.

$ anchorectl image vuln docker.io/vulnerable-rust-app:latest --type non-os
 ✔ Fetched vulnerabilities                   [3 vulnerabilities]                                            docker.io/vulnerable-rust-app:latest 
┌─────────────────────┬──────────┬───────┬─────────┬────────┬──────────────┬────────────┬─────────────┬───────┬────────────────┬───────────────────────────────────────────────────┬───────────────────┐
│ ID                  │ SEVERITY │ NAME  │ VERSION │ FIX    │ WILL NOT FIX │ TYPE       │ FEED GROUP  │ KEV   │ CVES           │ URL                                               │ ANNOTATION STATUS │
├─────────────────────┼──────────┼───────┼─────────┼────────┼──────────────┼────────────┼─────────────┼───────┼────────────────┼───────────────────────────────────────────────────┼───────────────────┤
│ GHSA-fg7r-2g4j-5cgr │ High     │ tokio │ 0.2.25  │ 1.8.4  │ false        │ rust-crate │ github:rust │ false │ CVE-2021-45710 │ https://github.com/advisories/GHSA-fg7r-2g4j-5cgr │                   │
│ GHSA-rr8g-9fpq-6wmg │ Low      │ tokio │ 0.2.25  │ 1.38.2 │ false        │ rust-crate │ github:rust │ false │                │ https://github.com/advisories/GHSA-rr8g-9fpq-6wmg │                   │
│ GHSA-4q83-7cq4-p6wg │ Low      │ tokio │ 0.2.25  │ 1.18.5 │ false        │ rust-crate │ github:rust │ false │                │ https://github.com/advisories/GHSA-4q83-7cq4-p6wg │                   │
└─────────────────────┴──────────┴───────┴─────────┴────────┴──────────────┴────────────┴─────────────┴───────┴────────────────┴───────────────────────────────────────────────────┴───────────────────┘

$ anchorectl image vuln docker.io/vulnerable-rust-app:latest --type non-os
 ✔ Fetched vulnerabilities                   [3 vulnerabilities]                                            docker.io/vulnerable-rust-app:latest 
┌─────────────────────┬──────────┬───────┬─────────┬────────┬──────────────┬────────────┬─────────────┬───────┬────────────────┬───────────────────────────────────────────────────┬───────────────────┐
│ ID                  │ SEVERITY │ NAME  │ VERSION │ FIX    │ WILL NOT FIX │ TYPE       │ FEED GROUP  │ KEV   │ CVES           │ URL                                               │ ANNOTATION STATUS │
├─────────────────────┼──────────┼───────┼─────────┼────────┼──────────────┼────────────┼─────────────┼───────┼────────────────┼───────────────────────────────────────────────────┼───────────────────┤
│ GHSA-fg7r-2g4j-5cgr │ High     │ tokio │ 0.2.25  │ 1.8.4  │ false        │ rust-crate │ github:rust │ false │ CVE-2021-45710 │ https://github.com/advisories/GHSA-fg7r-2g4j-5cgr │                   │
│ GHSA-rr8g-9fpq-6wmg │ Low      │ tokio │ 0.2.25  │ 1.38.2 │ false        │ rust-crate │ github:rust │ false │                │ https://github.com/advisories/GHSA-rr8g-9fpq-6wmg │                   │
│ GHSA-4q83-7cq4-p6wg │ Low      │ tokio │ 0.2.25  │ 1.18.5 │ false        │ rust-crate │ github:rust │ false │                │ https://github.com/advisories/GHSA-4q83-7cq4-p6wg │                   │
└─────────────────────┴──────────┴───────┴─────────┴────────┴──────────────┴────────────┴─────────────┴───────┴────────────────┴───────────────────────────────────────────────────┴───────────────────┘

This can also be viewed in the UI.

Wrap-up

As we’ve seen, securing Rust crates in container images presents unique challenges, but not insurmountable ones. By integrating cargo-auditable into your build process, you ensure that your production binaries carry their own source of truth. This enables accurate SBOM generation and vulnerability detection without compromising on image size or performance.

Don’t let your Rust containers remain a blind spot in your security posture. With Anchore Enterprise, you can automatically leverage this embedded metadata to gain complete visibility into your software supply chain, ensuring that what you build is exactly what you secure.

Ready to see what you’ve been missing? Request a demo of Anchore Enterprise today.

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

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

There’s a saying I use often, usually as a joke, but it’s often painfully true. Past me hates future me. What I mean by that is it seems the person I used to be keeps making choices that annoy the person I am now. The best example is booking that 5am flight, what was I thinking? But while I mean this mostly as a joke, we often don’t do things today that could benefit us in the future. What if we can do things that benefit us now, and in the future. Let’s talk about supply chain security in this context.

The world of supply chain security is more complicated and hard to understand than it’s ever been. There used to be a major supply chain attack or bug every couple of years. Now it seems like we see them every couple of weeks. In the past it was easy for us to mostly ignore long term supply chain problems because it was a problem for our future selves. We can’t really do that anymore, supply chain problems are something that affect present us, and future us. Also past us, but nobody likes them!

There are countless opinions on how to fix our supply chain problems. Everything from “it’s fine” to “ban all open source”. But there is one common thread every possible option has, and that’s understanding what software is in your supply chain. And when we say “software in your supply chain” we really mean all the open source you’re using. So how do we track all the open source we’re using? There are many opinions around this question, but the honest reality at this point is SBOMs (Software Bills of Material) won. So what does this have to do with us in the future?

Let’s tie all the pieces together now. We have a ton of open source. We have all these SBOMs, and we have a supply chain attack that’s going to affect future us. But not the distant future us, it’s the future us in a few weeks. It’s also possible we’re still in the middle of dealing with the last attack.

How does an inventory of our software help with future supply chain attacks?

When any sort of widespread incident happens in the world of security, the first question to ask is “am I affected” I have a blog post I wrote after one of the recent NPM incidents. A Zero-day Incident Response Story from the Watchers on the Wall. I can’t even remember where exactly it falls in the timeline of recent NPM attacks, there have been so many of these things. Most modern infrastructure is pretty complex. Asking the question “am I affected” isn’t as simple as it sounds.

If you have a container image, or a zip file, or a virtual machine that’s running your infrastructure, how do you even start to understand what’s inside? You might dig around and look for a specific filename, maybe something like “log4j.jar”. Sometimes looking for a certain file will work, sometimes it won’t. Did you know JAR files can be inside other JAR files? Now the problem is a lot harder.

It’s also worth noting that if you’re in the middle of a supply chain event, finding all your software and decompressing it isn’t a great use of time. It’s slow and a very error prone task. If you have thousands of artifacts to get through, that’s not going to happen quickly. When we’re in the middle of a security incident, we need the ability to move quickly and answer questions that come up as we learn more details.

Was I ever affected?

Let’s assume you figured out if you are, or aren’t, affected by a supply chain attack, the next question might be “was I ever affected?” Some supply chain problems don’t need a look back in time, but some do. If the problem was a single version of a malicious package that’s 6 hours old, you might not need an inventory of every version of every artifact ever deployed. But one of the challenges we have with these supply chain problems is we don’t know what’s going to happen next. If we need to know every version of every artifact that was deployed for the last two years, can most of us even answer that question?

It’s likely you’re not keeping artifacts laying around. They’re pretty big, but even if you don’t care about space, it can be really hard to keep track of everything. If you deploy once a day, and you have 20 services, that’s a lot of container images. Rather than keep the actual artifacts around taking up space, we can store just the metadata from those artifacts.

How can SBOMs help with this? SBOMs are just documents. One document per artifact. There are SBOM management systems that can help wrangle all these documents. While we’ve not yet solved the problem of storing a large number of software artifacts easily and efficiently. We have solved the problem of storing a large number of structured documents and making the data searchable.

The searchable angle is a pretty big deal. Even if you do have millions of stored container images, good luck searching through those. If you have a store of all your SBOMs, which would represent all the software you currently and have ever cared about, searching through that data is extremely fast and easy. We know how to search through structured data.

Next steps

Keep in mind that generating and collecting SBOMs is just the first step in a supply chain journey. But no journey can start without the first step. It’s also never been easier to start creating and storing SBOMs. We can benefit from the data right now. There’s a paper from the OpenSSF titled Improving Risk Management Decisions with SBOM Data that captures many of these use cases.

Fundamentally it’s an investment for our future selves who will need to know what all the software components are. It’s common for most solutions to either help present us or future us, but not both. When we start using an SBOM, why not both?

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

Here’s an uncomfortable truth: if you’re only scanning container images, you’re missing a key aspect of your security vulnerabilities. While container scanning is valuable for checking packaged dependencies and OS components which in itself cannot be understated, it’s not necessarily aware of the custom code vulnerabilities that attackers exploit in real-world breaches.

Think of it this way—container scanning checks whether your ingredients are fresh, but it can’t tell if your recipe is poisoned. And in today’s threat landscape, attackers are poisoning the recipe.

What Container Scanning Can’t See

Container scanners analyze built images after compilation—comparing package versions against CVE databases. They’re excellent at finding known vulnerabilities in third-party components. But, it’s not intrinsically geared towards detecting the vulnerabilities in your code.

Once your application code has been compiled into binaries, the scanner has little to no visibility into how that code actually works. It can’t analyze logic flows, trace data paths, or understand business rules.

What does this mean in practice? Container scanners are not designed to surface:

• Broken authentication mechanisms that let attackers bypass login
• Business logic flaws that allow transaction manipulation
• Authorization weaknesses enabling privilege escalation

These represent several of the OWASP Top 10 vulnerability categories which necessitate the need for organizations to also adopt source code scanning as part of their overall security posture.

Real Breaches That Prove the Point

Some of the most well known security incidents of recent years all share something in common: they succeeded because organizations relied on container scanning solely instead of a holistic approach which also incorporated source code scanning.

SolarWinds (2020) remains the textbook case. Russian state-sponsored attackers deployed malware on SolarWinds build servers that surgically modified source code during compilation. The malicious code was compiled, signed with valid certificates, and distributed to 18,000+ organizations including multiple U.S. federal agencies. 

CodeCov (2021) demonstrates supply chain risk at the source level. Attackers modified the Bash uploader script that thousands of developers ran in their CI/CD pipelines, silently exfiltrating environment variables, API keys, and credentials for over two months. Organizations including HashiCorp and hundreds of others were compromised. 

Log4Shell (2021) affected hundreds of millions of devices with a critical severity rating. The vulnerability was a missing input validation check in Apache Log4j source code that existed for eight years before discovery. Static analysis tools are specifically designed to catch input validation failures—but you have to scan the source code, not just containers.

The Timing Problem

Container scanning happens after code is compiled. By the time you scan a container image, package installation scripts have already been executed with full developer privileges—potentially accessing secrets, modifying files, or establishing persistence.

Modern package managers (npm, pip, Maven) automatically run code during installation. These scripts execute before build time, before containerization, before any scanner examines the result. If a malicious package or compromised dependency runs code during installation, container scanning only may not see it.

This is why supply chain attacks increasingly target upstream dependencies. Over 512,000 malicious packages were identified in 2024—a 156% year-over-year increase. These attacks exploit the blind spot between source code and containers.

The Solution: Dual-Layer Security

Stop treating source code scanning and container scanning as alternatives. They’re complementary layers that catch different problems at different stages. You need both.

This is exactly the approach Anchore has built: scan early at the source code level, then scan again when you build containers. It’s not redundant—it’s smart defense that covers both angles.

What Anchore’s Container Scanning Catches

Anchore’s container scanning goes deep. Using three core tools—Syft for building a software bill of materials (SBOM – a formal inventory of all the components, libraries, and dependencies that make up a piece of software), Grype for finding vulnerabilities, and Anchore Enterprise for managing it all—the platform examines every layer of your container images.

This means more than just checking package versions. The scanner looks at operating system packages, application dependencies, nested archives (like JARs inside WARs), and even scans file contents for exposed secrets, and malware signatures.

The vulnerability database draws from over 15 authoritative sources including the National Vulnerability Database, GitHub Security Advisories, and vendor-specific security data. But, Anchore doesn’t just dump a list of CVEs at you. It prioritizes risks using CVSS severity scores, EPSS (which predicts exploitation likelihood), and CISA’s list of actively exploited vulnerabilities.

What really matters: you get focused on what’s actually dangerous, not just what’s technically vulnerable.

What Anchore’s Source Code Scanning Catches

Here’s where Anchore differs from traditional static analysis tools. Instead of analyzing your custom application code for logic flaws, Anchore focuses on Software Composition Analysis (SCA)—identifying vulnerabilities in the open source dependencies you’re pulling into your projects.

The scanner reads your package manifest files (package.json, requirements.txt, pom.xml, go.mod—you name it) and checks both direct and transitive dependencies without needing to compile anything. It supports over 40 programming language ecosystems from C++ and Java to Rust and Swift.

The secrets detection capability scans both source repositories and built containers for exposed credentials: AWS keys, database passwords, API tokens, SSH keys. When it finds them, you can automatically block builds or deployments.

The key limitation: Anchore won’t catch SQL injection, cross-site scripting, or business logic flaws in your custom code. For that, you still need traditional SAST tools. Anchore’s documentation explicitly says to use both.

Why Both Layers Matter

The reality is that containers bring in way more than your application code. Base images, system libraries, runtime environments—all of these can introduce vulnerabilities that don’t exist in your source code.

At the source level, you catch vulnerable dependencies early when they’re cheap to fix. But, you’ll miss OS-level vulnerabilities, runtime environment risks, and problems introduced during the build process itself.

At the container level, you see the complete picture of what’s actually deploying to Production—but by then, you’ve already spent time and resources building the image. Finding problems at this stage costs more to fix.

Real examples make this concrete:

Container scanning catches:

• Critical vulnerabilities in Alpine’s package manager or OpenSSL libraries
• Log4j vulnerabilities buried deep in nested JAR dependencies
• Malware injected through compromised base images

Source code scanning catches:

• Vulnerable npm packages declared in package.json before they’re even installed
• Exposed secrets in configuration files before they reach version control
• Problematic open source licenses that could create legal issues

The two approaches complement each other and a real-world use case would be scanning a source code repository for open source licensure compliance or vulnerabilities in open source dependencies in the source code check-in stage of the build pipeline prior to an artifact (JAR, WAR, container image, etc.) being built, tested (unit, integration, automation, etc.), stored (within an artifact repository/container registry), and ultimately deployed.

One approach doesn’t also have to be done at the expense of the other as they are interchangeable with no co-dependencies. For instance, if an organization was already leveraging a traditional SAST tool for source code scanning, Anchore could then solely be utilized for container scanning within the build pipeline.

How It Works

Anchore integrates with the tools you’re already using. GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps, CircleCI—there are native integrations for all of them.

You can run source code scanning in distributed mode as described below which will work with any CI/CD system as long as the AnchoreCTL binary can be installed and run, or you can access the Enterprise APIs directly .

• Distributed mode: Generate SBOMs locally and send them to Anchore for analysis

AnchoreCTL is published as a simple binary available for download either from the Anchore Enterprise deployment or Anchore’s release site.

Using AnchoreCTL, you can manage and inspect all aspects of an Anchore Enterprise deployment, either as a manual control tool or as a CLI that is designed to be used in scripted environments such as CI/CD and other automation environments.

The platform’s policy engine lets you define security gates that automatically block non-compliant code/images from deploying. Pre-built policy bundles cover FedRAMP, NIST, DISA STIG, and other compliance frameworks, or you can write custom policies in JSON.

One unique capability: continuous monitoring through stored SBOMs. When a new zero-day vulnerability like Log4Shell emerges, you can instantly query your SBOM repository to find all affected systems—no rescanning required.

Example:

In the below example, we’ll generate an SBOM from a source code repository and then analyze (for vulnerabilities) and import the resultant SBOM into an Anchore Enterprise deployment as part of a versioned application source code artifact. 

AnchoreCTL is also being leveraged in distributed mode which could be automated by adding the steps to a CI/CD pipeline script.

1) Add a name for the application into Anchore Enterprise which will be mapped to the source code repository.

user@system:~# anchorectl application add k8s-inventory
 
 ✔ Added application                                                                                                                                                                 
Name: k8s-inventory
ID: 034b879d-5747-4deb-b29e-dc559d73fd03
Description: 
Versions: 

user@system:~# anchorectl application add k8s-inventory
 
 ✔ Added application                                                                                                                                                                 
Name: k8s-inventory
ID: 034b879d-5747-4deb-b29e-dc559d73fd03
Description: 
Versions: 

2) Add an application version that will be associated as a source code artifact.  

user@system:~# anchorectl application version add k8s-inventory@v1.0.0

 ✔ Added version                                                                                                                                                                     
Version Name: v1.0.0
ID: 1186e645-7309-499b-8ca1-82f557710152
Application ID: 034b879d-5747-4deb-b29e-dc559d73fd03
Created At: 2025-11-04T15:15:28Z
Last Updated: 2025-11-04T15:15:28Z

user@system:~# anchorectl application version add [email protected]

 ✔ Added version                                                                                                                                                                     
Version Name: v1.0.0
ID: 1186e645-7309-499b-8ca1-82f557710152
Application ID: 034b879d-5747-4deb-b29e-dc559d73fd03
Created At: 2025-11-04T15:15:28Z
Last Updated: 2025-11-04T15:15:28Z

3) Generate the SBOM from the source code repository, perform analysis, and import the resultant SBOM. The source code artifact association ([email protected]) is also being done during this step with the “–application” flag.

NOTE: The source code artifact comes into play with continuous integration to track the latest code changes for a given application version.

user@system:~# anchorectl syft scan --source-name k8s-inventory --source-version v1.0.0 -o json . | anchorectl source add github.com/anchore/k8s-inventory/latest@v1.0.0 --application "k8s-inventory@v1.0.0" --branch main --wait --from -
 
 ✔ Indexed file system                                                                                                                                                              
 ✔ Cataloged contents                                                                                               248991163569816cb202a8b2db755470b3c2c35e9e2027c694d3fa07d716e76e 
   ├── ✔ Packages                        [428 packages]  
   ├── ✔ Executables                     [2 executables]  
   ├── ✔ File digests                    [2 files]  
   └── ✔ File metadata                   [2 locations]  
Source:
  status:          analyzed (active)
  uuid:            eeab0c4a-95c4-4d10-9b3c-e5b754693cdb
  source:          github.com/anchore/k8s-inventory/latest@v1.0.0
  vcs:             git
  branch:          main

user@system:~# anchorectl syft scan --source-name k8s-inventory --source-version v1.0.0 -o json . | anchorectl source add github.com/anchore/k8s-inventory/[email protected] --application "[email protected]" --branch main --wait --from -
 
 ✔ Indexed file system                                                                                                                                                              
 ✔ Cataloged contents                                                                                               248991163569816cb202a8b2db755470b3c2c35e9e2027c694d3fa07d716e76e 
   ├── ✔ Packages                        [428 packages]  
   ├── ✔ Executables                     [2 executables]  
   ├── ✔ File digests                    [2 files]  
   └── ✔ File metadata                   [2 locations]  
Source:
  status:          analyzed (active)
  uuid:            eeab0c4a-95c4-4d10-9b3c-e5b754693cdb
  source:          github.com/anchore/k8s-inventory/[email protected]
  vcs:             git
  branch:          main

4) Check to make sure the source code repository is known to Anchore Enterprise and analysis has occurred.

user@system:~# anchorectl source list
 
 ✔ Fetched sources                                                                                                                                                                   
┌──────────────────────────────────────┬────────────┬──────────────────────────────┬──────────┬─────────────────┬───────────────┐
│ UUID                                 │ HOST       │ REPOSITORY                   │ REVISION │ ANALYSIS STATUS │ SOURCE STATUS │
├──────────────────────────────────────┼────────────┼──────────────────────────────┼──────────┼─────────────────┼───────────────┤
│ eeab0c4a-95c4-4d10-9b3c-e5b754693cdb │ github.com │ anchore/k8s-inventory/latest │ v1.0.0   │ analyzed        │ active        │
└──────────────────────────────────────┴────────────┴──────────────────────────────┴──────────┴─────────────────┴───────────────┘

user@system:~# anchorectl source list
 
 ✔ Fetched sources                                                                                                                                                                   
┌──────────────────────────────────────┬────────────┬──────────────────────────────┬──────────┬─────────────────┬───────────────┐
│ UUID                                 │ HOST       │ REPOSITORY                   │ REVISION │ ANALYSIS STATUS │ SOURCE STATUS │
├──────────────────────────────────────┼────────────┼──────────────────────────────┼──────────┼─────────────────┼───────────────┤
│ eeab0c4a-95c4-4d10-9b3c-e5b754693cdb │ github.com │ anchore/k8s-inventory/latest │ v1.0.0   │ analyzed        │ active        │
└──────────────────────────────────────┴────────────┴──────────────────────────────┴──────────┴─────────────────┴───────────────┘

5) Check to make sure the source code artifact is known to Anchore Enterprise.

user@system:~# anchorectl application artifact list k8s-inventory@v1.0.0

 ✔ List artifacts                                                                                                                                                                    
┌─────────────────────────────────────────┬────────┬────────┐
│ DESCRIPTION                             │ TYPE   │ HASH   │
├─────────────────────────────────────────┼────────┼────────┤
│ github.com/anchore/k8s-inventory/latest │ source │ v1.0.0 │
└─────────────────────────────────────────┴────────┴────────┘

user@system:~# anchorectl application artifact list [email protected]

 ✔ List artifacts                                                                                                                                                                    
┌─────────────────────────────────────────┬────────┬────────┐
│ DESCRIPTION                             │ TYPE   │ HASH   │
├─────────────────────────────────────────┼────────┼────────┤
│ github.com/anchore/k8s-inventory/latest │ source │ v1.0.0 │
└─────────────────────────────────────────┴────────┴────────┘

6) Although not a focal point for this post, the source code repository/artifact can also be verified via the Anchore Enterprise UI. Reference below documentation for further information on functionality via the UI.

NOTE: Work with Applications Generated from Source Repositories

NOTE: The “UUID” from Step 3 or 4 would be needed as an argument for the below steps.

7) Gather the imported/source SBOM (if needed/required).

user@system:~# anchorectl source sbom eeab0c4a-95c4-4d10-9b3c-e5b754693cdb -f /tmp/sbom.json
 
 ✔ Fetched SBOM

user@system:~# anchorectl source sbom eeab0c4a-95c4-4d10-9b3c-e5b754693cdb -f /tmp/sbom.json
 
 ✔ Fetched SBOM

8) Gather the vulnerabilities from the analysis.

user@system:~# anchorectl source vulnerabilities eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
 
 ✔ Fetched vulnerabilities                   [42 vulnerabilities]                                                                               eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
┌─────────────────────┬──────────┬─────────────────────────────────────┬──────────┬───────────────────────────────┬──────────────┬──────┬────────────┬───────┬────────────────┬───────────────────────────────────────────────────┐
│ ID                  │ SEVERITY │ NAME                                │ VERSION  │ FIX                           │ WILL NOT FIX │ TYPE │ FEED GROUP │ KEV   │ CVES           │ URL                                               │
├─────────────────────┼──────────┼─────────────────────────────────────┼──────────┼───────────────────────────────┼──────────────┼──────┼────────────┼───────┼────────────────┼───────────────────────────────────────────────────┤
│ CVE-2025-58187      │ High     │ stdlib                              │ go1.24.2 │ 1.24.9,1.25.3                 │ false        │ go   │ nvd        │ false │ CVE-2025-58187 │ https://nvd.nist.gov/vuln/detail/CVE-2025-58187   │
│ GHSA-fv92-fjc5-jj9h │ Medium   │ github.com/go-viper/mapstructure/v2 │ v2.2.1   │ 2.3.0                         │ false        │ go   │ github:go  │ false │                │ https://github.com/advisories/GHSA-fv92-fjc5-jj9h │
│ CVE-2025-61723      │ High     │ stdlib                              │ go1.24.2 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-61723 │ https://nvd.nist.gov/vuln/detail/CVE-2025-61723   │
│ CVE-2025-47906      │ Medium   │ stdlib                              │ go1.24.3 │ 1.23.12,1.24.6                │ false        │ go   │ nvd        │ false │ CVE-2025-47906 │ https://nvd.nist.gov/vuln/detail/CVE-2025-47906   │
│ GHSA-vvgc-356p-c3xw │ Medium   │ golang.org/x/net                    │ v0.37.0  │ 0.38.0                        │ false        │ go   │ github:go  │ false │ CVE-2025-22872 │ https://github.com/advisories/GHSA-vvgc-356p-c3xw │
│ CVE-2025-58183      │ Medium   │ stdlib                              │ go1.24.3 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-58183 │ https://nvd.nist.gov/vuln/detail/CVE-2025-58183   │
│ CVE-2025-61725      │ High     │ stdlib                              │ go1.24.2 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-61725 │ https://nvd.nist.gov/vuln/detail/CVE-2025-61725   │
│ CVE-2025-58188      │ High     │ stdlib                              │ go1.24.3 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-58188 │ https://nvd.nist.gov/vuln/detail/CVE-2025-58188   │

user@system:~# anchorectl source vulnerabilities eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
 
 ✔ Fetched vulnerabilities                   [42 vulnerabilities]                                                                               eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
┌─────────────────────┬──────────┬─────────────────────────────────────┬──────────┬───────────────────────────────┬──────────────┬──────┬────────────┬───────┬────────────────┬───────────────────────────────────────────────────┐
│ ID                  │ SEVERITY │ NAME                                │ VERSION  │ FIX                           │ WILL NOT FIX │ TYPE │ FEED GROUP │ KEV   │ CVES           │ URL                                               │
├─────────────────────┼──────────┼─────────────────────────────────────┼──────────┼───────────────────────────────┼──────────────┼──────┼────────────┼───────┼────────────────┼───────────────────────────────────────────────────┤
│ CVE-2025-58187      │ High     │ stdlib                              │ go1.24.2 │ 1.24.9,1.25.3                 │ false        │ go   │ nvd        │ false │ CVE-2025-58187 │ https://nvd.nist.gov/vuln/detail/CVE-2025-58187   │
│ GHSA-fv92-fjc5-jj9h │ Medium   │ github.com/go-viper/mapstructure/v2 │ v2.2.1   │ 2.3.0                         │ false        │ go   │ github:go  │ false │                │ https://github.com/advisories/GHSA-fv92-fjc5-jj9h │
│ CVE-2025-61723      │ High     │ stdlib                              │ go1.24.2 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-61723 │ https://nvd.nist.gov/vuln/detail/CVE-2025-61723   │
│ CVE-2025-47906      │ Medium   │ stdlib                              │ go1.24.3 │ 1.23.12,1.24.6                │ false        │ go   │ nvd        │ false │ CVE-2025-47906 │ https://nvd.nist.gov/vuln/detail/CVE-2025-47906   │
│ GHSA-vvgc-356p-c3xw │ Medium   │ golang.org/x/net                    │ v0.37.0  │ 0.38.0                        │ false        │ go   │ github:go  │ false │ CVE-2025-22872 │ https://github.com/advisories/GHSA-vvgc-356p-c3xw │
│ CVE-2025-58183      │ Medium   │ stdlib                              │ go1.24.3 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-58183 │ https://nvd.nist.gov/vuln/detail/CVE-2025-58183   │
│ CVE-2025-61725      │ High     │ stdlib                              │ go1.24.2 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-61725 │ https://nvd.nist.gov/vuln/detail/CVE-2025-61725   │
│ CVE-2025-58188      │ High     │ stdlib                              │ go1.24.3 │ 1.24.8,1.25.2                 │ false        │ go   │ nvd        │ false │ CVE-2025-58188 │ https://nvd.nist.gov/vuln/detail/CVE-2025-58188   │

9) Perform a policy evaluation.

user@system:~# anchorectl source check eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
 
 ✔ Evaluated against policy                  [passed]                                                                                           eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
Evaluation ID: f406016067fa4b7b529d519253cbed52
Source ID: eeab0c4a-95c4-4d10-9b3c-e5b754693cdb
Host: github.com
Repository: anchore/k8s-inventory/latest
Revision: v1.0.0
Policy ID: anchore_secure_default
Updated: 2025-11-04T15:44:22Z
Evaluation: warn
Number of Findings: 42

user@system:~# anchorectl source check eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
 
 ✔ Evaluated against policy                  [passed]                                                                                           eeab0c4a-95c4-4d10-9b3c-e5b754693cdb 
Evaluation ID: f406016067fa4b7b529d519253cbed52
Source ID: eeab0c4a-95c4-4d10-9b3c-e5b754693cdb
Host: github.com
Repository: anchore/k8s-inventory/latest
Revision: v1.0.0
Policy ID: anchore_secure_default
Updated: 2025-11-04T15:44:22Z
Evaluation: warn
Number of Findings: 42

That’s it…

The Bottom Line

Modern applications aren’t just your code. They’re a complex stack of dependencies, libraries, system packages, and runtime environments. Security at just one layer leaves gaps.

Anchore’s dual approach—SCA and secrets detection at the source level, comprehensive container scanning for built images—gives you visibility across the entire software supply chain. From a developer’s first commit to production runtime, you’re covered.

Organizations using this approach see 75-80% reductions in vulnerability management time and deploy 50-70% faster. More importantly, they ship secure software with confidence.

Container scanning protects against known vulnerabilities in dependencies. Source code scanning protects against the unknown vulnerabilities that attackers actually exploit. Source code scanning and container scanning aren’t competing strategies—they’re layers that work in tandem to provide the complete picture you need.

If you’ve been in the security universe for the last few decades, you’ve heard of the OWASP Top Ten. It’s a list of 10 security problems that we move around every year and never really solve. Oh sure, there are a few things we’ve made less bad, but fundamentally the list shows how our use of technology changes rather than a measure of solving problems.

I was talking with a friend long ago and I made a comment along the lines of “I don’t understand why OWASP doesn’t create an effort to eradicate whatever is number one on the list”. Their response was “OWASP is mostly consultants, they don’t want to solve these problems”. I am aware of the cynical nature of that answer, but it stopped me in my tracks for a moment. The Top Ten list gets a ton of attention, and if you look at the attention the current list is receiving, it’s less about solutions and more talking about how exciting a newly shuffled list is. A new Top Ten list is exciting, and it’s especially exciting when there’s a new entry on the list.

For the rest of this post, I’m going to focus on the new supply chain entry on the list. It’s number 3.

It’s worth starting out with the premise that there is no “Software Supply Chain”. Well there is, but I mean it’s not a term or concept you can just define. I could try to define it here, and every single reader will disagree because their definition is 1) Different, and 2) Better. A clever reader might be thinking right now we should probably define what this means. We probably should. The current definition is probably “supply chain is whatever I’m trying to sell”. Oh wait, I said I wasn’t going to define it. Too late.

So anyway, the point of this blog post is to set expectations on what happens after something lands on the OWASP Top Ten list. There will be a lot of people who proclaim all the exposure the Top Ten list generates is the solution. As we all know exposure is the most valuable currency, so I’m sure the list will drive plenty of exposure. But it should come as no surprise that just being on this list isn’t a solution.

The things on the OWASP Top Ten are systemic problems in our industry. We don’t solve systemic problems by buying a security tool. You can solve part of the problem sometimes, but the actual problem isn’t something any one company solves. Let’s pick apart the Software Supply Chain as a systemic issue in the industry.

What most people mean when they say Software Supply Chain is open source. They mean they are struggling with all the open source that runs all the software now. There are countless surveys and reports that declare all software is somewhere between 80% and 99% open source. What we’re really worried about is the Open Source Software Supply Chain.

Part of what makes this so hard is there isn’t a singular Open Source Software Supply Chain; open source is a collection of millions of projects and tens of millions of people. Nobody is in charge. There can be pockets of coordination where groups work together but even then there are at most thousands of those groups and still millions of things lacking coordination. This is a number larger than anyone can possibly comprehend, much less understand. You’d be wise to avoid anyone claiming to understand open source, they are basically a bigfoot expert who has never seen bigfoot.

So let’s rewrite the new OWASP item. It’s not “Software Supply Chain Failures”. It’s more accurate to say “Collection of random software I found in the couch cushions that I don’t understand and we don’t know where most of it comes from”. But didn’t I just say you can’t understand your open source software? I said, you can’t understand the nebulous cloud known as Open Source; but there are things they have in common. You can understand the specific open source software that you use…if you want to. And you should.

This is like claiming instead of building a structure that can withstand a hurricane if you buy my anti-hurricane product. That’s a silly premise. What we really need are buildings that are designed to withstand the weather in the place they are built. A hurricane isn’t a concern if you’re in Chicago, but it is a concern if you’re in Miami. Using open source software is a similar problem.

The problems you will see in the NPM ecosystem are not the same as the problems you will see in the PyPI ecosystem. There are some similarities, but there are also many differences. For example, NPM has a lot of very small packages designed to do one thing, so you end up with a huge explosion of dependencies. PyPI has less dependency explosion, but they often ship pre-built binary components. Two very different sets of challenges.

So what should a proper response to Software Supply Chain Failures look like? There isn’t a single answer, but there are ideas and groups that are on the right path. The Cyber Resilience Act in the EU seems to be a good start. There are supply chain efforts in foundations like the Linux Foundation and the Eclipse Foundation. But those efforts are less about technology and more about the people. The TL;DR of many efforts is really “know what you’re shipping”. It’s the first place to start.

It’s easy to be a cynic about anything happening in the security space. There is a lot of good happening, but we need to roll up our sleeves and do the work. Open source is a team sport. Ask your vendors how they are helping. Ask your developers which projects they are helping out. Ask all the people on LinkedIn posting about the supply chain how they are helping (posting opinions on LinkedIn doesn’t count as helping).

If your first reaction to this is “that sounds hard” and your second reaction is “I don’t know where to start”, that’s OK. It is hard and it’s not always obvious where to start. The first step is knowing what you have. I’m partial to using SBOMs to figure this out, but it’s not the only way. If the open source you’re using is 99% Python, that’s where you can start. The Python Software Foundation has a bunch of working groups. If you don’t see anything you like there, go check out the OpenSSF, or OWASP, or one of the countless Linux Foundation vertical groups.

You could reach out and see if some of the python packages you are using could use help. Maybe it’s money, maybe it’s patches, maybe it’s just hanging out with them and chatting about what’s happening. You can even ask me (or someone else you know in this universe), I love talking about this stuff and I’ll point you at someone smarter than me who can help you out. There’s no one right way to get involved.

The most important takeaway from all this is just because OWASP added software supply chain (open source) to the list, doesn’t mean it will magically solve itself. Supply chain security making the OWASP list changes nothing unless we make the change happen. The things that have fallen off the OWASP list did so because groups of dedicated people did a lot of work to improve the situation. We are the dedicated people, we have to fix this. The cavalry isn’t coming to save us, we are the cavalry.

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.

As an Associate Professor of Cybersecurity, I spend a lot of time thinking about risk, and increasingly, that risk lives within the software supply chain. The current industry focus on CVEs is a necessary, but ultimately insufficient, approach to securing modern, containerized applications.

Frankly, relying on basic vulnerability scanning alone is like putting a single padlock on a vault with an open back door, it gives a false sense of security. If we are serious about container security, we need to go beyond the patch-and-pray cycle and start enforcing comprehensive, deep inspection.

The Limitation of CVE-Only Scanning

The vast majority of container security tools trumpet their ability to find CVEs or remove all CVEs from base images. While identifying known vulnerabilities is crucial, it only addresses one facet of risk. What about the other, often more insidious, security pitfalls?

• Misconfigurations: An application might have zero known vulnerabilities, but if a critical configuration file is improperly set (e.g., exposed ports, weak permissions), the image is fundamentally insecure.
• Hidden Secrets: The accidental inclusion of API keys, SSH keys, or database credentials is a depressingly common issue. A CVE scanner won’t catch these, but a single leaked secret can lead to total environment compromise.
• Supply Chain Integrity: Is a package allowed in your image? Are you using specific, approved base images? The presence of unauthorized or blacklisted packages introduces unknown, unvetted risk.
• License and attestation: Do you care about licensing and their compliance? The presence of accurate license data and attestation ensures that all software components meet legal and organizational compliance standards, reducing risk and supporting secure, transparent supply chains. 

I’ve seen first hand how a policy failure, not a zero-day, is often the weakest link. True security means moving from a reactive model of patching what’s known to a proactive model of enforcing what’s correct.

Deeper Analysis with Anchore

This is where a tool like Anchore becomes essential. Anchore shifts the focus from merely reporting CVEs to enforcing a robust security and compliance policy based on a complete understanding of the container image. It allows us to codify security expectations directly into the CI/CD pipeline.

Here’s how Anchore enables a deep inspection that goes far beyond the basic vulnerability database:

1. Configuration File Compliance

Anchore analyzes the actual contents and structure of configuration files within your image.

1. Configuration File Compliance

Anchore analyzes the actual contents and structure of configuration files within your image.

Anchore Enterprise’s Policy Engine is configured to enforce these advanced security checks. Let’s explore how to do this:

These policies are built from a hierarchy of gates, triggers, and actions. You can read more about policy and its components in my previous blogpost: Automate Your Compliance: How Anchore Enforce Secures the Software Supply Chain.

To ensure configuration files comply with security best practices, you can use the retrieved_files policy gate. This gate allows Anchore to inspect the contents of files included in your image, enabling the detection of misconfigurations and other potential issues.

Learn more about the retrieved_files gate here: Anchore Documentation – Gate: retrieved_files.

To add a new rule:

1. Go to your preferred policy settings.
2. Add a new rule.
3. In the Gate dropdown menu, select retrieved_files.
4. Choose a Trigger.
5. Specify the file path (location of the files).
6. Enter the regex pattern you want to detect.
7. Finally, apply the new rule and save the updated policy.

2. Image Whitelists and Blacklists

Moving beyond just patching vulnerabilities, Anchore allows you to control the universe of components that make up your image.

• Denylisting: Automatically fail an image if it contains an unapproved or deprecated package, such as an old version of python2 or a specific cryptomining library that slipped past a developer.

• Allowlisting: Enforce that only packages from a specific, trusted vendor or build are permitted, ensuring that all components adhere to strict internal quality standards.

You can read more about allowlist here: Anchore Documentation — Allowlists

Anchore goes beyond traditional CVE scanning by giving teams precise control over what is and isn’t allowed in their container images, enabling proactive, policy-driven security that aligns with their organization’s unique compliance and quality standards.

3. Secret and Credential Detection

Perhaps the most critical “non-CVE” check is secret and credential scanning. Anchore uses the secret_scans gates to scan the entire filesystem of the container image for patterns matching sensitive data.

For example, using this gate allows you to set a rule that fails the image build if any file contains a string that looks like a high-entropy AWS Secret Key or a standard format SSH private key. This definitely goes beyond traditional CVE scanning and prevents catastrophic credential leakage before the image ever hits a registry.

Read more about this gate here: Anchore Documentation — Gate: secret_scans

4. Licensing and Attestation

For comprehensive software supply chain hygiene, Anchore also allows policies around component licensing, ensuring you meet legal and compliance obligations for open source usage. You can also enforce build-time attestation, ensuring the image was built by an approved CI/CD system and hasn’t been tampered with.

Example: Enforcing License Denylists

A critical part of software supply chain policy is preventing the accidental use of components licensed under specific, undesirable terms. Anchore uses the License Gate and its corresponding License Trigger to check for the presence of any license you want to deny.

Let’s say your organization must block all strong copyleft licenses, such as the GNU General Public License v2.0-only (GPL-2.0-only), because it requires derivative works (like your final application) to also be published under the GPL.

How Anchore Enforces This:

Detection: Anchore scans the image and identifies every package and file licensed under GPL-2.0-only.

Policy Rule: A rule is configured in the policy to target the license trigger and set the action to STOP if GPL-2.0-only is detected in any installed package.

Conclusion: Dive Deep with Anchore Enterprise

As cybersecurity professionals, we must champion the shift from reactive vulnerability management to proactive policy enforcement.

A CVE score tells you about known weaknesses. Deep container analysis with Anchore Enterprise tells you whether the image adheres to your organization’s definition of secure and compliant.

The software supply chain is where the next major cybersecurity battles will be fought. By implementing deep inspection policies now, we can move beyond the CVE and build a truly resilient, defensible container infrastructure. We simply can’t afford to do less.

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

It’s starting to feel like 2025 is going to be the year of IT compliance. We hear about new regulations like the CRA, PLD, DORA, SSDF; as well as, updates to standards like FDA, PCI-DSS, and SSDF. If you’re a compliance nerd this has been an absolutely wild year. It seems like there’s a new compliance standard or update happening every other week. Why this is happening right now is a hotly contested topic. There’s no single reason we’re seeing compliance becoming more important than it’s ever been in the world of IT. But no matter the reason, and no matter if you think this is good or bad, it’s the new normal.

It should also be noted that IT isn’t special. It’s easy to claim IT isn’t comparable to other industries for many reasons; we move very fast and we don’t usually deal with physical goods. Many other industries have had regulations for tens or even hundreds of years. We can think of food safety or automobile safety as easy examples where regulations and compliance are a major driving force. If anything this shows us that IT is becoming a mature industry, just like all those other regulated spaces.

There’s a new term being used I find delightful. CompOps. Think DevOps, but with compliance—basically Compliance Operations. If you wanted to get silly we could make up something like DevCompSecOps. We like to put words in front of Ops to claim it’s a new way of doing something. In this particular instance, CompOps, there might actually be a new way of doing things. Having to conform to compliance standards is something the world of IT hasn’t really had to do at scale before. There’s no way we can comply with these standards without making some changes, so the term CompOps helps show that something is different.

When we think of how compliance in IT used to work, the first thing that comes to mind would be the annual audit. Once a year an auditor would come around and ask for a bunch of evidence. Everyone would make sure all the patches were installed, and user accounts cleaned up. Make sure the logging server was working and all that awareness training was finished. The auditor would collect their evidence, and assuming everything checked out, you were off the hook for another year!

Compliance isn’t a once a year effort anymore. Many of the new standards are demanding certain evidence be collected regularly and saved for a period of time. For example the CRA demands SBOM be generated for every software release and stored for 10 years. PCI-DSS 4 requires vulnerability scans to be run at least every three months! 

And it’s not just about scanning, it also has to be shown that findings were resolved. This new way of adhering to a compliance standard on a constant basis will need a new process. The ideas behind CompOps is a new process. Rather than keeping your compliance staff hidden away in a dark basement until the once a year you need them, they are going to be present for everything now. We will all need guidance to ensure things are done right at the start, but also things are kept right all the time.

So how do we do this CompOps thing?

Let’s start with the difficult reality that your security budget is likely already fueled by compliance requirements. Security teams have always struggled to show business value, this has been a problem since the beginning of security. How do you prove you’re the reason something didn’t happen? When security teams do their jobs, the result is nothing. “Nothing” can’t be measured. It’s pretty easy to measure when things go wrong, but very hard to measure when things go right. 

However, we can measure compliance requirements. If we can’t do business in a certain jurisdiction, or can’t take credit cards, or can’t process customer data, that’s easy to explain. If we meet these requirements, the rest of the business can do their thing. If we don’t meet those requirements everything grinds to a halt. That’s an easy story to tell. So make sure you tell it.

Security teams love to be in charge. There’s nothing more exciting than showing up and declaring everything is going to be fine because security is here! If you do this when trying to build out a compliance program you just lost before you started. It’s likely your existing development and operations teams are doing a subset of the things you’re going to need in this new compliance focused world. The only real difference might be you have to continuously collect evidence now.

Speaking of continuously collecting evidence. When you have a process you do once a year, you can sort of just wing it and deal with whatever bumps in the road show up along the way. Once a year isn’t all that often so it’s easy to justify manual effort. When you have to do something every month, or every week, or every day, the rules all change. Now we go from justifying a few extra hours of manual effort to an unacceptable amount of effort needed every single day. 

The world of CompOps means we have to architect how we are going to meet our compliance requirements. It’s a lot like building software, or deploying infrastructure, except in this case it’s meeting your compliance requirements. The DevOps crowd has a lot they can teach here. DevOps is all about making systems resilient and repeatable. The exact sort of thing we’re going to need!

It’s probably better to think of all this like a product manager more than a security or compliance team. Your DevOps folks know how to architect solutions based on a set of requirements. If we think of a compliance standard as a set of detailed requirements, we can translate those requirements into something the DevOps team already knows how to handle. This whole CompOps world is going to be all about communication and cooperation.

The road ahead

For many of us, all these new compliance standards are a welcome change, but it’s also a future filled with hard work and difficult problems. Change is always hard, and this will be no exception. While many of us are familiar with meeting compliance standards, the future of compliance won’t look like the past. It’s time to implement compliance programs that are not only continuous, but are part of our development and operations processes. For an experienced DevOps team these will all be very solvable problems, assuming we communicate clearly and work with them as a trusted partner.

In a few years we won’t be talking about CompOps anymore because it will just be part of the existing DevOps process. Our job for the next year or two will be figuring out how to normalize all these new requirements. If we don’t listen to our DevOps experts, none of this is going to be smooth and painless. They can teach us a lot, make sure you listen to them. Because if we do our job right, nothing will happen.

When I woke up the morning of September 8, I didn’t have the foggiest idea what the day had prepared for me. The most terrifying part of being a security person is the first few minutes of your day when you check the dashboards.

By mid-morning the now infamous blog post from Aikido Security about compromised NPM packages had found its way into Anchore’s Slack. My immediate response? Immediate panic, followed by relief when the scan of Anchore systems came back with the answer that we weren’t impacted.

We wanted to write this blog post to give the broader community a peek behind the curtains at what a zero-day vulnerability disclosure looks like from the perspective of the vendors who help customers protect their users from supply chain attacks. Spoiler: we’re just normal people making reasonable decisions while under pressure. 

Let’s walk through what actually happened behind the scenes at Anchore.

The first ten minutes: actions > root cause

When I first read the Aikido post, I didn’t care about the technical details of how the attack happened or the fascinating social engineering tactics. I wanted one thing: the list of affected packages. Something actionable.

The list was originally buried at the bottom of their blog post, which meant those first few minutes involved a lot of scrolling and muttering. But once we had it, everything clicked into place. This is lesson number one when a zero-day disclosure hits: get to the actionable information as fast as possible. Skip the drama, find the indicators, and start checking.

Step one: are we affected?

At Anchore, we dogfood our own products constantly (the Anchore Enterprise instance is literally named “dogfood”). On any given day, it’s somewhere between number two and three on my daily TODO list. On this day, I pulled up the latest build of Anchore Enterprise, and got to work.

First check: our latest releases. Our latest release was from the Friday before this all happened, so the timing meant the malicious packages couldn’t have made it into our most recent release. That’s good news, but it’s just the start.

Next check: the development versions of Anchore Enterprise. We pulled up our SBOMs and started looking. No malicious packages as direct dependencies—that’s a relief. But we did have some of the targeted packages as transitive dependencies! Luckily the packages we had inherited were not the malicious versions. Our dependency management had kept us safe, but we needed to verify this everywhere.

Then we checked with the UI team. Did anyone have these packages installed in their development environments? Did anything make it into CI? Nope, everything checked out.

GitHub Actions workflows were next. Sometimes we have opportunistic dependencies that get pulled during builds. Some of the packages were there, but not the vulnerable versions.

This whole process took maybe twenty minutes. Twenty minutes to check our current state across multiple products and teams. That’s only possible because we generate and store SBOMs for every build and create the tools to search through the growing inventory efficiently. We have stored SBOMs for every nightly and release of Anchore Enterprise. I can search them all very quickly.

Step two: the historical question

Now that we have confirmed that our infrastructure isn’t breached, the next question to answer is “has Anchore ever had any of these malicious packages?” Not just today, but at any point in our history. Granted the history was really just a few days in this instance, but you can imagine a situation like Log4Shell where there were years of history to wade through.

We have 1,571 containers in our build history. If we had to manually check each one, we’d still be working on it. But because we maintain a historical inventory of SBOMs in our database for all of our container builds, this became a simple query. A few seconds later: nothing found across our entire history.

These are the kinds of questions that keep me up at night during incidents: “Are we affected now?” is important, but “were we ever affected?” can be just as critical. Imagine discovering three months later that you shipped a compromised package to customers. The blast radius of that is enormous.

Having historical tracking isn’t fancy or sexy. It’s just good operational hygiene. And in moments like this, it means the difference between answering “I don’t know” and “we’re good.”

Step three: can we protect our customers?

Okay, so Anchore is clean. Great. But we sell the security tools that automate this kind of incident response—our customers are depending on us to help them figure out if they’re affected and detect these malicious packages.

Early in the incident, the GitHub Advisory Database made an understandable but problematic decision: they set the affected versions of these packages to 0, which meant all versions would be flagged as vulnerable. This potentially created mass confusion for users who rely on the GHSA DB for vulnerability results. If anyone ran a vulnerability scan with this version of the GHSA DB their scanners would have lit up like Christmas trees, flagging packages that were known to be good.

In order to protect our customers from this panic inducing possibility we made the call: stop our vulnerability database build. We’d never tried to kill a build mid-process before, but this was one of those “figure it out as we go” moments. We stopped the build, then went to make pull requests to the GitHub Advisory Database to fix the version ranges.

By the time we got there, the GitHub team had already found the issue and a fix was in-flight. This is how the open source community works when everything is going right—multiple teams identifying the same problem and coordinating to fix it.

As soon as GitHub pushed their fix, we rebuilt our vulnerability database and messaged our customers. The goal was simple: make sure our customers had accurate information and could trust their scans. From detection to customer notification happened in hours, not days.

Why is GitHub in this story?

I want to make an important point about why the GitHub Vulnerability Database is an important part of this story. At Anchore, we have an open source vulnerability scanner called Grype. In order for Grype to work, we need vulnerability data that’s available to the public. Most vulnerability data companies don’t let you publish their data to the public, for free, for some reason.

GitHub is an important source of vulnerability data for both Anchore Enterprise and Grype. We have a number of vulnerability data sources and we do quite a lot of work on our own to polish up data without a robust source. Rather than pull in GitHub’s data and treat it like our own, we take the open source approach of working with our upstream. Anytime there are corrections needed in any of our upstream data, we go to the source with the fixes. This helps the entire community with accuracy of data. Open source only works when you get involved. So we are involved.

What actually matters during a zero-day

Looking back at this incident, a few lessons stand out about what actually matters when something like this hits:

Get to actionable information fast. The technical details are interesting for a blog post later, but when you’re responding, you need indicators. Package names. Version numbers. Hashes. Don’t get distracted by the story until you’ve handled the response.

Check yourself first, but don’t stop there. We needed to know if Anchore was affected, but we couldn’t stop at “we’re fine.” Our customers depend on us to help them figure out their exposure.

Historical tracking matters. Being able to answer “were we ever affected?” is just as important as “are we affected now?” If you don’t have historical SBOMs, you can’t answer that question with confidence.

Speed matters, but accuracy matters more. When the GitHub Advisory Database incorrectly flagged all versions, it could have created chaos. We could have pushed that bad data to customers quickly, but we stopped, verified, and waited for the fix. A fast response is important, but an accurate response is what actually helps.

Automation is your friend. Twenty minutes to check 1,571 historical containers? That only happens with automation. Manual verification would have taken days or weeks.

The NPM community’s response was impressive

Here’s something that deserves more attention: NPM pulled the malicious packages in approximately six hours. Six hours from compromise to resolution. We only have to think back to 2021 when Log4j was disclosed and the industry was still responding to the incident weeks and even months later.

This wasn’t one company with a massive security team solving the problem. This was the open source community working together. Information was shared. Multiple organizations contributed. The response was faster than any single company could have managed, no matter how large their security team.

The attackers successfully phished more than one maintainer and bypassed 2FA (clearly not phishing-resistant 2FA, but that’s a conversation for another post). This was a sophisticated attack. And the community still went from compromised to clean in six hours.

That’s remarkable, and it’s only possible because the supply chain security ecosystem has matured significantly over the last few years.

How this compares to Log4Shell

This whole process reminded me of our response to Log4Shell in December 2021. We followed essentially the same playbook: check if we’re affected, verify our detection works, inform customers, help them respond.

During Log4Shell, we discovered Anchore had some instances of Log4j, but they weren’t exploitable. We created a test Java jar container (we called it “jarjar“) to verify our scanning could detect it. We helped customers scan their historical SBOMs to determine if and when Log4j appeared in their infrastructure, this provided their threat response teams with the information to bound their investigation and clearly define their risk.

But here’s the critical difference: Log4Shell response was measured in days and weeks. This NPM incident was measured in hours. The attack surface was arguably larger—these are extremely popular NPM packages with millions of weekly downloads. But the response time was dramatically faster.

That improvement represents years of investment in better tools, better processes, and better collaboration across the industry. It’s why Anchore has been building exactly these capabilities—historical SBOM tracking, rapid vulnerability detection, automated response workflows. Not for hypothetical scenarios, but for moments exactly like this.

What this means for you

This NPM incident is hopefully over for all of us (good luck if you’re still working on it). It’s probably worth thinking about what you can do for the next one. My advice would be to start keeping an inventory of your software if you’re not already. I’m partial to SBOMs of course. There will be more supply chain attacks in the future, they will need a quick response. The gap between “we checked everything in twenty minutes” and “we’re still trying to figure out what we have” represents real business risk. That gap is also entirely preventable.

Supply chain attacks aren’t theoretical. They’re happening regularly, they’re getting more sophisticated, and they will keep happening. The only question is whether you’re prepared to respond fast.

The tools exist

At Anchore, we built Syft and Grype specifically for these scenarios. Syft generates SBOMs that give you a complete inventory of your software. Grype scans for vulnerabilities. These are free, open source tools that anyone can use.

For organizations that need historical SBOM tracking, policy enforcement, and compliance reporting, Anchore Enterprise provides those capabilities. This isn’t a sales pitch—these are the actual tools we used during this incident to verify our own exposure and help our customers.

None of this is magic. It’s just normal people making normal decisions about how to prepare for predictable problems. Supply chain attacks are predictable. The question is whether you’ll be ready when the next one hits.

What’s next

Here’s what I expect: more supply chain attacks, more sophisticated techniques, and continued pressure on open source maintainers. But I also expect continued improvement in response times as the ecosystem matures.

Six hours from compromise to resolution is impressive, but I bet we can do better. As more organizations adopt SBOMs, vulnerability scanning, and historical tracking, the collective response will get even faster.

The question for your organization is simple: when the next incident happens—and it will—will you spend twenty minutes verifying you’re clean, or will you spend weeks trying to figure out what you have?

The best time to prepare for a supply chain attack was 10 years ago. The second best time is now.If you want to talk about how to actually implement this stuff—not in theory, but in practice—reach out to our team. Or join the conversation on our community Discourse where we talk about exactly these kinds of incidents and how to prepare for them.

October is Cybersecurity Awareness Month, an idea that’s more than 20 years old now. It’s an idea that had its day, it’s time to re-think the intended purpose. Cybersecurity is ever present now; Cybersecurity Awareness Month shouldn’t exist anymore. The modern purpose of Cybersecurity Awareness Month seems to be mostly for security people to make fun of Cybersecurity Awareness Month.

Let’s start with some history

Cybersecurity awareness month started in 2004. Back in 2004 things were VERY different. 2004 saw a bit more than 2,000 CVE IDs (we’re going to see more than 45,000 by the time 2025 ends). Windows XP SP2 was released in 2004. Many of the news stories I dug up were wondering how close we were to ending spam—how quaint. That’s not a world any of us can recognize anymore. Back in 2004 we would have contests to see who could keep a computer running the longest without rebooting (or applying security updates … or any updates). I could go on, but you get the point. It may have been 20 calendar years, but in tech that feels like 200 years. If any of us traveled back to 2004 we wouldn’t know how anything works, and if someone from 2004 showed up today, they wouldn’t be able to make anything work either.

Cybersecurity awareness month probably made sense back in 2004. It was a brand new problem. This whole internet thing was catching on. We were suddenly using computers to mail DVDs to our homes, check our account balances (instead of an ATM) and to frustrate our family doctors after consulting WebMD. 

It’s no surprise that as humanity began its online journey there would be a whole new group of criminals looking for opportunity. Nobody understood that using the same password everywhere was a bad idea, or that you should install those security updates quickly, or that the email you got about winning the lottery wasn’t real. Having a month where everyone was trying to draw attention to what’s happening probably made sense. It’s hard to spread new ideas, using a gimmick is a great way to get attention.

If we fast forward to 2025, a dedicated month for cybersecurity awareness doesn’t make sense anymore. It would also be a mistake to say “every month is cybersecurity awareness month”. Security awareness also isn’t everyone’s problem. Awareness is part of every security team, it has to be. Things change faster than anyone can possibly keep up with.

Keeping people informed about security is something that happens all the time as needs arise. We can probably use compliance as a good example here. Remember when we only worried about compliance once a year when the auditor was coming to town? That’s not how it works anymore, many of the compliance standards have requirements to collect evidence all year long, not once the night before it’s due. If there’s a new SMS spam attack happening against your company, you’re not going to take a note to cover it next October, you’re going to reach out to everyone right now!

Cybersecurity awareness isn’t a point in time or a single event. It’s honestly not really even about only awareness. It’s all about building trust with whoever the people are you are there to help out. It has to be woven into constant communications about whatever matters right now. You can’t build trust once a year, trust happens through consistent communication and also positive behavior. It’s critical that the people security teams are meant to be protecting aren’t afraid to ask questions or report suspicious activities. Even if those suspicious activities were caused by something they did.

Security teams used to be all about blame. Who is to blame? Anything bad that happened was the fault of someone. We also complained constantly about how little all the other teams cared about security, or how they didn’t seem to like us very much. There are still plenty of security teams that try to assign blame, but it’s not the default anymore, at least not the good teams. Good security teams are now all about being a trusted partner. You aren’t automatically a trusted partner, you have to earn it every day. We don’t need a special month, if anything a special month might detract from a program that’s trying to build trust.

When October rolls around the only thing that you should change is maybe some extra memes making fun of awareness month.

If you’re a security team, planning security focused communications can and should happen all year long. Make sure you understand who you’re working with and why. If you’re not sure your partners trust you, they probably don’t.

October is also National Pizza Month, you can start building trust by buying everyone some pizza. Security will probably never be as loved as pizza, but we can at least try!

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

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

If you pay attention to the world of AI, you’ll have noticed that Model Context Protocol (MCP) is a very popular topic right now. The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools. The architecture is straightforward: developers can either expose their data through MCP servers or build AI applications (MCP clients) that connect to these servers.

Because MCP is so popular it seemed like a great topic to do some security research with. I decided to review the top 161 MCP servers currently listed on the Docker hub, generate SBOMs for each container then run a vulnerability scan to see what the current state of that software is.

The list of the MCP server I used can be found on Docker Hub at  https://hub.docker.com/mcp. The tools I am using are explained further down. 

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

Step by step vulnerability analysis of 161 MCP servers 

As a first step I pulled all the container images then I used our OSS Syft scanner to generate SBOMs for each image. When Syft scans a container it catalogs all the packages and files contained in a container image. Those SBOMs were then scanned with our OSS vulnerability scanner Grype . All scan results, SBOMs and vulnerabilities were put into Elasticsearch. I enjoy using Elasticsearch as it makes it very easy to make graphs of the data and understand what’s happening.

Keep in mind, these results are the output of Syft and Grype; if there is a bug in one of them, or they cannot detect a certain package type, that will cause a hole in the data. These results shouldn’t be treated as 100% accurate, but we can derive observations, trends, and patterns based on this data set.

How bad is it? TL;DR: It’s pretty bad.

In 161 containers, Grype found exactly 9000 vulnerabilities. The number is certainly larger now. Vulnerabilities are a point in time snapshot, it was 9000 when the scan was run in early September 2025. As time moves forward, more vulnerabilities will be uncovered. CVE is adding around 4000 new vulnerabilities per month, some of which will affect a subset of the software in these MCP containers.

Let’s start with the top 10 containers by vulnerability count.

We should dig deeper into the top image as there’s more happening than the raw numbers would suggest. What if we look at the number of vulnerabilities based on the type of package for that image?

This image is based on Debian 12 specifically, which isn’t particularly old. If we take a closer look, we see 429 Debian packages installed, 51 python modules, and 13 unpackaged binaries. 429 packages is quite a lot. The default Debian base container image contains 78 packages, 429 is a lot of new packages being added!

Before publishing, I did contact Clickhouse and they have updated their container image, it’s in way better shape now. I applaud their quick updates!

What’s the make up of a MCP container?

Rather than dwell on this one container, let’s zoom out and look at all the data first. That will allow us to better explain what’s happening with Debian and why we see these results.

Let’s look at the list of all Linux distributions in use in these MCP containers:

The observant will now say that only adds up to 160! The mcp/docker image has no distro. There are also no RPM based container images in the top MCP servers (this might only be interesting to me as I spent many years at RedHat).

Each image has various packages installed, in this instance from the Linux distributions deb and apk. It also includes packages used by the various languages in use such as Python and NPM. What does the number of packages spread across all the images look like?

Anybody watching the world of package ecosystems would probably expect this distribution above; NPM is a widely used language with a lot of packages. Debian is used by many images and doesn’t focus on minimal packages like Alpine, and Go and Python are commonly used languages.

Analysis of vulnerabilities in a debian image

Now if we shift our focus back to vulnerabilities, what does the distribution of vulnerabilities by package look like?

As seen above, the Debian packages account for the vast majority of vulnerabilities in these container images.

On a side note: I want to take a moment to explain something important about the Debian results. We should not be using this data to make a claim Debian is insecure. Debian is a very well maintained distribution with a great security team. They have a huge number of packages they have to keep track of. Debian puts a ton of effort into fixing the security vulnerabilities that truly matter. When a small team of volunteers have limited time, we of course want them working on things that matter, not wasting time on low severity vulnerability noise.

If we look at the distribution of vulnerabilities affecting the Debian packages we are getting a clearer picture: 

The vast majority  are “Negligible” Debian vulnerabilities. These are vulnerabilities the Debian security team after careful analysis has decided are lower than low and will be de-prioritized compared to other vulnerabilities.

I scanned the latest Debian container and these are the results: 0 critical, 0 high, 1 medium, 5 low, 40 negligible. That’s very impressive, and it’s also a great reason to keep your software up to date.  Also keep in mind that many of these MCP Debian images haven’t been updated in a long time. It’s hardly Debian’s fault when the author of a container builds it then never updates the Debian packages.

But how bad is it overall?

On the topic of vulnerability severities, what does that graph look like across all packages in all the containers?

This graph looks a bit like that Debian distribution, but here we are seeing  263 critical vulnerabilities. That’s 263 critical vulnerabilities in 161 container images which seems like a lot. If we break this down into the packages affected by critical vulnerabilities this is what we get.

While we know there are a lot of outdated Debian packages, it’s clear most of the other ecosystems have problems as well. We haven’t done enough research to say if these critical findings could be exploited, but even if not, it’s bad optics. It’s common for an organization to have a policy of no critical vulnerabilities in any software they deploy, it doesn’t matter if it’s exploitable or not.

Deep dive into 36,000 NPM packages

If we recall the table of all package types at the beginning of this post, there were more than 36,000 NPM packages installed in these 161 container images. Since NPM is significantly more than all the other ecosystems combined, we should investigate a bit further. What are the most installed NPM packages?

It is impressive that minipass has almost 700 installs in 161 containers, unless you are an NPM developer, then these packages won’t surprise you. They are widely used across NPM both for MCP and non-MCP software.

As a note to myself, a future research project should be looking for NPM packages that have been removed for having malware, or could be typosquatted or slopsquatted.

When working with these types of data sets, I am always interested to look at the size of files in the images. 

If we look at the graph, there are a huge number of small files but also always outliers that are much larger than one would expect. One datapoint even nears 600 Megabytes. That’s a pretty big file, and my initial thought was that it could be some sort of LLM model or training content. In the clickhouse container there is a shared library in a python package that’s nearly 600 Megabytes in size. It’s a binary library in a file named _chdb.cpython-313-x86_64-linux-gnu.so. chdb is an in-memory database with data needed by the MCP server, so yeah, it’s AI content.

The other outliers around 100 MB are clickhouse and vizro containers with the pyarrow library, about 66 MB. And the aws-terraform container with a 120MB package called playwright.

It’s likely these large files aren’t mistakes but are indeed used by the container images. There’s nothing wrong with large containers. But it’s always interesting to look for outlier data to ensure mistakes haven’t been made somewhere along the way. We want to make sure we don’t accidentally include some sensitive files, or extra packages, or even debug data that nobody needs.

Conclusion…if you want to call them that 

This post has a lot of data for us to think about, it’s probably overwhelming at a first glance. I don’t suggest that this should be treated as some sort of deep security analysis of MCP, it’s meant to be a brief overview of some interesting findings while digging into data. My goal is to start conversations and hopefully see more deeper research into these MCP images. If you think I did something wrong, or want to ask different questions, nothing would make me happier to be proven wrong, or inspire further research.

For now, these are the conclusions I have drawn. All of these images would benefit from some common vulnerability handling best practices:

1. Keeping software updated is a great first step. Regular updates are hard, but also table stakes for anyone building software in the modern age. 
2. Minimizing attack surfaces should also be used when possible. There are small container images to build on top of. Make sure you prune out unused dependencies on a regular basis. Only use the dependencies and libraries that are needed. 
3. And most importantly is to keep an inventory of what you’re shipping, then using that inventory to make informed decisions.

Software doesn’t age like a fine wine, more like milk. It’s important we keep track of what we’re shipping. When you produce software, it’s never a “one and done” sort of situation. It needs constant care and feeding. Understand what our threat model and risk profiles are, and most importantly, keep things updated.

Learn about the role that SBOMs for the security of your organization in this white paper.

Download Now

The software industry faces a growing problem: we have far more open issues than we have contributors multiplied by available time. Every project maintainer knows this pain. We certainly recognize this across our open source tools Syft, Grype and Grant.

The backlogs grow faster than teams can address them, and “good first issues” can sit untouched for months. What if we could use AI tools not just to write code, but to tackle this contributor time shortage systematically?

Friends and podcast presenters frequently share their perspective that LLMs are terrible at coding tasks. Rather than accepting this at face value, I wanted to conduct a controlled experiment using our own open source tools at Anchore.

My specific hypothesis: Can an LLM take me from start to finish; selecting a bug to work on, implementing a fix, and submitting a pull request that gets merged; while helping me learn something valuable about the codebase?

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

Finding the Right Issue to Work On

Most repositories tag specific issues as “good-first-issue”, a label typically assigned by the core developers. They tend to know the project well enough to identify work items suitable for newcomers. These issues represent the sweet spot: meaningful contributions that may not require deep architectural knowledge, which is why I think they might be suitable for this test.

Rather than manually browsing through dozens of issues, I wrote a quick script that uses gh to gather all the relevant data systematically. The expectation is that I can benefit from an LLM to pick an appropriate issue from this list.

#!/bin/bash
# Script to find and save open issues with 
# a specific label from a GitHub repository.
# 
# Usage: ./find-labelled-issues.sh [org/repo] [label] [limit]
set -e

repo="${1:-anchore/syft}"
label="${2:-good-first-issue}" 
limit="${3:-50}"
tmpfile=$(mktemp)
results="./results/$repo"

cleanup() {
    rm -f "$tmpfile"
}
trap cleanup EXIT

mkdir -p "$results"

# Grab the issues with the specified label
echo "Fetching issues from repo with label 'label'..."
gh issue list -R "repo" --label "$label" --state "open" --limit "$limit" --json number --jq '.[] | .number' > "tmpfile"

while read -r issue_number; do
    echo "Processing repo issue #issue_number"
    filename="(echo $repo | tr '/' '_')_issue_issue_number.json"
    gh issue view "issue_number" -R "$repo" --json title,body,author,createdAt,updatedAt,comments,labels --jq '. | {title: .title, body: .body, author: .author.login, createdAt: .createdAt, updatedAt: .updatedAt, comments: .comments, labels: [.labels[].name]}' | jq . > "$results/filename"
done < "$tmpfile"

echo "All issues processed. Results saved in the $results directory."

#!/bin/bash
# Script to find and save open issues with 
# a specific label from a GitHub repository.
# 
# Usage: ./find-labelled-issues.sh [org/repo] [label] [limit]
set -e

repo="${1:-anchore/syft}"
label="${2:-good-first-issue}" 
limit="${3:-50}"
tmpfile=$(mktemp)
results="./results/$repo"

cleanup() {
    rm -f "$tmpfile"
}
trap cleanup EXIT

mkdir -p "$results"

# Grab the issues with the specified label
echo "Fetching issues from repo with label 'label'..."
gh issue list -R "repo" --label "$label" --state "open" --limit "$limit" --json number --jq '.[] | .number' > "tmpfile"

while read -r issue_number; do
    echo "Processing repo issue #issue_number"
    filename="(echo $repo | tr '/' '_')_issue_issue_number.json"
    gh issue view "issue_number" -R "$repo" --json title,body,author,createdAt,updatedAt,comments,labels --jq '. | {title: .title, body: .body, author: .author.login, createdAt: .createdAt, updatedAt: .updatedAt, comments: .comments, labels: [.labels[].name]}' | jq . > "$results/filename"
done < "$tmpfile"

echo "All issues processed. Results saved in the $results directory."

This script does the heavy lifting of gathering not just the initial bug reports, but all the comments and discussions that often contain crucial implementation hints from the project maintainers.

I ran this across multiple Anchore repositories, to get the first fifty:

for repo in syft grype grant stereoscope; do 
    ./find-good-first-issues.sh anchore/$repo good-first-issue 50
done

for repo in syft grype grant stereoscope; do 
    ./find-good-first-issues.sh anchore/$repo good-first-issue 50
done

Letting the LLM Choose

With all the data collected, I presented the entire set to Claude and asked them to recommend which issue I should work on. I deliberately provided it with minimal criteria, allowing the LLM to develop its own evaluation framework.

Claude devised an evaluation criterion based on the following factors and weights:

Impact & User Value (Weight: 30%)

• High: Critical functionality, affects many users, or enables new important use cases
• Medium: Useful improvements or bug fixes affecting moderate user base
• Low: Nice-to-have features or edge cases

Implementation Complexity (Weight: 25%)

• Easy: Clear requirements, well-defined scope, straightforward implementation
• Medium: Some complexity but manageable with good planning
• Hard: Complex architecture changes, unclear requirements, or extensive testing needed

Information Quality (Weight: 20%)

• Excellent: Clear problem description, reproduction steps, examples, context
• Good: Adequate information with some details
• Poor: Vague description, missing context or examples

LLM Assistance Potential (Weight: 15%)

• High: Pattern matching, code generation, template work, documentation
• Medium: Some assistance possible for research or boilerplate
• Low: Requires deep domain expertise or complex architectural decisions

Community Need (Weight: 10%)

• High: Many comments, long-standing issue, or frequently requested
• Medium: Some community interest
• Low: Limited engagement
  

Using the above criteria, Claude grouped the current open issues into three “Tiers” and “Avoid”, for those that might be too complex or have insufficient information to complete. The “Top Tier” issues included Syft issue #675 – “Markdown Table Output Support”, and  #2555 – “Windows .NET6 Dependency Parsing Fix”, but finally landed on Syft issue #2250 – “package.json authors keyword parsing”. This involves parsing the authors field in package.json files. Quoting the LLM’s response, the rationale was somewhat compelling:

"This issue stands out as the best choice because it's ideal for AI assistance—it involves JSON parsing, regex patterns, and code generation—all areas where LLMs excel. The problem has crystal clear requirements with exact examples of expected JSON structures, a manageable scope contained in a single file. It provides real user impact by improving npm package metadata parsing accuracy."

"This issue stands out as the best choice because it's ideal for AI assistance—it involves JSON parsing, regex patterns, and code generation—all areas where LLMs excel. The problem has crystal clear requirements with exact examples of expected JSON structures, a manageable scope contained in a single file. It provides real user impact by improving npm package metadata parsing accuracy."

The issue was well-documented with specific examples:

"authors": [
   "Harry Potter <hp@hogwards.com> (http://youknowwho.com/)",
   "John Smith <j.smith@something.com> (http://awebsite.com/)"
]

"authors": [
   "Harry Potter <[email protected]> (http://youknowwho.com/)",
   "John Smith <[email protected]> (http://awebsite.com/)"
]

Starting the Development Work

With the issue selected, I moved into VS Code and enabled GitHub Copilot’s agent mode, which allows the AI to edit code and run commands rather than just make suggestions. My initial prompt was deliberately simple:

#codebase

This is the syft codebase. Syft is an SBOM generator.

I have analyzed all the open bugs in syft that are tagged "good first issue" and found 2250 a good one to start with.

The rationale is in #file:anchore_syft_issue_2250_rationale.md and the bug itself is detailed in #file:anchore_syft_issue_2250.json

Please formulate a plan for implementing the fix. Do not start working on the code. I would like you to break down the fix into the necessary steps and explain them. If you need more information, ask questions.

#codebase

This is the syft codebase. Syft is an SBOM generator.

I have analyzed all the open bugs in syft that are tagged "good first issue" and found 2250 a good one to start with.

The rationale is in #file:anchore_syft_issue_2250_rationale.md and the bug itself is detailed in #file:anchore_syft_issue_2250.json

Please formulate a plan for implementing the fix. Do not start working on the code. I would like you to break down the fix into the necessary steps and explain them. If you need more information, ask questions.

The key was treating this as a collaborative process. I read every response, examined all generated code, and made sure I understood each step. Working in a feature branch meant I could experiment freely, abandon approaches that weren’t working, and restart with different prompts when needed. I was under no obligation to accept any of the suggestions from the LLM.

The Iterative Process

The most valuable part of this experiment was the back-and-forth dialog. When the LLM-generated code was unclear to me, I asked questions. When it made assumptions about the codebase structure, I corrected them. When it needed more context about contributing guidelines, I provided that information by directing it to the CONTRIBUTING.md and DEVELOPING.md files from the repository.

This iterative approach allowed me to learn about the Syft codebase structure, Go programming patterns, and the project’s testing conventions throughout the process. The LLM worked as a knowledgeable pair-programming partner rather than a black-box code generator.

Testing and Validation

The LLM automatically detected the project’s existing test structure and generated appropriate test cases for the new functionality. It was understood that any changes needed to maintain backward compatibility and avoid breaking existing package.json parsing behavior.

Running the test suite confirmed that the implementation worked correctly and didn’t introduce regressions, a crucial step that many rushed “vibe-coded” AI-assisted contributions skip.

Pull Request Creation

When the code was ready, I asked the LLM to draft a pull request description using the project’s template. I edited this slightly to match my writing style before submitting, but the generated description covered all the key points: what the change does, why it’s needed, and how it was tested.

The pull request was submitted like any other contribution and entered the standard review process.

Results and Lessons Learned

The experiment succeeded: the pull request was merged after review and feedback from the maintainers. But the real insights came from what happened during the process:

Speed Gains: The development process was somewhere around 3-5 times faster than if I had tackled this issue manually. The LLM handled the routine parsing logic while I focused on understanding the broader codebase architecture.

Learning Acceleration: Rather than just producing code, the process accelerated my understanding of how Syft’s package parsing works, Go testing patterns, and the project’s contribution workflow.

Maintainer Perspective: The project maintainers could tell the code was AI-assisted (interesting in itself), but this wasn’t a significant problem. They provided thoughtful feedback that I was able to incorporate with the LLM’s help.

Room for Improvement: I should have explicitly pointed the LLM to the contributing guidelines instead of relying on the codebase to infer conventions. This would have saved some iteration cycles.

When This Approach Makes Sense

I wouldn’t use this process for every contribution. Consuming all the good-first-issues would leave nothing for human newcomers who want to learn through direct contribution. The sweet spot seems to be:

• Straightforward issues with clear requirements.
• Learning-focused development where you want to understand a new codebase.
• Time-constrained situations where you need to move faster than usual.
• Problems that involve routine parsing or data transformation logic.

Future Refinements

For the next contributions, I will make several improvements:

• Add explicit prompts to match my writing style for pull request descriptions.
• Point the LLM directly to the contributing guidelines and coding standards, which are in the repository, but sometimes require explicit mention.
• Consider working on issues that aren’t tagged as “good-first-issue” to preserve those seemingly “easier” ones for other human newcomers.
• Add a note in the pull request acknowledging the use of a tool-assisted approach.

The goal isn’t to replace human contributors, but to find ways that AI tools can help us tackle the growing backlog of open issues while genuinely accelerating our learning and understanding of the codebases we work with.

This experiment suggests that with the right approach, LLMs can be valuable partners in open source contribution, not just for generating code, but for navigating unfamiliar codebases and understanding project conventions. The key is maintaining active engagement with the entire process, rather than treating AI as a one-click magic solution. 

After conducting this experiment, I discussed the outcomes with the Anchore Open Source team, which welcomes contributions to all of its projects. They were quick to point out the quality difference between a well-curated AI-assisted pull request and a “vibe-coded” one, thrown over the wall.

What similar experiments would you want to see? The intersection of AI tools and open-source contributions feels like fertile ground for making our development workflows both faster and more educational.

Learn about the role that SBOMs for the security of your organization in this white paper.

Download Now

Lately it seems like a new company building hardened container images is popping up every other day. What’s the deal with this, why the sudden influx of hardened images? 

A previous blog article titled “Navigating the New Compliance Frontier” discussed some of the new trends with compliance. But it’s not as simple as just claiming “because compliance”–that’s the easy answer that doesn’t tell us much. Compliance doesn’t say anything about using hardened container images. But here’s the thing: many compliance standards do have things to say about configuration management, attack surface, and vulnerabilities. We’re not being told to use hardened images, but hardened images solve many of these problems, so they are getting used. It’s one of those situations where the practical solution emerges not because someone mandated it, but because it actually works.

When you operate in a regulated space (as we all will be soon, thanks to the CRA) you have to justify configuration changes, software changes, and every vulnerability. The idea behind the hardened images is to have only the software you absolutely need and nothing else. That translates into you only having a list of the vulnerabilities that directly affect you.

There’s an additional reason that’s giving small hardened images extra attention. The ability to scan your software for vulnerabilities is better than it’s ever been. Historically trying to scan software for vulnerabilities wasn’t very reliable or even a good use of anyone’s time. Scanners of the past missed a lot of things. It was a lot harder to figure out what all the software installed on bare metal, VMs, or containers. And by harder we really mean it was nearly impossible. It was common to just fall back to spreadsheets with people doing this all manually.

Scanning for vulnerabilities was basically out of the question, nobody had a decent inventory of their software supply chain. The scanners also had incomplete data if they even had data at all. The false positive rate made the results useless and the false negative rate made those useless results dangerous. It was also common to scan a system and just get no results at all. Not because there are no vulnerabilities, but because the scanners couldn’t figure anything out.

That’s not true anymore. If you scan any modern Linux distribution you’re going to get results. Language ecosystems like Python, Java, and Go are well supported. A lot of scanners can even figure out what pre-built binaries are in a container image. Scanners have gotten pretty good at finding the software in a container.

This also means that if we have a reliable list of software, we can also scan that list for vulnerabilities. Something you’ll notice quickly is a hardened minimal image has fewer findings than a more traditional container image. This doesn’t mean a minimal container image is better than a more traditional one. They solve different problems.Here’s an example, let’s look at an Alpine image and a Debian image. We can scan the container image with the Syft SBOM scanner.

➜  ~ syft alpine:latest
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ File metadata                   [81 locations]  
   ├── ✔ Executables                     [17 executables]  
   └── ✔ File digests                    [81 files] 

➜  ~ syft alpine:latest
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ File metadata                   [81 locations]  
   ├── ✔ Executables                     [17 executables]  
   └── ✔ File digests                    [81 files] 

➜  ~ syft debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files] 

➜  ~ syft debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files] 

The Alpine image has 16 packages in it. The Debian image has 78. That’s a pretty big difference. It’s pretty clear that an Alpine image would fall under the umbrella of a minimal hardened image while Debian does not.If we scan these for vulnerabilities the results are similar. The Grype vulnerability scanner does a great job when scanning both Alpine and Debian container images.

➜  ~ grype alpine:latest
 ✔ Vulnerability DB                [updated]  
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ Executables                     [17 executables]  
   ├── ✔ File metadata                   [81 locations]  
   └── ✔ File digests                    [81 files]  
 ✔ Scanned for vulnerabilities     [6 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 6 low, 0 negligible

➜  ~ grype alpine:latest
 ✔ Vulnerability DB                [updated]  
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ Executables                     [17 executables]  
   ├── ✔ File metadata                   [81 locations]  
   └── ✔ File digests                    [81 files]  
 ✔ Scanned for vulnerabilities     [6 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 6 low, 0 negligible

➜  ~ grype debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files]  
 ✔ Scanned for vulnerabilities     [46 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 1 medium, 5 low, 40 negligible

➜  ~ grype debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files]  
 ✔ Scanned for vulnerabilities     [46 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 1 medium, 5 low, 40 negligible

We see 0 vulnerabilities in the Alpine image and 46 vulnerabilities in the Debian image. Now this doesn’t make Debian worse, they have limited time and fix the most dangerous vulnerabilities first. It’s 1 medium, 5 low, and 40 negligible. It’s pretty clear the Debian security folks are staying on top of all this.

Keep in mind that Debian has a lot more software than you get in an Alpine image. There are many problems that are easier to solve with Debian than Alpine because it has more software available. There are also problems that are easier to solve with Alpine because it has less software.

In the case of hardened container images, if our primary problem is justifying security findings, you’re going to have less work to do if you have fewer vulnerabilities. Less software means fewer vulnerabilities. This seems like a pretty easy logical conclusion. Even when a security vulnerability is marked as “negligible” as we see in the above Debian report, security and compliance auditors will want a justification. Those justifications come with a cost. We can remove that cost by just not having those vulnerabilities present. One way to get fewer vulnerabilities is to ship less software. This is that case where Alpine solves a problem Debian doesn’t.

Of course we could try to build our own tiny variant of Debian. Is that a problem we want to solve? The care and feeding of container base images has been solved by many other companies and open source projects. If you need a giant image full of stuff, or a small image that only contains what you need. This is one of those classic situations where you can use an existing solution to solve a problem. You don’t generate your own electricity, you pay a utility. Why are you trying to manage the operating system in your container images?

As we see more compliance standards becoming the reality for software producers. We are going to see more hardened container images emerge, these things are here to stay. They solve real problems. The thing to keep an eye on in the future is what other common problems that mandatory compliance creates?

Hardened container images aren’t the end goal of meeting your compliance requirements, they are the first step in a long journey. There are many stages to release software and services. We’re going to see increasing attention to how we build our software, what the dependencies are, what the vulnerabilities in those dependencies are. There won’t be a single simple answer for any of these new requirements. However, now that we have some requirements we can start to figure out the best way to solve these new problems.

This is exactly why Anchore recently announced a strategic partnership with Chainguard, one of the leading companies in the hardened container space. The partnership recognizes something important: starting with secure, hardened container images is just the beginning. You also need continuous scanning, policy enforcement, and compliance monitoring as you build your own code on top of those secure foundations. It’s a “Start Safe, Stay Secure and Compliant” approach that acknowledges hardened images solve the base layer problem, but you still need to manage everything else in your software supply chain.

At Anchore we don’t think we can solve every problem, but we do think the combination of starting with hardened images and applying continuous security practices like SBOMs and policy evaluations throughout your development lifecycle is the most practical way forward in this new compliance world.

Learn how Chainguard’s hardened images and Anchore Enterprise’s SBOM-powered, vulnerability scanning and policy enforcement reduce audit effort and accelerate entry into new markets.

Watch Now

In 2018, Anchore partnered with the US Air Force on Platform One, a project focused on integrating DevSecOps principles into government software development. A core part of that project was the launch of the Iron Bank, a repository of container images hardened with Anchore’s software to remove security issues before deployment. This accelerated compliance status for the US government. Chainguard now champions the concept of hardened container images for the broader market. Today, we formally partner with Chainguard, enabling our customers to “Start Safe, Stay Secure and Compliant.”

Our joint partnership focused on guaranteeing seamless workflows between both products for our customers. Chainguard Images allow customers to start with hardened images with close to zero vulnerabilities. Anchore Enterprise scans images correctly, generating no false positives; then continuously monitors images for compliance as developers add code, guiding them on upgrades.

As the compliance burden increases from governmental regulations such as FedRAMP, DORA, NIS2, and CRA, customers can use Anchore and Chainguard to achieve compliance faster by avoiding the costly burden of triaging and patching security issues. 

Default-to-Secure with Chainguard Images

Vulnerability management has become both more essential and challenging in recent years.

The pervasive use of open source software, often of varying quality, combined with the rise of novel supply chain attacks, means almost all software now contains vulnerabilities. Consequently, developers are bombarded with a long list of security issues as part of their very first build. 

Chainguard provides hardened images, removing many vulnerabilities before development even begins. Developers can focus on the security of their own code and not the operating system underneath. Rather than shift more issues left to developers, the goal is to shift issues out of the view of the developers entirely.

However, if the vulnerability management tools in place are not tested or configured properly, there is a risk of content being misidentified and packages erroneously flagged as being vulnerable. Anchore and Chainguard have partnered to ensure that Anchore’s results are always up to date with the latest fixes from Chainguard and no false positives are generated. Beyond vulnerabilities, Chainguard’s published SBOMs for the base images have been tested for consistency with the automatic SBOMs that Anchore generates throughout the SDLC.

Continuous Compliance with Anchore Enterprise

Hardened images offer developers a cleaner starting point, but ongoing scanning remains essential. Once developers add their code, with its own dependencies from GitHub or other upstream repositories, they must ensure no new vulnerabilities are introduced.

Continuous scanning with Anchore Enterprise

Anchore Enterprise will highlight vulnerabilities discovered in higher-level code not present in the base Chainguard image, directing developers only to fixes they can take action against.  Anchore can also generate a list of vulnerable base images with critical CVEs, indicating when the images are stale and require upgrading from the Chainguard catalog. It is important to note that unlike other tools which need ongoing access to the original image or asset, the Anchore assessment is done continuously whenever new vulnerabilities are published. This means alerts for new issues go out immediately as soon as the data is received.

Our out-of-the-box policy packs immediately flag any findings that cause an environment to go out of compliance, prompting developer or security teams to follow up. Examples may include unencrypted secrets, incorrect file permissions, or exposed ports – all of which are explicitly called out in various US and European standards. 

The Anchore Policy Engine also allows you to test images against multiple controls on the fly without needing to rescan the image. 

Collaboration through continuous testing and Open Source

Chainguard has a long history of contributing to our open source projects: Syft, Grype, and Vunnel. We are excited to continue working with them on an upstream first basis to support Chainguard Images and future product offerings. 

Extending the collaboration further, both Anchore and Chainguard are using each other’s commercial software as part of a continuous testing process to ensure that scans generate the best results for end users and any issues are detected early and quickly.

Join us tomorrow at 10am PT | 1 pm ET  for a live demo and discussion on this new partnership with us and Chainguard – save your seat here.

Learn how Chainguard’s hardened images and Anchore Enterprise’s SBOM-powered, vulnerability scanning and policy enforcement reduce audit effort and accelerate entry into new markets.

Save a Seat

Every modern application is built on a foundation of open source dependencies. Dozens, hundreds, sometimes thousands of packages can make up a unit of software being shipped to production. Each of these packages carries its own license terms. A single incompatible license deep in your dependency tree can create legal headaches, force costly rewrites, or even block a product release. 

What looks like a routine compliance task can quickly turn into what some have called “death by a thousand cuts”. Every weekend disappears into spreadsheets, combing through packages, trying to spot the legal landmines buried in the latest snapshot of a software supply chain. The danger doesn’t normally come from the obvious places but from the invisible depths of transitive dependencies—the “dependencies of dependencies”—where one unexpected license could derail an entire product.

As software supply chains grow more complex, manual license review becomes an intractable method. That’s where Grant comes in. We’ve rebuilt key parts of Syft to make SBOM license inspection for Golang packages smarter, while also updating Grant’s config to allow for stricter policies that are easier to use.

90% improvements on license inspection for Golang modules

At its surface, the package detection problem for Golang seems straight forward. Give me the go.mod, enumerate all the entries, build the package list…done!. In actuality, it’s a lot more complicated if you want the licenses.  When we tested Grant’s new Golang module integration on the MinIO Golang client (a popular S3-compatible storage solution), the new results for licenses detection were very promising:

• Before: 295 packages with undetected licenses (go.mod approach)
• After: Only 29 missing licenses – a 90% improvement (golang source inspection)

Each undetected license carries potential harm such as:

• A competitor claiming code ownership
• A consumer forced to open-source proprietary features
• Personal liability for engineering leaders

For a company preparing for acquisition or IPO, having 295 unknown licenses in their SBOM could delay due diligence. With Grant’s improvements, that same audit/inspection can now isolate the problem packages and figure out what licenses are missing.

Stronger Policies for Safer (and Faster) Compliance

Detect Unlicensed Packages

“No license” cases are now flagged by default. This closes gaps where unlicensed code could slip through and gives organizations clearer control over compliance risks. If it’s ok that a package has no licenses, it’s quick to add it to the exceptions list for a green CI.

Understanding License Families

Grant now categorizes licenses into risk-based families, making it easier to create policies that match your organization’s risk tolerance. We create the following classification to help teams quickly identify which dependencies need legal review versus which can be auto-approved :

Strong Copyleft (High Risk): GPL, AGPL, SSPL

• Requires derivative works to use the same license
• Can “infect” proprietary code with open source obligations
• Example policy: deny: ["GPL-*", "AGPL-*"]

Weak Copyleft (Medium Risk): LGPL, MPL, EPL

• More permissive than strong copyleft
• Allows linking without license propagation
• Example policy: allow: ["LGPL-*"] # but review usage context

Permissive (Low Risk): MIT, Apache-2.0, BSD

• Minimal restrictions on reuse
• Generally safe for commercial products
• Example policy: allow: ["MIT", "Apache-2.0", "BSD-*"]

Easier, Cleaner Configuration

The old .grant.yaml was powerful but too verbose and hard to manage. Users told us it was unwieldy, repetitive, and full of boilerplate. We rebuilt the configuration system with sensible defaults and simpler patterns.

👉 The result: policies that used to take ~50 lines can now be expressed in ~15.

Before: Verbose & Rule-Heavy

#.grant.yaml

rules:
  - pattern: "BSD-*"
    name: "bsd-allow"
    mode: "allow"
    reason: "BSD is compatible with our project"
    exceptions:
      - my-package # denied for this package
  - pattern: "MIT"
    name: "mit-allow"
    mode: "allow"
    reason: "MIT is compatible with our project"
  - pattern: "*"
    name: "default-deny-all"
    mode: "deny"
    reason: "All licenses need to be explicitly allowed"

#.grant.yaml

rules:
  - pattern: "BSD-*"
    name: "bsd-allow"
    mode: "allow"
    reason: "BSD is compatible with our project"
    exceptions:
      - my-package # denied for this package
  - pattern: "MIT"
    name: "mit-allow"
    mode: "allow"
    reason: "MIT is compatible with our project"
  - pattern: "*"
    name: "default-deny-all"
    mode: "deny"
    reason: "All licenses need to be explicitly allowed"

After: Streamlined & User-Friendly

# Default: DENY all licenses (including no-license packages)

require-license: true
require-known-license: false
allow:
  - MIT
  - MIT-*
  - Apache-2.0
  - Apache-2.0-*
  - BSD-2-Clause
  - BSD-3-Clause
  - BSD-3-Clause-Clear
  - ISC
  - 0BSD
  - Unlicense
  - CC0-1.0
ignore-packages:
  - github.com/mycompany/*  # Our own Go modules

# Default: DENY all licenses (including no-license packages)

require-license: true
require-known-license: false
allow:
  - MIT
  - MIT-*
  - Apache-2.0
  - Apache-2.0-*
  - BSD-2-Clause
  - BSD-3-Clause
  - BSD-3-Clause-Clear
  - ISC
  - 0BSD
  - Unlicense
  - CC0-1.0
ignore-packages:
  - github.com/mycompany/*  # Our own Go modules

The new format is:

• Shorter – no more repetitive rule definitions
• Clearer – defaults make intent obvious (deny all unless explicitly allowed)
• More flexible – glob patterns and ignore-packages handle common exceptions

CI/CD Upgrades with --dry-run and --allow-failure

Not every scan should block your build. Based on feedback from teams running Grant in CI/CD, we’ve added two new flags for more control:

• --dry-run — preview scan results without enforcing policy
• --allow-failure — let pipelines continue even if violations are found

These options make it easier to adopt Grant incrementally: start in “report-only” mode, then turn on strict enforcement when it fits your needs.

Smarter Package Discovery

Golang Toolchain Integration

The latest update builds Golang package licenses by using golang.org/x/tools/go/packages to build a full import graph, detect the main module, and pull licenses from the Golang module cache. If the toolchain isn’t available, we gracefully fall back to go.mod. This approach catches transitive dependencies that other tools might miss and handles complex scenarios like replace directives and local modules.

Under the Hood: How Go Module Discovery Works

Grant’s new Golang integration enhances how we discover licenses for dependencies:

1. Build-time analysis: We hook into golang.org/x/tools/go/packages to construct the actual import graph—not just what’s declared in go.mod, but what’s actually used.
   
2. Module cache mining: Instead of crawling vendor directories, we pull licenses directly from Go’s module cache, ensuring we get the canonical license files.
   
3. Graceful degradation: No Go toolchain? No problem. Grant still constructs the SBOM and grabs what licenses it can in the current directory’s context. It just won’t be as powerful as it is when combined with the go tool chain knowledge.

Expanded Package Type Support

Grant now leverages Syft’s enhanced cataloging capabilities to detect licenses across more package ecosystems:

• Cataloging snap packages with transitive package support and their included licenses
• Conda ecosystem support when license location available
• Better license detection with over 1400 URL-to-license mappings

Better Data, Faster Runs

SPDX Upgrade

Added ~1,400 new URL-to-license mappings, improved lookups, and upgraded the SPDX license list from 3.22 → 3.27. Deprecated URLs now resolve cleanly to replacements.

Focused Crawling

License detection is now limited to common filenames (LICENSE, COPYING, NOTICE, etc.), avoiding slow scans through irrelevant directories. Users even have the ability to turn off Grant’s scanning feature with --disable-file-search if they trust the content of their SBOM.

In prior releases large directories of files would give grant issues since it would try to read the contents of every file to look for license evidence:

$ npx create-react-app . --template minimal

$ grant check .
~/d/test (main)> grant check .
 ⠹ Checking licenses  ━━━━━━━━━━━━━━━━━━━━

$ npx create-react-app . --template minimal

$ grant check .
~/d/test (main)> grant check .
 ⠹ Checking licenses  ━━━━━━━━━━━━━━━━━━━━

The above would balloon a workstation’s memory usage and take about 3-4 cups of coffee before finishing its task.

With this change we see this process execute in a shorter amount of time.

$ time grant check dir:.
                                                                                                                          
Target: dir:. (directory)
Status: ✗ NON-COMPLIANT

Summary:
  Packages: 1289 total, 1289 denied, 43 unlicensed
  Licenses: 15 unique, 15 denied

Denied Packages (1256):
...........................
________________________________________________________
Executed in    2.87 secs    fish           external
   usr time    2.22 secs    0.21 millis    2.22 secs
   sys time    1.26 secs    1.22 millis    1.26 secs

$ time grant check dir:.
                                                                                                                          
Target: dir:. (directory)
Status: ✗ NON-COMPLIANT

Summary:
  Packages: 1289 total, 1289 denied, 43 unlicensed
  Licenses: 15 unique, 15 denied

Denied Packages (1256):
...........................
________________________________________________________
Executed in    2.87 secs    fish           external
   usr time    2.22 secs    0.21 millis    2.22 secs
   sys time    1.26 secs    1.22 millis    1.26 secs

The secret? Focused crawling that skips irrelevant files and parallel license classification. The new --disable-file-search flag can also reduce scan times by another 40% when you only need licenses that are found in the SBOM and associated packages.

TLDR; Top 5 Grant Improvements

With this update, Grant is:

1. Stricter where it counts, by detecting unlicensed packages
2. Simpler to configure with defaults that reflect real-world needs
3. Safer to adopt in CI/CD with dry-run and allow-failure modes
4. Smarter for Go projects and other ecosystems with toolchain-backed cataloging
5. Faster across large repositories with reduced crawl time

Together these improvements make Grant a sharper, safer tool for software license inspection and evaluation.

And This Is What’s Next

This release sets the foundation for what’s coming next:

• Configuration templates: Pre-built license configurations for common scenarios
• License remediation hints: Automated suggestions for replacing problematic dependencies
• MCP integration: Real-time license feedback from your favorite AI agent
• SBOM enrichment: Adding edited/discovered licenses back into your SBOMs

Try it yourself

$ grant check dir:.

$ grant check dir:.

Join us on September 18 for our live webinar where we demo the latest functionality.

Save a Seat

Questions? Issues? Join the discussion at anchore.com/discourse or reach out and file an issue!

Grant is part of Anchore’s open source toolkit for software supply chain security. Learn more about our complete SBOM and vulnerability management solutions at anchore.com.

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

On September 8, 2025 Anchore was made aware of an incident involving a number of popular NPM packages to insert malware. The technical details of the attack can be found in the Aikido blog post: npm debug and chalk packages compromised

After an internal audit, Anchore determined no Anchore products, projects, or development environments ever downloaded or used the malicious versions of these packages.

Anchore Enterprise and Grype both use the GitHub Advisory Database to source the vulnerability data for NPM packages. Since this database also includes malware packages such as this, both Anchore Enterprise and Grype will detect these malware packages if they are present.

The databases used by Anchore Enterprise and Grype will auto update on a regular basis. However, given the severity of this malware, users of Anchore Enterprise and Grype can update their feed database manually to ensure they are able to detect the malicious packages from this incident.

Grype users should run:

$ grype db update

$ grype db update

Which will download the updated vulnerability database.

Anchore Enterprise users can run:

$ anchorectl feed sync

$ anchorectl feed sync

Which will download the latest version of the vulnerability database.

Once the databases are updated, both Grype and Anchore Enterprise identify the malware in question. You can verify the vulnerability ID is found in your vulnerability dataset with the following API call:

$ curl -u ${ANCHORE_USER}:${ANCHORE_PASS} -H 'x-anchore-account: {account_context} -X 'GET' "$ANCHORE_URL/v2/query/vulnerabilities?id=GHSA-5g7q-qh7p-jjvm&page=1" -k

$ curl -u ${ANCHORE_USER}:${ANCHORE_PASS} -H 'x-anchore-account: {account_context} -X 'GET' "$ANCHORE_URL/v2/query/vulnerabilities?id=GHSA-5g7q-qh7p-jjvm&page=1" -k

And then you can locate affected artifacts by using reports:

Timeline

[1830UTC] Anchore Enterprise and Grype start rebuilding the vulnerability databases to properly detect these malicious packages

[1930UTC] Anchore Enterprise vulnerability database is published

[2015UTC] Grype vulnerability database is published

If you develop or use software, which in 2025 is everyone, it feels like everything is starting to change. Software used to exist in a space where we could do almost anything they wanted and it didn’t seem like anyone was really paying attention. We all heard stories about mission critical Windows 95, still running today. Or running a version of Log4j older than the interns have been alive. Some will view it as some sort of golden age of software, to others it was the darkest of ages with no accountability. No matter what you think about how things used to work, we are on the precipice of change in the world of software development.

If you try to ask why things are starting to change, you’re going to get a multitude of answers. The why doesn’t really matter though, we need to understand the how. What is going to change? What should we be paying attention to? Anyone working on software will need to know what they have to pay attention to now. The what in this instance is compliance, a lot of new compliance standards.

So what are these standards we all need to start paying attention to? There’s not enough time to hit them all here, but a few names you’re going to start hearing more about are the EU Cyber Resilience Act (CRA), the Product Liability Directive (PLD). Secure Software Development Framework (SSDF), Cybersecurity in Medical Devices (everyone seems to be calling this “FDA”). And there are even more industry specific standards starting to emerge like PCI. We will cover all these and more over the course of this blog series.

What we’re seeing now is that the sort of compliance in healthcare doesn’t look like the compliance in automotive or financial. And then there are even broader things like the EU CRA that will cover everyone and everything. One of our challenges moving forward is figuring out which standards apply where and what needs to change. This can include the markets we sell into, the type of product we’re selling, the service(s) we’re providing. There won’t be any easy answers and we will all have to figure this out. 

There’s a term I really like I heard someone use the other day: CompOps to build on the SecDevSecOpsSec sort of naming. Compliance Operations. A few years ago this could be dismissed as a weird and boring term, but as we see compliance everywhere we look, it’s going to be more important than ever to incorporate compliance into how we build and distribute software. Thinking about this with a DevOps mindset might be the only reasonable way forward.

We should take a moment to note the software industry is not special with all these new compliance standards. Virtually every existing industry has standards they must adhere to. Issues like food safety, human safety, auto safety, too many topics to list. Compliance is nothing new, we are not special. We’re finally catching up to everyone else.

While every one of these standards has different requirements. And we will of course cover many of those differences, there are certain things they all seem to have in common. The two that are probably easiest to understand and unpack are Software Bill of Materials (SBOMs) and vulnerabilities. At Anchore this is something we’ve been thinking about and working on for a very long time. Our SBOM and vulnerability projects Syft and Grype were created in 2020, and we had a tool called Anchore Engine before that. 

Let’s start with SBOMs. Just because a compliance standard says you need an SBOM, that’s not necessarily helpful. What format does it need to be in? How are you supposed to store the SBOM? How long are you supposed to keep an SBOM around? Do you need to publish it on your website? Give it to customers, or regulators, or some other group? It’s one of those things that can seem really easy, but the devil is always in the details. We can answer some of these questions today, but some of them are going to evolve over time as the intention of regulators becomes more clear.

Vulnerabilities aren’t any easier, but might be a more tractable problem. You just need to release software that doesn’t have any vulnerabilities! That’s probably not easier than SBOMs. But recently we’ve seen very small hardened containers images show up that can make a huge difference with vulnerability wrangling. This doesn’t solve the problem of vulnerabilities in your dependencies and own code. But it will certainly free up your time to focus on your product rather than the things in your container base image.

Before we get to our exciting conclusion, it’s important to understand that all these compliance standards are going to have unintended consequences. There will be second and third order effects that create new problems while trying to solve the original problem. That’s how new standards work. It will be important for all of us to give feedback to the governing bodies of all these standards. They do listen and generally try to do the right things.

So what happens now? If you’ve never been involved in compliance standards before, this can all feel extremely overwhelming. It’s OK to panic for a little while, this sort of change is a big deal. There are a lot of resources available to help us all out. There are companies that can help us out. Plenty of people have made a career out of making compliance easy (or at least less hard).

This post is the start of a series where Anchore is going to help break down and explain many of the SBOM and software supply chain requirements in these standards. Helping out with SBOM requirements is something we’ve been working on for years. We knew SBOMs were going to end up in compliance standards, we just didn’t think it would happen so suddenly!

If this is your new reality, stay with us. We’ll be diving deep into each major standard, providing practical implementation guidance, and sharing what we’ve learned from organizations that are already ahead of the curve. Subscribe to our newsletter or follow us on LinkedIn to get these insights delivered directly to your inbox, because staying informed isn’t just a nice-to-have anymore: it’s a must-have.

Josh Bressers is Vice President of Security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers.

Learn about the role that SBOMs for the security of your organization in this white paper.

Download Now

If you’re just joining us, this is part 2 of a series on practical implementation of software supply chain security to meet the most recent SBOM compliance requirements. In Part 1, we covered the fundamentals of automated SBOM generation—from deployment options to registry integration to vulnerability analysis across any container infrastructure. With your SBOMs now flowing into Anchore Enterprise, the real compliance value begins to emerge.

Part 2 focuses on the operational aspects that turn SBOM data into actionable compliance outcomes: 

• automated policy evaluation, 
• custom rule creation for your specific regulatory requirements, and 
• comprehensive reporting that satisfies auditors while providing actionable insights for development teams.

Whether you’re pursuing PCI DSS 4.0 compliance, preparing for the EU Cyber Resilience Act, or building frameworks for future regulatory requirements, these capabilities transform compliance from overhead into competitive advantage.

Learn about the role that SBOMs for the security of your organization in this white paper.

Download Now

Checking your container SBOMs (for compliance)

With high fidelity SBOMs now present in Anchore Enterprise, the system will automatically perform policy evaluations against them. This is important in order to establish a baseline for container image compliance with checks against various policies.

NOTE: When a container image is added, policy compliance checks are automatically applied against the SBOM in accordance with the default policy.

In the Anchore Enterprise UI, navigate to an image. The first page visible will be the policy and compliance evaluation summary.  From here you can inspect the policy evaluation results and the recommended action by the policy, for example the rule which was triggered and the resultant action (such as STOP or WARN):

You may wish to export a compliance report to deliver feedback to application teams or other stakeholders, asking them to please fix or remediate these items. You can get this report from the UI at the click of a button:

NOTE: A compliance report can be downloaded in either json or csv format.

With application teams busy taking remedial action, they can build a new image and Anchore Enterprise can generate an SBOM from this and conduct another policy evaluation. 

NOTE: It’s possible to watch a given tag which will ensure whenever a new version is pushed, it will be automatically scanned by Anchore Enterprise. 

You can also use the CLI and API (via AnchoreCTL) for checking your container SBOM (for compliance). This is particularly useful when working with Anchore Enterprise and SBOMS in the development pipeline. To conduct a policy check on a newly built image, run the following command to compare with the default policy:

$ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag –detail

$ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag –detail

You can also fail based on the results of this evaluation with the following -f flag:

$ anchorectl image check -f aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag

$ anchorectl image check -f aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag

NOTE: The pass/fail evaluation result is useful for integration into CI/CD pipelines as it sets the exit code to “1” on a fail to halt the pipeline.

You can also export the compliance report using the CLI:

$ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -o json > <file_name.json>

$ anchorectl image check aws_account_id.dkr.ecr.region.amazonaws.com/repository:tag -o json > <file_name.json>

NOTE: The AnchoreCTL utility supports exporting the results in various formats (i.e., json, text, csv, json-raw, and id) with the -o flag. Text is the default format.

Both UI and CLI (AnchoreCTL) compliance management are described in further detail here.

Customising Policy (for compliance posture)

Using Anchore Enterprise’s policy engine, you can build a set of custom rules which map to your own organizational policy. Alternatively, if you are pursuing FedRAMP compliance, you can use optional policy packs which are available as addons for the product. 

NOTE: Multiple policies are supported by Anchore Enterprise. However, only one policy can be set as active/default at any time. 

In order to build or customize your own policy, you can navigate to the desired policy and begin editing the rulesets.

From the Policies (UI) page, you can view any policies listed under Policy Manager and select a given policy for editing.

When editing a policy, you can then view all rulesets associated with it and select a ruleset for editing.

When editing a ruleset, the recommended actions (STOP/WARN/GO) can be modified when a ruleset is triggered on policy evaluation.

The ruleset parameters can also be modified to change the existing values.

You can also use CLI tooling to gather certain aspects related to a policy.

To list all policies both active and inactive:

$ anchorectl policy list

$ anchorectl policy list

To list the rulesets associated with a policy (including names and actions):

$ anchorectl policy get <The policy name or ID>

$ anchorectl policy get <The policy name or ID>

Downloading Account-Wide Compliance Reports

Sometimes you need to demonstrate your compliance with policy at the account-level or across multiple accounts. Anchore Enterprise allows you to do just that with its Reporting feature. Anchore Enterprise Reports as it’s known aggregates data across all accounts to: 

1. Maintain a summary of all current and historical images/tags, and 
2. Maintain vulnerability reports and policy evaluations for these respective images and tags.

From the Reports (UI) page, you can generate a “New Report” based on pre-defined system templates and filters.

The first dropdown allows you to select one of the included templates for generating a report.

In turn, the second dropdown allows you to select one or more report filters.

After selecting your template and report filter(s), you can also toggle between generating a report for the account you’re logged into or for all accounts.

From the “Templates” tab, you can view all the current system templates or even any custom templates as you have the capability to create your own (templates).

Once you’re ready to generate a report, it can either be downloaded in csv or json (native/raw) format or saved for later reference and run later either ad-hoc or on a schedule.

NOTE: Reporting is described in further detail here.

Wrap-Up

The journey from SBOM generation to automated compliance demonstrates how regulatory requirements can drive meaningful security improvements rather than just administrative overhead. Organizations that embrace this automated approach aren’t just meeting current compliance deadlines—they’re building resilient supply chain security practices that scale with their business growth.

Throughout this two-part series, we’ve seen how Anchore Enterprise transforms complex regulatory requirements into manageable, automated workflows. From initial SBOM generation across diverse container registries to sophisticated policy enforcement and comprehensive reporting, the platform provides continuous visibility into security risks while streamlining compliance processes.

The strategic advantage becomes clear when comparing manual approaches to automated SBOM management. Manual processes create bottlenecks that slow development cycles and generate compliance debt that compounds over time. Automated approaches integrate compliance checking into existing workflows, providing real-time feedback that helps development teams build more secure applications from the start.

As regulatory requirements continue expanding globally, organizations with robust SBOM management capabilities will find themselves better positioned to adapt quickly to new requirements. The foundation built for PCI DSS 4.0 and EU Cyber Resilience Act compliance provides the framework needed for whatever regulatory changes emerge next.

The choice facing organizations today isn’t whether to implement SBOM management—it’s whether to build sustainable, automated practices that turn compliance into competitive advantage or to continue with manual approaches that become more unsustainable with each new regulatory requirement. The 2025 compliance deadlines mark the beginning of this new reality, not the end.

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

For the last 7 years CISA has been one of the major public stewards of SBOMs – publishing many whitepapers, hosting a multitude of meetings, and evangelizing the term so nearly everyone in the industry now recognizes. For those of us who have been working in the SBOM community over the years, one of the best meetings was a Monday morning SBOM community call (morning if you’re in the US, not morning most everywhere else on the planet). The agenda usually started with an informal discussion about news and events and moved to a semi formal presentation about a tool or idea that was being worked on. Occasionally the discussions lasted the entire hour and the topics were always informative and interesting.  

As the world of SBOMs has grown, one of the biggest challenges is just keeping track of everything; There are too many events, tools and talks and it is impossible for one person to be on top of it all. And that’s why the Monday community meeting was so useful to its attendees. Even if you weren’t trying to actively keep track of the SBOM universe, the SBOM universe would come to you! 

Unfortunately the Monday community meeting has recently been discontinued. It’s tough to keep a meeting like this going, especially for many years, so hats off to CISA for all the hard work! That meeting shall be missed, but we can all respect the need to focus the existing resources to better align with the CISA mission.

But given how valuable the CISA meeting has been, a few of us at the OpenSSF have decided we miss the meeting and would like to keep it going. So the OpenSSF SBOM Coffee Club has been started! Same time on Monday as the CISA meeting (11am Eastern). The format is going to be exactly the same: Show up, discuss the latest news and happenings and share interesting SBOM related events. Just like the CISA list of SBOM events, this one will be pretty flexible and only need to be vaguely SBOM related to deserve a mention.

One of the often overlooked aspects of building a community are the little things that bring everyone together. I’ve been part of many communities over the years, I am honored to be part of the SBOM community now. While our community is built on top of SBOMs, that’s not enough to keep everyone connected. We need a place to discuss topics, share experiences, and talk about new things and ideas, and most importantly, let new people find us. That was the Monday SBOM call. It’s important to me and others to keep a place going that can help the existing community thrive and bring in new people in a safe and welcoming way.

Everyone is welcome, it doesn’t matter if you’re not an OpenSSF member. The invite is available on the OpenSSF public calendar (it’s pretty full of events, look for “OpenSSF SBOM Coffee Club” on Monday. You are welcome to check out the notes document. This will be updated before and during the meeting each week. Even if you don’t attend you are welcome to keep track of what’s happening from the meeting notes. We’ve quite literally copied the events list from the last CISA call and we are going to keep it updated.

I hope to see you at a future meeting to learn, to share and evangelize. I promise you will learn something. And if you have an idea to present, or a tool, or anything really, reach out to the group. See you next Monday!

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

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

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

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

Solution Overview

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

Deployment Options:

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

Above: A typical Cloud Image-based deployment

Above: A typical Container Image deployment on Amazon EKS

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

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

SBOM Generation Methods

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

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

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

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

Connecting to Container Registries

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

For Cloud Registries:

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

For Private Registries:

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

Example: Configuring Amazon ECR Access

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

With appropriate permissions configured, add your registry:

# For AWS ECR

$ ANCHORECTL_REGISTRY_PASSWORD=awsauto anchorectl registry add \

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

  --username awsauto --type awsecr

# For other registries, authentication varies:

# Docker Hub

$ anchorectl registry add docker.io --username your_username

# Harbor

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

# Confirm the registry has been added:

$ anchorectl registry list

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

Generating SBOMs from Container Images

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

# Add images from any supported registry

$ anchorectl image add registry_url/repository:tag

# Examples for different registries:

# AWS ECR

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

# Azure ACR  

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

# Google GCR

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

# Harbor

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

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

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

# Verify images have been added:

$ anchorectl image list

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

Inspecting Container SBOMs for Vulnerabilities

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

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

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

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

# View all vulnerabilities in an image

$ anchorectl image vulnerabilities registry_url/repository:tag -t all

# Export vulnerability data for further processing

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

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

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

Inspecting Container SBOMs for Additional Content

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

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

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

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

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

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

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

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

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

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

SBOM:

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

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

What’s Next

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

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

Learn about the role that SBOMs for the security of your organization in this white paper.

Download 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.