Tag: Software Supply Chain Security

Security engineers at modern enterprises face an unprecedented challenge: managing software supply chain risk without impeding development velocity, all while threat actors exploit the rapidly expanding attack surface. With over 25,000 new vulnerabilities in 2023 alone and supply chain attacks surging 540% year-over-year from 2019 to 2022, the exploding adoption of open source software has created an untenable security environment. To overcome these challenges security teams are in need of tools to scale their impact and invert the they are a speed bump for high velocity software delivery.

If your DevSecOps pipeline utilizes the open source Harbor registry then we have the perfect answer to your needs. Integrating Anchore Enterprise—the SBOM-powered container vulnerability management platform—with Harbor offers the force-multiplier security teams need. This one-two combo delivers:

• Proactive vulnerability management: Automatically scan container images before they reach production
• Actionable security insights: Generate SBOMs, identify vulnerabilities and alert on actionable insights to streamline remediation efforts
• Lightweight implementation: Native Harbor integration requiring minimal configuration while delivering maximum value
• Improved cultural dynamics: Reduce security incident risk and, at the same time, burden on development teams while building cross-functional trust

This technical guide walks through the implementation steps for integrating Anchore Enterprise into Harbor, equipping security engineers with the knowledge to secure their software supply chain without sacrificing velocity.

Learn the essential container security best practices to reduce the risk of software supply chain attacks in this white paper.

Download Now

Integration Overview

Anchore Enterprise can integrate with Harbor in two different ways—each has pros and cons:

Pull Integration Model

In this model, Anchore uses registry credentials to pull and analyze images from Harbor:

• Anchore accesses Harbor using standard Docker V2 registry integration
• Images are analyzed directly within Anchore Enterprise
• Results are available in Anchore’s interface and API
• Ideal for organizations where direct access to Harbor is restricted but API access is permitted

Push Integration Model

In this model, Harbor uses its native scanner adapter feature to push images to Anchore for analysis:

• Harbor initiates scans on-demand through its scanner adapter as images are added
• Images are scanned within the Anchore deployment
• Vulnerability scan results are stored in Anchore and sent to Harbor’s UI
• Better for environments with direct access to Harbor that want immediate scans

Both methods provide strong security benefits but differ in workflow and where results are accessed.

Setting Up the Pull Integration

Let’s walk through how to configure Anchore Enterprise to pull and analyze images from your Harbor registry.

Prerequisites

• Anchore Enterprise installed and running
• Harbor registry deployed and accessible
• Harbor user account with appropriate permissions

Step 1: Configure Registry Credentials in Anchore

1. In Anchore Enterprise, navigate to the “Registries” section
2. Select “Add Registry”

3. Fill in the following details:

Registry Hostname or IP Address: [your Harbor API URL or IP address, e.g., http://harbor.yourdomain.com]

Name: [Human readable name]

Type: docker_v2

Username: [your Harbor username, e.g., admin]

Password: [your Harbor password]

4. Configure any additional options like SSL validation if necessary
5. Test the connection
6. Save the configuration

Step 2: Analyze an Image from Harbor

Once the registry is configured, you can analyze images stored in Harbor:

1. Navigate to the “Images” section in Anchore Enterprise
2. Select “Add Image”

3. Choose your Harbor registry from the dropdown
4. Specify the repository and tag for the image you want to analyze
5. Click “Analyze”

Anchore will pull the image from Harbor, decompose it, generate an SBOM, and scan for vulnerabilities. This process typically takes a few minutes depending on image size.

Step 3: Review Analysis Results

After analysis completes:

1. View the vulnerability report in the Anchore UI
2. Check the generated SBOM for all dependencies
3. Review compliance status against configured policies
4. Export reports or take remediation actions as needed

Setting Up the Push Integration

Now let’s configure Harbor to push images to Anchore for scanning using the Harbor Scanner Adapter.

Prerequisites

• Harbor v2.0 or later installed
• Anchore Enterprise deployed and accessible
• Harbor Scanner Adapter for Anchore installed

Step 1: Deploy the Harbor Scanner Adapter

If not already deployed, install the Harbor Scanner Adapter for Anchore:

1. Download or copy the harbor-adapter-anchore.yaml template from our GitHub repository
2. Customize the template for your Harbor deployment. The required fields are:

ANCHORE_ENDPOINT 

ANCHORE_USERNAME 

ANCHORE_PASSWORD

3. Apply the Kubernetes manifest:

kubectl apply -f harbor-adapter-anchore.yaml

Step 2: Configure the Scanner in Harbor

1. Log in to Harbor as an administrator
2. Navigate to “Administration” → “Interrogation Services”
3. In the “Scanners” tab, click “New Scanner”

4. Enter the following details:

Name: Anchore

Description: Anchore Enterprise Scanner

Endpoint: http://harbor-scanner-anchore:8080

Auth: None (or as required by your configuration)

5. Save and set as default if desired

Step 3: Configure Project Scanning Settings

For each project that should use Anchore scanning:

1. Navigate to the project in Harbor
2. Go to “Configuration”
3. Enable “Automatically scan images on push” AND Enable “Automatically generate SBOM on push”

4. Save the configuration

Step 4: Test the Integration

1. Tag an image for your Harbor project:

docker tag my-test-application:latest harbor.yourdomain.com/project-name/my-test-application:latest

2. Push the image to Harbor:
   

docker push harbor.yourdomain.com/project-name/my-test-application:latest

3. Verify the automatic scan starts in Harbor
4. Review the results in your Harbor UI once scanning completes

Advanced Configuration Features

Now that you have the base configuration working for the Harbor Scanner Adapter, you are ready to consider some additional features to increase your security posture.

Scheduled Scanning

Beyond on-push scanning, you can configure scheduled scanning to catch newly discovered vulnerabilities in existing images:

1. In Harbor, navigate to “Administration” → “Interrogation Services” → “Vulnerability”

2. Set the scan schedule (hourly, daily, weekly, etc.)
3. Save the configuration

This ensures all images are regularly re-scanned as vulnerability databases are updated with newly discovered and documented vulnerabilities.

Security Policy Enforcement

To enforce security at the pipeline level:

1. In your Harbor project, navigate to “Configuration”

2. Enable “Prevent vulnerable images from running”
3. Select the vulnerability severity level threshold (Low, Medium, High, Critical)
4. Images with vulnerabilities above this threshold will be blocked from being pulled*

*Be careful with this setting for a production environment. If an image is flagged as having a vulnerability and your container orchestrator attempts to pull the image to auto-scale a service it may cause instability for users.

Proxy Image Cache

Harbor’s proxy cache capability provides an additional security layer:

1. Navigate to “Registries” in Harbor and select “New Endpoint”

2. Configure a proxy cache to a public registry like Docker Hub
3. All images pulled from Docker Hub will be cached locally and automatically scanned for vulnerabilities based on your project settings

Security Tips and Best Practices from the Anchore Team

Use Anchore Enterprise for highest fidelity vulnerability data

• The Anchore Enterprise dashboard surfaces complete vulnerability details
• Full vulnerability data can be configured with downstream integrations like Slack, Jira, ServiceNow, etc. 

“Good data empowers good people to make good decisions.”

—Dan Perry, Principal Customer Success Engineer, Anchore

Configuration Best Practices

For optimal security posture:

• Configure per Harbor project: Use different vulnerability scanning settings for different risk profiles
• Mind your environment topology: Adjust network timeouts and SSL settings based on network topology; make sure Harbor and Anchore Enterprise deployments are able to communicate securely

Secure Access Controls

• Adopt least privilege principle: Use different credentials per repository
• Utilize API keys: For service accounts and integrations, use API keys rather than user credentials

Conclusion

Integrating Anchore Enterprise with Harbor registry creates a powerful security checkpoint in your DevSecOps pipeline. By implementing either the pull or push model based on your specific needs, you can automate vulnerability scanning, enforce security policies, and maintain compliance requirements.

This integration enables security teams to:

• Detect vulnerabilities before images reach production
• Generate and maintain accurate SBOMs
• Enforce security policies through prevention controls
• Maintain continuous security through scheduled scans

With these tools properly integrated, you can significantly reduce the risk of deploying vulnerable containers to production environments, helping to secure your software supply chain.

If you’re a visual learner, this content is also available in webinar format. Watch it on-demand below:

Software Bill of Materials (SBOMs) are no longer optional—they’re mission-critical.

That’s why we’re excited to announce the release of our new white paper, “Unlock Enterprise Value with SBOMs: Use-Cases for the Entire Organization.” This comprehensive guide is designed for security and engineering leadership at both commercial enterprises and federal agencies, providing actionable insights into how SBOMs are transforming the way organizations manage software complexity, mitigate risk, and drive business outcomes.

From software supply chain security to DevOps acceleration and regulatory compliance, SBOMs have emerged as a cornerstone of modern software development. They do more than provide a simple inventory of application components; they enable rapid security incident response, automated compliance, reduced legal risk, and accelerated software delivery.

⏱️ Can’t wait till the end?
📥 Download the white paper now 👇👇👇

Download Now

Why SBOMs Are a Game Changer

SBOMs are no longer just a checklist item—they’re a strategic asset. They provide an in-depth inventory of every component within your software ecosystem, complete with critical metadata about suppliers, licensing rights, and security postures. This newfound transparency is revolutionizing cross-functional operations across enterprises by:

• Accelerating Incident Response: Quickly identify vulnerable components and neutralize threats before they escalate.
• Enhancing Vulnerability Management: Prioritize remediation efforts based on risk, ensuring that developer resources are optimally deployed.
• Strengthening Compliance: Automate and streamline adherence to complex regulatory requirements such as FedRAMP, SSDF Attestation, and DoD’s continuous ATO.
• Reducing Legal Risk: Manage open source license obligations proactively, ensuring that every component meets your organization’s legal and security standards.

What’s Inside the White Paper?

Our white paper is organized by organizational function; each section highlighting the relevant SBOM use-cases. Here’s a glimpse of what you can expect:

• Security: Rapidly identify and mitigate zero-day vulnerabilities, scale vulnerability management, and detect software drift to prevent breaches.
• Engineering & DevOps: Eliminate wasted developer time with real-time feedback, automate dependency management, and accelerate software delivery.
• Regulatory Compliance: Automate policy checks, streamline compliance audits, and meet requirements like FedRAMP and SSDF Attestation with ease.
• Legal: Reduce legal exposure by automating open source license risk management.
• Sales: Instill confidence in customers and accelerate sales cycles by proactively providing SBOMs to quickly build trust.

Also, you’ll find real-world case studies from organizations that have successfully implemented SBOMs to reduce risk, boost efficiency, and gain a competitive edge. Learn how companies like Google and Cisco are leveraging SBOMs to drive business outcomes.

Empower Your Enterprise with SBOM-Centric Strategies

The white paper underscores that SBOMs are not a one-trick pony. They are the cornerstone of modern software supply chain management, driving benefits across security, engineering, compliance, legal, and customer trust. Whether your organization is embarking on its SBOM journey or refining an established process, this guide will help you unlock cross-functional value and future-proof your technology operations.

Download the White Paper Today

SBOMs are more than just compliance checkboxes—they are a strategic enabler for your organization’s security, development, and business operations. Whether your enterprise is just beginning its SBOM journey or operating a mature SBOM initiative, this white paper will help you uncover new ways to maximize value.

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

SBOM (software bill of materials) generation is becoming increasingly important for software supply chain security and compliance. Several approaches exist for generating SBOMs for Python projects, each with its own strengths. In this post, we’ll explore two popular methods: using pipdeptree with cyclonedx-py and Syft. We’ll examine their differences and see why Syft is better for many use-cases.

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

Download Now

Why Generate Python Package SBOMs?

Before diving into the tools, let’s understand why generating an SBOM for your Python packages is increasingly critical in modern software development. Security analysis is a primary driver—SBOMs provide a detailed inventory of your dependencies that security teams can use to identify vulnerabilities in your software supply chain and respond quickly to newly discovered threats. The cybersecurity compliance landscape is also evolving rapidly, with many organizations and regulations (e.g., EO 14028) now requiring SBOMs as part of software delivery to ensure transparency and traceability in an organization’s software supply chain.

From a maintenance perspective, understanding your complete dependency tree is essential for effective project management. SBOMs help development teams track dependencies, plan updates, and understand the potential impact of changes across their applications. They’re particularly valuable when dealing with complex Python applications that may have hundreds of transitive dependencies.

License compliance is another crucial aspect where SBOMs prove invaluable. By tracking software licenses across your entire dependency tree, you can ensure your project complies with various open source licenses and identify potential conflicts before they become legal issues. This is especially important in Python projects, where dependencies might introduce a mix of licenses that need careful consideration.

Generating a Python SBOM with pipdeptree and cyclonedx-py

The first approach we’ll look at combines two specialized Python tools: pipdeptree for dependency analysis and cyclonedx-py for SBOM generation. Here’s how to use them:

# Install the required tools
$ pip install pipdeptree cyclonedx-bom

# Generate requirements with dependencies
$ pipdeptree --freeze > requirements.txt

# Generate SBOM in CycloneDX format
$ cyclonedx-py requirements requirements.txt > cyclonedx-sbom.json

This Python-specific approach leverages pipdeptree‘s deep understanding of Python package relationships. pipdeptree excels at:

• Detecting circular dependencies
• Identifying conflicting dependencies
• Providing a clear, hierarchical view of package relationships

Generating a Python SBOM with Syft: A Universal SBOM Generator

Syft takes a different approach. As a universal SBOM generator, it can analyze Python packages and multiple software artifacts. Here’s how to use Syft with Python projects:

# Install Syft (varies by platform)
# See: https://github.com/anchore/syft#installation
$ curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate SBOM from requirements.txt
$ syft requirements.txt -o cyclonedx-json

# Or analyze an entire Python project
$ syft path/to/project -o cyclonedx-json

Key Advantages of Syft

Syft’s flexibility in output formats sets it apart from other tools. In addition to the widely used CycloneDX format, it supports SPDX for standardized software definitions and offers its own native JSON format that includes additional metadata. This format flexibility allows teams to generate SBOMs that meet various compliance requirements and tooling needs without switching between multiple generators.

Syft truly shines in its comprehensive analysis capabilities. Rather than limiting itself to a single source of truth, Syft examines your entire Python environment, detecting packages from multiple sources, including requirements.txt files, setup.py configurations, and installed packages. It seamlessly handles virtual environments and can even identify system-level dependencies that might impact your application.

The depth of metadata Syft provides is particularly valuable for security and compliance teams. For each package, Syft captures not just basic version information but also precise package locations within your environment, file hashes for integrity verification, detailed license information, and Common Platform Enumeration (CPE) identifiers. This rich metadata enables more thorough security analysis and helps teams maintain compliance with security policies.

Comparing the Outputs

We see significant differences in detail and scope when examining the outputs from both approaches. The pipdeptree with cyclonedx-py combination produces a focused output that concentrates specifically on Python package relationships. This approach yields a simpler, more streamlined SBOM that’s easy to read but contains limited metadata about each package.

Syft, on the other hand, generates a more comprehensive output that includes extensive metadata for each package. Its SBOM provides rich details about package origins, includes comprehensive CPE identification for better vulnerability matching, and offers built-in license detection. Syft also tracks the specific locations of files within your project and includes additional properties that can be valuable for security analysis and compliance tracking.

Here’s a snippet comparing the metadata for the rich package in both outputs:

// pipdeptree + cyclonedx-py
{
  "bom-ref":"pkg:pypi/[email protected]",
  "type":"library",
  "name":"rich",
  "version":"13.9.4"
}

// Syft
{
  "bom-ref":"pkg:pypi/[email protected]",
  "type":"library",
  "author":"Will McGugan <[email protected]>",
  "name":"rich",
  "version":"13.9.4",
  "licenses":[{"license":{"id": "MIT"}}],
  "cpe":"cpe:2.3:a:will_mcgugan_project:python-rich:13.9.4:*:*:*:*:*:*:*",
  "purl":"pkg:pypi/[email protected]",
  "properties":[
    {
      "name":"syft:package:language",
      "value":"python"
    },
    {
      "name":"syft:location:0:path",
      "value":"/.venv/lib/python3.10/site-packages/rich-13.9.4.dist-info/METADATA"
    }
  ]
}

Why Choose Syft?

While both approaches are valid, Syft offers several compelling advantages. As a universal tool that works across multiple software ecosystems, Syft eliminates the need to maintain different tools for different parts of your software stack.

Its rich metadata gives you deeper insights into your dependencies, including detailed license information and precise package locations. Syft’s support for multiple output formats, including CycloneDX, SPDX, and its native format, ensures compatibility with your existing toolchain and compliance requirements.

The project’s active development means you benefit from regular updates and security fixes, keeping pace with the evolving software supply chain security landscape. Finally, Syft’s robust CLI and API options make integrating into your existing automation pipelines and CI/CD workflows easy.

How to Generate a Python SBOM with Syft

Ready to generate SBOMs for your Python projects? Here’s how to get started with Syft:

1. Install Syft following the official installation guide
2. For a quick SBOM of your Python project:
   

$ syft path/to/your/project -o cyclonedx-json

3. Explore different output formats:
   

$ syft path/to/your/project -o spdx-json
$ syft path/to/your/project -o syft-json

Conclusion

While pipdeptree combined with cyclonedx-py provides a solid Python-specific solution, Syft offers a more comprehensive and versatile approach to SBOM generation. Its ability to handle multiple ecosystems, provide rich metadata, and support various output formats makes it an excellent choice for modern software supply chain security needs.

Whether starting with SBOMs or looking to improve your existing process, Syft provides a robust, future-proof solution that grows with your needs. Try it and see how it can enhance your software supply chain security today.

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

Download Now

We’re excited to announce Syft v1.20.0! If you’re new to the community, Syft is Anchore’s open source software composition analysis (SCA) and SBOM generation tool that provides foundational support for software supply chain security for modern DevSecOps workflows.

The latest version is packed with performance improvements, enhanced SBOM accuracy, and several community-driven features that make software composition scanning more comprehensive and efficient than ever.

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

Download Now

50x Faster Windows Scans

Scanning projects with numerous DLLs was reported to take peculiarly long when running on Windows, sometimes up to 50 minutes. A sharp-eyed community member (@rogueai) discovered that certificate validation was being performed unnecessarily during DLL scanning. A fix was merged into this release and those lengthy scans have been dramatically reduced from to just a few minutes—a massive performance improvement for Windows users!

Bitnami Embedded SBOM Support: Maximum Accuracy

Container images from Bitnami include valuable embedded SBOMs located at /opt/bitnami/. These SBOMs, packaged by the image creators themselves, represent the most authoritative source for package metadata. Thanks to community member @juan131 and maintainer @willmurphyscode, Syft now includes a dedicated cataloger for these embedded SBOMs.

This feature wasn’t simple to implement. It required careful handling of package relationships and sophisticated deduplication logic to merge authoritative vendor data with Syft’s existing scanning capabilities. The result? Scanning Bitnami images gives you the most accurate SBOM possible, combining authoritative vendor data with Syft’s comprehensive analysis.

Smarter License Detection

Handling licenses for non-open source projects can be a bit tricky. We discovered that when license files can’t be matched to a valid SPDX expression, they sometimes get erroneously marked as “unlicensed”—even when valid license text is present. For example, our dpkg cataloger occasionally encountered a license like:

NVIDIA Software License Agreement and CUDA Supplement to Software License Agreement

And categorized the package as unlicensed. Ideally, the cataloger would capture this non-standards compliant license whether the maintainer follows SDPX or not.

Community member @HeyeOpenSource and maintainer @spiffcs tackled this challenge with an elegant solution: a new configuration option that preserves the original license text when SPDX matching fails. While disabled by default for compatibility, you can enable this feature with license.include-unknown-license-content: true in your configuration. This ensures you never lose essential license information, even for non-standard licenses.

Go 1.24: Better Performance and Versioning

The upgrade to Go 1.24 brings two significant improvements:

• Faster Scanning: Thanks to Go 1.24’s optimized map implementations, discussed in this Bytesize Go post—and other performance improvements—we’re seeing scan times reduced by as much as 20% in our testing.
  
• Enhanced Version Detection: Go 1.24’s new version embedding means Syft can now accurately report its version and will increasingly provide more accurate version information for Go applications it scans:

syft:   go1.24.0

$ go version -m ./syft

path    github.com/anchore/syft/cmd/syft

mod     github.com/anchore/syft v1.20.0

This also means that as more applications are built with Go 1.24—the versions reported by Syft will become increasingly accurate over time. Everyone’s a winner!

Join the Conversation

We’re proud of these enhancements and grateful to the community for their contributions. If you’re interested in contributing or have ideas for future improvements, head to our GitHub repo and join the conversation. Your feedback and pull requests help shape the future of Syft and our other projects. Happy scanning!

Stay updated on future community spotlights and events by subscribing to our community newsletter.

Learn how MegaLinter leverages Syft and Grype to generate SBOMs and create vulnerability reports

Watch Now

Syft is an open source CLI tool and Go library that generates a Software Bill of Materials (SBOM) from source code, container images and packaged binaries. It is a foundational building block for various use-cases: from vulnerability scanning with tools like Grype, to OSS license compliance with tools like Grant. SBOMs track software components—and their associated supplier, security, licensing, compliance, etc. metadata—through the software development lifecycle.

At a high level, Syft takes the following approach to generating an SBOM:

1. Determine the type of input source (container image, directory, archive, etc.)
2. Orchestrate a pluggable set of catalogers to scan the source or artifact
   • Each package cataloger looks for package types it knows about (RPMs, Debian packages, NPM modules, Python packages, etc.)
   • In addition, the file catalogers gather other metadata and generate file hashes
3. Aggregate all discovered components into an SBOM document
4. Output the SBOM in the desired format (Syft, SPDX, CycloneDX, etc.)

Let’s dive into each of these steps in more detail.

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

Download Now

Flexible Input Sources

Syft can generate an SBOM from several different source types:

• Container images (both from registries and local Docker/Podman engines)
• Local filesystems and directories
• Archives (TAR, ZIP, etc.)
• Single files

This flexibility is important as SBOMs are used in a variety of environments, from a developer’s workstation to a CI/CD pipeline.

When you run Syft, it first tries to autodetect the source type from the provided input. For example:

# Scan a container image 
syft ubuntu:latest

# Scan a local filesystem
syft ./my-app/

Pluggable Package Catalogers

The heart of Syft is its decoupled architecture for software composition analysis (SCA). Rather than one monolithic scanner, Syft delegates scanning to a collection of catalogers, each focused on a specific software ecosystem.

Some key catalogers include:

• apk-db-cataloger for Alpine packages
• dpkg-db-cataloger for Debian packages
• rpm-db-cataloger for RPM packages (sourced from various databases)
• python-package-cataloger for Python packages
• java-archive-cataloger for Java archives (JAR, WAR, EAR)
• npm-package-cataloger for Node/NPM packages

Syft automatically selects which catalogers to run based on the source type. For a container image, it will run catalogers for the package types installed in containers (RPM, Debian, APK, NPM, etc). For a filesystem, Syft runs a different set of catalogers looking for installed software that is more typical for filesystems and source code.

This pluggable architecture gives Syft broad coverage while keeping the core streamlined. Each cataloger can focus on accurately detecting its specific package type.

If we look at a snippet of the trace output from scanning an Ubuntu image, we can see some catalogers in action:

[0001] DEBUG discovered 91 packages cataloger=dpkg-db-cataloger...  
[0001] DEBUG discovered 0 packages cataloger=rpm-db-cataloger
[0001] DEBUG discovered 0 packages cataloger=npm-package-cataloger

Here, the dpkg-db-cataloger found 91 Debian packages, while the rpm-db-cataloger and npm-package-cataloger didn’t find any packages of their types—which makes sense for an Ubuntu image.

Aggregating and Outputting Results

Once all catalogers have finished, Syft aggregates the results into a single SBOM document. This normalized representation abstracts away the implementation details of the different package types.

The SBOM includes key data for each package like:

• Name
• Version
• Type (Debian, RPM, NPM, etc)
• Files belonging to the package
• Source information (repository, download URL, etc.)
• File digests and metadata

It also contains essential metadata, including a copy of the configuration used when generating the SBOM (for reproducibility). The SBOM will contain detailed information about package evidence, which packages were parsed from (within package.Metadata).

Finally, Syft serializes this document into one or more output formats. Supported formats include:

• Syft’s native JSON format
• SPDX’s tag-value and JSON
• CycloneDX’s JSON and XML

Having multiple formats allows integrating Syft into a variety of toolchains and passing data between systems that expect certain standards.

Revisiting the earlier Ubuntu example, we can see a snippet of the final output:

NAME         VERSION            TYPE
apt          2.7.14build2       deb
base-files   13ubuntu10.1       deb
bash         5.2.21-2ubuntu4    deb

Container Image Parsing with Stereoscope

To generate high-quality SBOMs from container images, Syft leverages a stereoscope library for parsing container image formats.

Stereoscope does the heavy lifting of unpacking an image into its constituent layers, understanding the image metadata, and providing a unified filesystem view for Syft to scan.

This encapsulation is quite powerful, as it abstracts the details of different container image specs (Docker, OCI, etc.), allowing Syft to focus on SBOM generation while still supporting a wide range of images.

Cataloging Challenges and Future Work

While Syft can generate quality SBOMs for many source types, there are still challenges and room for improvement.

One challenge is supporting the vast variety of package types and versioning schemes. Each ecosystem has its own conventions, making it challenging to extract metadata consistently. Syft has added support for more ecosystems and evolved its catalogers to handle edge-cases to provide support for an expanding array of software tooling.

Another challenge is dynamically generated packages, like those created at runtime or built from source. Capturing these requires more sophisticated analysis that Syft does not yet do. To illustrate, let’s look at two common cases:

Runtime Generated Packages

Imagine a Python application that uses a web framework like Flask or Django. These frameworks allow defining routes and views dynamically at runtime based on configuration or plugin systems.

For example, an application might scan a /plugins directory on startup, importing any Python modules found and registering their routes and models with the framework. These plugins could pull in their own dependencies dynamically using importlib.

From Syft’s perspective, none of this dynamic plugin and dependency discovery happens until the application actually runs. The Python files Syft scans statically won’t reveal those runtime behaviors.

Furthermore, plugins could be loaded from external sources not even present in the codebase Syft analyzes. They might be fetched over HTTP from a plugin registry as the application starts.

To truly capture the full set of packages in use, Syft would need to do complex static analysis to trace these dynamic flows, or instrument the running application to capture what it actually loads. Both are much harder than scanning static files.

Source Built Packages

Another typical case is building packages from source rather than installing them from a registry like PyPI or RubyGems.

Consider a C++ application that bundles several libraries in a /3rdparty directory and builds them from source as part of its build process.

When Syft scans the source code directory or docker image, it won’t find any already built C++ libraries to detect as packages. All it will see are raw source files, which are much harder to map to packages and versions.

One approach is to infer packages from standard build tool configuration files, like CMakeLists.txt or Makefile. However, resolving the declared dependencies to determine the full package versions requires either running the build or profoundly understanding the specific semantics of each build tool. Both are fragile compared to scanning already built artifacts.

Some Language Ecosystems are Harder Than Others

It’s worth noting that dynamism and source builds are more or less prevalent in different language ecosystems.

Interpreted languages like Python, Ruby, and JavaScript tend to have more runtime dynamism in their package loading compared to compiled languages like Java or Go. That said, even compiled languages have ways of loading code dynamically, it just tends to be less common.

Likewise, some ecosystems emphasize always building from source, while others have a strong culture of using pre-built packages from central registries.

These differences mean the level of difficulty for Syft in generating a complete SBOM varies across ecosystems. Some will be more amenable to static analysis than others out of the box.

What Could Help?

To be clear, Syft has already done impressive work in generating quality SBOMs across many ecosystems despite these challenges. But to reach the next level of coverage, some additional analysis techniques could help:

1. Static analysis to trace dynamic code flows and infer possible loaded packages (with soundness tradeoffs to consider)
2. Dynamic instrumentation/tracing of applications to capture actual package loads (sampling and performance overhead to consider)
3. Standardized metadata formats for build systems to declare dependencies (adoption curve and migration path to consider)
4. Heuristic mapping of source files to known packages (ambiguity and false positives to consider)

None are silver bullets, but they illustrate the approaches that could help push SBOM coverage further in complex cases.

Ultimately, there will likely always be a gap between what static tools like Syft can discover versus the actual dynamic reality of applications. But that doesn’t mean we shouldn’t keep pushing the boundary! Even incremental improvements in these areas help make the software ecosystem more transparent and secure.

Syft also has room to grow in terms of programming language support. While it covers major ecosystems like Java and Python well, more work is needed to cover languages like Go, Rust, and Swift completely.

As the SBOM landscape evolves, Syft will continue to adapt to handle more package types, sources, and formats. Its extensible architecture is designed to make this growth possible.

Get Involved

Syft is fully open source and welcomes community contributions. If you’re interested in adding support for a new ecosystem, fixing bugs, or improving SBOM generation, the repo is the place to get started.

There are issues labeled “Good First Issue” for those new to the codebase. For more experienced developers, the code is structured to make adding new catalogers reasonably straightforward.

No matter your experience level, there are ways to get involved and help push the state of the art in SBOM generation. We hope you’ll join us!

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

Download Now

Today, we’re excited to announce the launch of “Software Bill of Materials 101: A Guide for Developers, Security Engineers, and the DevSecOps Community”. This eBook is free and open source resource that provides a comprehensive introduction to all things SBOMs.

Why We Created This Guide

While SBOMs have become increasingly critical for software supply chain security, many developers and security professionals still struggle to understand and implement them effectively. We created this guide to help bridge that knowledge gap, drawing on our experience building popular SBOM tools like Syft.

What’s Inside

The ebook covers essential SBOM topics, including:

• Core concepts and evolution of SBOMs
• Different SBOM formats (SPDX, CycloneDX) and their use cases
• Best practices for generating and managing SBOMs
• Real-world examples of SBOM deployments at scale
• Practical guidance for integrating SBOMs into DevSecOps pipelines

We’ve structured the content to be accessible to newcomers while providing enough depth for experienced practitioners looking to expand their knowledge.

Community-Driven Development

This guide is published under an open source license and hosted on GitHub at https://github.com/anchore/sbom-ebook. The collective wisdom of the DevSecOps community will strengthen this resource over time. We welcome contributions whether fixes, new content, or translations.

Getting Started

You can read the guide online, download PDF/ePub versions, or clone the repository to build it locally. The source is in Markdown format, making it easy to contribute improvements.

Join Us

We invite you to:

1. Read the guide at https://github.com/anchore/sbom-ebook
2. Star the repository to show your support
3. Share feedback through GitHub issues
4. Contribute improvements via pull requests
5. Help spread the word about SBOM best practices

The software supply chain security challenges we face require community collaboration. We hope this guide advances our collective understanding of SBOMs and their role in securing the software ecosystem.

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

Download Now

Software Bill of Materials (SBOM) has emerged as a pivotal technology to scale product innovation while taming the inevitable growth of complexity of modern software development. SBOMs are typically thought of as a comprehensive inventory of all software components—both open source and proprietary—within an application. But they are more than just a simple list of “ingredients”. They offer deeper insights that enable organizations to unlock enterprise-wide value. From automating security and compliance audits to assessing legal risks and scaling continuous regulatory compliance, SBOMs are central to the software development lifecycle.

However, as organizations begin to mature their SBOM initiative, the rapid growth in SBOM documents can quickly become overwhelming—a phenomenon known as SBOM sprawl. Below, we’ll outline how SBOM sprawl happens, why it’s a natural byproduct of a maturing SBOM program, and the best practices for wrangling the complexity to extract real value.

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

Download Now

How does SBOM Sprawl Happen?

SBOM adoption typically begins ad hoc when a Software Engineer starts self-scanning their source code to look for vulnerabilities or a DevOps Engineer integrating an open source SBOM generator into a non-critical CI/CD pipeline as a favor to a friendly Security Engineer. SBOMs begin to pile up niches across the organization and adoption continues to grow through casual conversation. 

It’s only a matter of time before you accumulate a flood of SBOMs. As ad hoc adoption reaches scale, the volume of SBOM data balloons. We’re not all running at Google’s scale but their SBOM growth chart still illustrates the story of how new SBOM programs can quickly get out of hand.

We call this SBOM sprawl. It is the overabundance of unmanaged and unorganized SBOM documents. When left unchecked, SBOM sprawl prevents SBOMs from delivering the value of its use-cases like real-time vulnerability discovery, automated compliance checks, or supply chain insights.

So, how do we regain control as our SBOM initiative grows? The answer lies in a centralized data store. Instead of letting SBOMs scatter, we bring them together in a robust SBOM management system that can index, analyze, and make these insights actionable. Think of it like any large data management problem. The same best practices used for enterprise data management—ETL pipelines, centralized storage, robust queries—apply to SBOMs as well.

What is SBOM Management (SBOMOps)?

SBOM management—or SBOMOps—is defined as:

A data pipeline, centralized repository and query engine purpose-built to manage and extract actionable software supply chain insights from software component metadata (i.e., SBOMs).

In practical terms, SBOM management focuses on:

• Reliably generating SBOMs at key points in the development lifecycle
• Ingesting and converting 3rd-party supplier SBOMs
• Storing the SBOM documents in a centralized repository
• Enriching SBOMs from additional data sources (e.g., security, compliance, licensing, etc.)
• Generating the use-case specific queries and reports that drive results

When done right, SBOMOps reduces chaos, making SBOMs instantly available for everything from zero-day vulnerability checks to open source license tracking—without forcing teams to manually search scattered locations for relevant files.

SBOM Management Best Practices

1. Store and manage SBOMs in a central repository

A single, central repository for SBOMs is the antidote to sprawl. Even if developer teams keep SBOM artifacts near their code repositories for local reference, the security organization should maintain a comprehensive SBOM inventory across all applications.

Why it matters:

• Rapid incident response: When a new zero-day hits, you need a quick way to identify which applications are affected. That’s nearly impossible if your SBOM data is scattered or nonexistent.
• Time savings: Instead of rescanning every application from scratch, you can consult the repository for an instant snapshot of dependencies.

2. Support SBOM standards—but don’t stop there

SPDX and CycloneDX are the two primary SBOM standards today, each with their own unique strengths. Any modern SBOM management system should be able to ingest and produce both. However, the story doesn’t end there.

Tooling differences:

• Not all SBOM generation tools are created equal. For instance, Syft (OSS) and AnchoreCTL can produce a more comprehensive intermediate SBOM format containing additional metadata beyond what SPDX or CycloneDX alone might capture. This extra data can lead to:
  • More precise vulnerability detection
  • More granular policy enforcement
  • Fewer false positives

3. Require SBOMs from all 3rd-party software suppliers

It’s not just about your own code—any 3rd-party software you include is part of your software supply chain. SBOM best practice demands obtaining an SBOM from your suppliers, whether that software is open source or proprietary.

Challenges:

• OSS: Open source libraries can be scanned relatively easily using software composition analysis (SCA) tools because source code is public. Remember, you are ultimately responsible for patching OSS vulnerabilities—not the maintainers.
• Proprietary: Commercial vendors may be wary of sharing SBOM data (IP or confidentiality concerns). If they won’t provide the SBOM, at least require them to maintain an SBOM-driven vulnerability management workflow and to notify you of relevant incidents.

4. Generate SBOMs at each step in the development process and for each build

Yes, generating an SBOM with every build inflates your data management and storage needs. However, if you have an SBOM management system in place then storing these extra files is a non-issue—and the benefits are massive.

SBOM drift detection:
By generating SBOMs multiple times along the DevSecOps pipeline, you can detect any unexpected changes (drift) in your supply chain—whether accidental or malicious. This approach can thwart adversaries (e.g., APTs) that compromise upstream supplier code. An SBOM audit trail lets you pinpoint exactly when and where an unexpected code injection occurred.

5. Pay it forward >> Create an SBOM for your releases

If you expect third parties to provide you SBOMs, it’s only fair to provide your own to downstream users. This transparency fosters trust and positions you for future SBOM-related regulatory or compliance requirements. If SBOM compliance becomes mandatory (we think the industry is trending that direction), you’ll already be prepared.

How to Architect an SBOM Management System

The reference architecture below outlines the major components needed for a reliable SBOM management solution:

1. Integrate SBOM Generation into CI/CD Pipeline: Embed a SBOM generator in every relevant DevSecOps pipeline stage to automate software composition analysis and SBOM generation.
2. Ingest 3rd-party supplier SBOMs: Ingest and normalize external SBOMs from all 3rd-party software component suppliers.
3. Send All SBOM Artifacts to Repository: Once generated, ensure each SBOM is automatically shipped to the central repository to serve as your source-of-truth for software supply chain data.
4. Enrich SBOMs with critical business data: Enrich SBOMs from additional data sources (e.g., security, compliance, licensing, etc.)
5. Stand Up Data Analysis & Visualization: Build or adopt dashboards and query tooling to generate the software supply chain insights desired from the scoped SBOM use-cases.
6. Profit! (Figuratively): Gain comprehensive software supply chain visibility, faster incident response, and the potential to unlock advanced use-cases like automated policy-as-code enforcement.

You can roll your own SBOM management platform or opt for a turnkey solution 👇.

SBOM Management Using Anchore SBOM and Anchore Enterprise

Anchore offers a comprehensive SBOM management platform that help you centralize and operationalize SBOM data—unlocking the full strategic value of your software bills of materials:

• Anchore Enterprise
  • Out-of-the-box SBOM generation: Combined SCA scanning, SBOM generation and SBOM format support for full development environment coverage.
  • Purpose-built SBOM Inventory: Eliminates SBOM sprawl with a centralized SBOM repository to power SBOM use-cases like rapid incident response, license risk management and automated compliance.
  • DevSecOps Integrations: Drop-in plugins for standard DevOps tooling; CI/CD pipelines, container registries, ticketing systems, and more.
  • SBOM Enrichment Data Pipeline: Fully automated data enrichment pipeline for security, compliance, licensing, etc. data.
  • Pre-built Data Analysis & Visualization: Delivers immediate insights on the health of your software supply chain with visualization dashboards for vulnerabilities, compliance, and policy checks.
  • Policy-as-Code Enforcement: Customizable policy rules guarantee continuous compliance, preventing high-risk or non-compliant components from entering production and reducing manual intervention.

Ready to get serious about securing your software supply chain?
Request a demo to learn how Anchore Enterprise can help you implement a scalable SBOM management solution.

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

Download Now

Welcome back to the second installment of our two-part series on “The Evolution of SBOMs in the DevSecOps Lifecycle”. In our first post, we explored how Software Bills of Materials (SBOMs) evolve over the first 4 stages of the DevSecOps pipeline—Plan, Source, Build & Test—and how each type of SBOM serves different purposes. Some of those use-cases include: shift left vulnerability detection, regulatory compliance automation, OSS license risk management and incident root cause analysis.

In this part, we’ll continue our exploration with the final 4 stages of the DevSecOps lifecycle, examining:

• Analyzed SBOMs at the Release (Registry) stage
• Deployed SBOMs during the Deployment phase
• Runtime SBOMs in Production (Operate & Monitor stages)

As applications migrate down the pipeline, design decisions made at the beginning begin to ossify becoming more difficult to change; this influences the challenges that are experienced and the role that SBOMs play in overcoming these novel problems. Some of the new challenges that come up include: pipeline leaks, vulnerabilities in third-party packages, and runtime injection. All of which introduce significant risk. Understanding how SBOMs evolve across these stages helps organizations mitigate these risks effectively.

Whether you’re aiming to enhance your security posture, streamline compliance reporting, or improve incident response times, this comprehensive guide will equip you with the knowledge to leverage SBOMs effectively from Release to Production. Additionally, we’ll offer pro tips to help you maximize the benefits of SBOMs in your DevSecOps practices.

So, let’s continue our journey through the DevSecOps pipeline and discover how SBOMs can transform the latter stages of your software development lifecycle.

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

Download Now

Release (or Registry) => Analyzed SBOM

After development is completed and the new release of the software is declared a “golden” image the build system will push the release artifact to a registry for storage until it is deployed. At this stage, an SBOM that is generated based on these container images, binaries, etc. is named an “Analyzed SBOM” by CISA. The name is a little confusing since all SBOMs should be analyzed regardless of the stage they are generated. A more appropriate name might be a Release SBOM but we’ll stick with CISA’s name for now.

At first glance, it would seem that Analyzed SBOMs and the final Build SBOMs should be identical since it is the same software but that doesn’t hold up in practice. DevSecOps pipelines aren’t hermetically sealed systems, they can be “leaky”. You might be surprised what finds its way into this storage repository and eventually gets deployed bypassing your carefully constructed build and test setup.

On top of that, the registry holds more than just first-party applications that are built in-house. It also stores 3rd-party container images like operating systems and any other self-contained applications used by the organization.

The additional metadata that is collected for an Analyzed SBOM includes:

• Release images that bypass the happy path build and test pipeline
• 3rd-party container images, binaries and applications

Pros and Cons

Pros:

• Comprehensive Artifact Inventory: A more holistic view of all software—both 1st- and 3rd-party—that is utilized in production.
• Enhanced Security and Compliance Posture: Catches vulnerabilities and non-compliant images for all software that will be deployed to production. This reduces the risk of security incidents and compliance violations.
• Third-Party Supply Chain Risk Management: Provides insights into the vulnerabilities and compliance status of third-party components.
• Ease of implementation: This stage is typically the lowest lift for implementation given that most SBOM generators can be deployed standalone and pointed at the registry to scan all images.

Cons:

• High Risk for Release Delays: Scanning images at this stage are akin to traditional waterfall-style development patterns. Most design decisions are baked-in and changes typically incur a steep penalty.
• Difficult to Push Feedback into Exist Workflow: The registry sits outside of typical developer workflows and creating a feedback loop that seamlessly reports issues without changing the developer’s process is a non-trivial amount of work.
• Complexity in Management: Managing SBOMs for both internally developed and third-party components adds complexity to the software supply chain.

Use-Cases

• Software Supply Chain Security: Organizations can detect vulnerabilities in both their internal developed software and external software to prevent supply chain injections from leading to a security incident.
• Compliance Reporting: Reporting on both 1st- and 3rd-party software is necessary for industries with strict regulatory requirements.
• Detection of Leaky Pipelines: Identifies release images that have bypassed the standard build and test pipeline, allowing teams to take corrective action.
• Third-Party Risk Analysis: Assesses the security and compliance of third-party container images, binaries, and applications before they are deployed.

Example: An organization subject to strict compliance standards like FedRAMP or cATO uses Analyzed SBOMs to verify that all artifacts in their registry, including third-party applications, comply with security policies and licensing requirements. This practice not only enhances their security posture but also streamlines the audit process.

Pro Tip

A registry is an easy and non-invasive way to test and evaluate potential SBOM generators. It won’t give you a full picture of what can be found in your DevSecOps pipeline but it will at least give you an initial idea of its efficacy and help you make the decision on whether to go through the effort of integrating it into your build pipeline where it will produce deeper insights.

Deploy => Deployed SBOM

As your container orchestrator is deploying an image from your registry into production it will also orchestrate any production dependencies such as sidecar containers or production dependencies. At this stage, an SBOM that is generated is named an “Deployed SBOM” by CISA.

The ideal scenario is that your operations team is storing all of these images in the same central registry as your engineering team but—as we’ve noted before—reality diverges from the ideal.

The additional metadata that is collected for a Deployed SBOM includes:

• Any additional sidecar containers or production dependencies that are injected or modified through a release controller.

Pros and Cons

Pros:

• Enhanced Security Posture: The final gate to prevent vulnerabilities from being deployed into production. This reduces the risk of security incidents and compliance violations.
• Leaky Pipeline Detection: Another location to increase visibility into the happy path of the DevSecOps pipeline being circumvented.
• Compliance Enforcement: Some compliance standards require a deployment breaking enforcement gate before any software is deployed to production. A container orchestrator release controller is the ideal location to implement this.

Cons:

Essentially the same issues that come up during the release phase.

• High Risk for Release Delays: Scanning images at this stage are even later than traditional waterfall-style development patterns and will incur a steep penalty if an issue is uncovered.
• Difficult to Push Feedback into Exist Workflow: A deployment release controller sits outside of typical developer workflows and creating a feedback loop that seamlessly reports issues without changing the developer’s process is a non-trivial amount of work.

Use-Cases

• Strict Software Supply Chain Security: Implementing a pipeline breaking gating mechanism is typically reserved for only the most critical security vulnerabilities (think: an actively exploitable known vulnerability).
• High-Stakes Compliance Enforcement: Industries like defense, financial services and critical infrastructure will require vendors to implement a deployment gate for specific risk scenarios beyond actively exploitable vulnerabilities.
• Compliance Audit Automation: Most regulatory compliance frameworks mandate audit artifacts at deploy time, these documents can be automatically generated and stored for future audits.

Example: A Deployed SBOM can be used as the source of truth for generating a report that demonstrates that no HIGH or CRITICAL vulnerabilities were deployed to production during an audit period.

Pro Tip

Combine a Deployed SBOM with a container vulnerability scanner that cross-checks all vulnerabilities against CISA’s Known Exploitable Vulnerability (KEV) database. In the scenario where a matching KEV is found for a software component you can configure your vulnerability scanner to return a FAIL response to your release controller to abort the deployment.

This strategy creates an ideal balance between not adding delays to software delivery and an extremely high probability for a security incident. 

Operate & Monitor (or Production) => Runtime SBOM

After your container orchestrator has deployed an application into your production environment it is live and serving customer traffic. An SBOM that is generated at this stage don’t have a name as specified by CISA. They are sometimes referred to as “Runtime SBOMs”. SBOMs are still a new-ish standard and will continue to evolve. 

The additional metadata that is collected for a Runtime SBOM includes:

• Modifications (i.e., intentional hotfixes or malicious malware injection) made to running applications in your production environment. 

Pros and Cons

Pros:

• Continuous Security Monitoring: Identifies new vulnerabilities that emerge after deployment.
• Active Runtime Inventory: Provides a canonical view into an organization’s active software landscape.
• Low Lift Implementation: Deploying SBOM generation into a production environment typically only requires deploying the scanner as another container and giving it permission to access the rest of the production environment.

Cons:

• No Shift Left Security: By definition is excluded as a part of a shift left security posture.
• Potential for Release Rollbacks: Scanning images at this stage is the worst possible place for proactive remediation. Discovering a vulnerability could potentially cause a security incident and force a release rollback.

Use-Cases

• Rapid Incident Management: When new critical vulnerabilities are discovered and announced by the community the first priority for an organization is to determine exposure. An accurate production inventory, down to the component-level, is needed to answer this critical question.
• Threat Detection: Continuously monitoring for anomalous activity linked to specific components. Sealing your system off completely from advanced persistent threats (APTs) is an unfeasible goal. Instead, quick detection and rapid intervention is the scalable solution to limit the impact of these adversaries.
• Patch Management: As new releases of 3rd-party components and applications are released an inventory of impacted production assets provides helpful insights that can direct the prioritization of engineering efforts.

Example: When the XZ Utils vulnerability was announced in the spring of 2024, organizations that already automatically generated a Runtime SBOM inventory ran a simple search query against their SBOM database and knew within minutes—or even seconds—whether they were impacted.

Pro Tip

If you want to learn about how Google was able to go from an all-hands on deck security incident when the XZ Utils vulnerability was announced to an all clear under 10 minutes, watch our webinar with the lead of Google’s SBOM initiative.

Watch Now

Wrap-Up

As the SBOM standard has evolved the subject has grown considerably. What started as a structured way to store information about open source licenses has expanded to include numerous use-cases. A clear understanding of the evolution of SBOMs throughout the DevSecOps lifecycle is essential for organizations aiming to solve problems ranging from software supply chain security to regulatory compliance to legal risk management.

SBOMs are a powerful tool in the arsenal of modern software development. By recognizing their importance and integrating them thoughtfully across the DevSecOps lifecycle, you position your organization at the forefront of secure, efficient, and compliant software delivery.

Ready to secure your software supply chain and automate compliance tasks with SBOMs? Anchore is here to help. We offer SBOM management, vulnerability scanning and compliance automation enforcement solutions. If you still need some more information before looking at solutions, check out our webinar below on scaling a secure software supply chain with Kubernetes. 👇👇👇

Learn how Spectro Cloud secured their Kubernetes-based software supply chain and the pivotal role SBOMs played.

Watch Now

The software industry has wholeheartedly adopted the practice of building new software on the shoulders of the giants that came before them. To accomplish this developers construct a foundation of pre-built, 3rd-party components together then wrap custom 1st-party code around this structure to create novel applications. It is an extraordinarily innovative and productive practice but it also introduces challenges ranging from security vulnerabilities to compliance headaches to legal risk nightmares. Software bills of materials (SBOMs) have emerged to provide solutions for these wide ranging problems.

An SBOM provides a detailed inventory of all the components that make up an application at a point in time. However, it’s important to recognize that not all SBOMs are the same—even for the same piece of software! SBOMs evolve throughout the DevSecOps lifecycle; just as an application evolves from source code to a container image to a running application. The Cybersecurity and Infrastructure Security Agency’s (CISA) has codified this idea by differentiating between all of the different types of SBOMs. Each type serves different purposes and captures information about an application through its evolutionary process.

In this 2-part blog series, we’ll deep dive into each stage of the DevSecOps process and the associated SBOM. Highlighting the differences, the benefits and disadvantages and the use-cases that each type of SBOM supports. Whether you’re just beginning your SBOM journey or looking to deepen your understanding of how SBOMs can be integrated into your DevSecOps practices, this comprehensive guide will provide valuable insights and advice from industry experts.

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

Download Now

Types of SBOMs and the DevSecOps Pipeline

Over the past decade the US government got serious about software supply chain security and began advocating for SBOMs as the standardized approach to the problem. As part of this initiative CISA created the Types of Software Bill of Material (SBOM) Documents white paper that codified the definitions of the different types of SBOMs and mapped them to each stage of the DevSecOps lifecycle. We will discuss each in turn but before we do, let’s anchor on some terminology to prevent confusion or misunderstanding.

Below is a diagram that lays out each stage of the DevSecOps lifecycle as well as the naming convention we will use going forward.

With that out of the way, let’s get started!

Plan => Design SBOM

As the DevSecOps paradigm has spread across the software industry, a notable best practice known as the security architecture review has become integral to the development process. This practice embodies the DevSecOps goal of integrating security into every phase of the software lifecycle, aligning perfectly with the concept of Shift-Left Security—addressing security considerations as early as possible.

At this stage, the SBOM documents the planned components of the application. The CISA refers to SBOMs generated during this phase as Design SBOMs. These SBOMs are preliminary and outline the intended components and dependencies before any code is written.

The metadata that is collected for a Design SBOM includes:

• Component Inventory: Identifying potential OSS libraries and frameworks to be used as well as the dependency relationship between the components.
• Licensing Information: Understanding the licenses associated with selected components to ensure compliance.
• Risk Assessment Data: Evaluating known vulnerabilities and security risks associated with each component.

This might sound like a lot of extra work but luckily if you’re already performing DevSecOps-style planning that incorporates a security and legal review—as is best practice—you’re already surfacing all of this information. The only thing that is different is that this preliminary data is formatted and stored in a standardized data structure, namely an SBOM.

Pros and Cons

Pros:

• Maximal Shift-Left Security: Vulnerabilities cannot be found any earlier in the software development process. Design time security decisions are the peak of a proactive security posture and preempt bad design decisions before they become ingrained into the codebase.
• Cost Efficiency: Resolving security issues at this stage is generally less expensive and less disruptive than during later stages of development or—worst of all—after deployment.
• Legal and Compliance Risk Mitigation: Ensures that all selected components meet necessary compliance standards, avoiding legal complications down the line.

Cons:

• Upfront Investment: Gathering detailed information on potential components and maintaining an SBOM at this stage requires a non-trivial commitment of time and effort.
• Incomplete Information: Projects are not static, they will adapt as unplanned challenges surface. A design SBOM likely won’t stay relevant for long.

Use-Cases

There are a number of use-cases that are enabled by 

• Security Policy Enforcement: Automatically checking proposed components against organizational security policies to prevent the inclusion of disallowed libraries or frameworks.
• License Compliance Verification: Ensuring that all components comply with the project’s licensing requirements, avoiding potential legal issues.
• Vendor and Third-Party Risk Management: Assessing the security posture of third-party components before they are integrated into the application.
• Enhance Transparency and Collaboration: A well-documented SBOM provides a clear record of the software’s components but more importantly that the project aligns with the goals of all of the stakeholders (engineering, security, legal, etc). This builds trust and creates a collaborative environment that increases the chances of each individual stakeholder outcome will be achieved.

Example:

A financial services company operating within a strict regulatory environment uses SBOMs during planning to ensure that all components comply with compliance standards like PCI DSS. By doing so, they prevent the incorporation of insecure components that won’t meet PCI compliance. This reduces the risk of the financial penalties associated with security breaches and regulatory non-compliance.

Pro Tip

If your organization is still early in the maturity of its SBOM initiative then we generally recommend moving the integration of design time SBOMs to the back of the queue. As we mention at the beginning of this the information stored in a design SBOMs is naturally surfaced during the DevSecOps process, as long as the information is being recorded and stored much of the value of a design SBOM will be captured in the artifact. This level of SBOM integration is best saved for later maturity stages when your organization is ready to begin exploring deeper levels of insights that have a higher risk-to-reward ratio. 

Alternatively, if your organization is having difficulty getting your teams to adopt a collaborative DevSecOps planning process mandating a SBOM as a requirement can act as a forcing function to catalyze a cultural shift.

Source => Source SBOM

During the development stage, engineers implement the selected 3rd-party components into the codebase. CISA refers to SBOMs generated during this phase as Source SBOMs. The SBOMs generated here capture the actual implemented components and additional information that is specific to the developer who is doing the work.

The additional metadata that is collected for a Source SBOM includes:

• Dependency Mapping: Documenting direct and transitive dependencies.
• Identity Metadata: Adding contributor and commit information.
• Developer Environment: Captures information about the development environment.

Unlike Design SBOMs which are typically done manually, these SBOMs can be generated programmatically with a software composition analysis (SCA) tool—like Syft. They are usually packaged as command line interfaces (CLIs) since this is the preferred interface for developers. 

If you’re looking for an SBOM generation tool (SCA embedded), we have a comprehensive list of options to make this decision easier.

Pros and Cons

Pros:

• Accurate and Timely Component Inventory: Reflects the actual components used in the codebase and tracks changes as codebase is actively being developed.
• Shift-Left Vulnerability Detection: Identifies vulnerabilities as components are integrated but requires commit level automation and feedback mechanisms to be effective.
• Facilitates Collaboration and Visibility: Keeps all stakeholders members informed about divergence from the original plan and provokes conversations as needed. This is also dependent on automation to record changes during development and the notification systems to broadcast the updates.

Example: A developer adds a new logging library to the project like an outdated version of Log4j. The SBOM, paired with a vulnerability scanner, immediately flags the Log4Shell vulnerability, prompting the engineer to update to a patched version.

Cons:

• Noise from Developer Toolchains: A lot of times developer environments are bespoke. This creates noise for security teams by recording development dependencies.
• Potential Overhead: Continuous updates to the SBOM can be resource-intensive when done manually; the only resource efficient method is by using an SBOM generation tool that automates the process.
• Possibility of Missing Early Risks: Issues not identified during planning may surface here, requiring code changes.

Use-Cases

• Faster Root Cause Analysis: During service incident retrospectives questions about where, when and by whom a specific component was introduced into an application. Source SBOMs are the programmatic record that can provide answers and decrease manual root cause analysis.
• Real-Time Security Alerts: Immediate notification of vulnerabilities upon adding new components, decreasing time to remediation and keeping security teams informed.
• Automated Compliance Checks: Ensuring added components comply with security or license policies to manage compliance risk.
• Effortless Collaboration: Stakeholders can subscribe to a live feed of changes and immediately know when implementation diverges from the plan.

Pro Tip

Some SBOM generators allow developers to specify development dependencies that should be ignored, similar to .gitignore file. This can help cut down on the noise created by unique developer setups.

Build & Test => Build SBOM

When a developer pushes a commit to the CI/CD build system an automated process initiates that converts the application source code into an artifact that can then be deployed. CISA refers to SBOMs generated during this phase as Build SBOMs. These SBOMs capture both source code dependencies and build tooling dependencies.

The additional metadata that is collected includes:

• Build Dependencies: Build tooling such as the language compilers, testing frameworks, package managers, etc.
• Binary Analysis Data: Metadata for compiled binaries that don’t utilize traditional container formats.
• Configuration Parameters: Details on build configuration files that might impact security or compliance.

Pros and Cons

Pros:

• Build Infrastructure Analysis: Captures build-specific components which may have their own vulnerability or compliance issues.
• Reuses Existing Automation Tooling: Enables programmatic security and compliance scanning as well as policy enforcement without introducing any additional build tooling.
• Reuses Existing Automation Tooling: Directly integrates with developer workflow. Engineers receive security, compliance, etc. feedback without the need to reference a new tool.
• Reproducibility: Facilitates reproducing builds for debugging and auditing.

Cons:

• SBOM Sprawl: Build processes run frequently, if it is generating an SBOM with each run you will find yourself with a glut of files that you will have to manage.
• Delayed Detection: Vulnerabilities or non-compliance issues found at this stage may require rework.

Use-Cases

• SBOM Drift Detection: By comparing SBOMs from two or more stages, unexpected dependency injection can be detected. This might take the form of a benign, leaky build pipeline that requires manual workarounds or a malicious actor attempting to covertly introduce malware. Either way this provides actionable and valuable information.
• Policy Enforcement: Enables the creation of build breaking gates to enforce security or compliance. For high-stakes operating environments like defense, financial services or critical infrastructure, automating security and compliance at the expense of some developer friction is a net-positive strategy.
• Automated Compliance Artifacts: Compliance requires proof in the form of reports and artifacts. Re-utilizing existing build tooling automation to automate this task significantly reduces the manual work required by security teams to meet compliance requirements.

Example: A security scan during testing uses the Build SBOM to identify a critical vulnerability and alerts the responsible engineer. The remediation process is initiated and a patch is applied before deployment.

Pro Tip

If your organization is just beginning their SBOM journey, this is the recommended phase of the DevSecOps lifecycle to implement SBOMs first. The two primary cons of this phase can be mitigated the easiest. For SBOM sprawl, you can procure a turnkey SBOM management solution like Anchore SBOM. 

As for the delay in feedback created by waiting till the build phase, if your team is utilizing DevOps best practices and breaking features up into smaller components that fit into 2-week sprints then this tight scoping will limit the impact of any significant vulnerabilities or non-compliance discovered.

Intermission

So far we’ve covered the first half of the DevSecOps lifecycle. Next week we will publish the second part of this blog series where we’ll cover the remainder of the pipeline. Watch our socials to be sure you get notified when part 2 is published.

If you’re looking for some additional reading in the meantime, check out our container security white paper below.

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

Download Now

We are thrilled to announce the release of Anchore Enterprise 5.10, our tenth release of 2024. This update brings two major enhancements that will elevate your experience and bolster your security posture: the new Anchore Data Service (ADS) and expanded AnchoreCTL ecosystem coverage. 

With ADS, we’ve built a fast and reliable solution that reduces time spent by DevSecOps teams debugging intermittent network issues from flaky services that are vital to software supply chain security.

On top of that, we have buffed our software composition analysis (SCA) scanner’s ecosystem coverage (e.g., C++, Swift, Elixir, R, etc.) for all Anchore customers. To do this we embedded Syft—our popular, open source SCA/SBOM (software bill of materials) generator—directly into Anchore Enterprise.

It’s been a fall of big releases at Anchore and we’re excited to continue delivering value to our loyal customers. Read on to get all of the gory details >>

Announcing the Anchore Data Service

Before, customers ran the Anchore Feed Service within their environment to pull data feeds into their Anchore Enterprise deployment. To get an idea of what this looked like, see the architecture diagram of Anchore Enterprise prior to version 5.10:

Originally we did this to give customers more control over their environment. Unfortunately this wasn’t without its issues. The data feeds are provided by the community which means the services were designed to be accessible but cost-efficient. This meant they were unreliable; frequently having accessibility issues.

We only have to stretch our memory back to the spring to recall an example that made national headlines. The National Vulnerability Database (NVD) ran into funding issues. This impacted both the creation of new vulnerabilities AND the availability of their API. This created significant friction for Anchore customers—not to mention the entirety of the software industry.

Now, Anchore is running its own enterprise-grade service, named Anchore Data Service (ADS). It is a replacement for the former feed service. ADS aggregates all of the community data feeds, enriches the data (with proprietary threat data) and packages it for customers; all of this with a service availability guarantee expected of an enterprise service.

The new architecture with ADS as the intermediary is illustrated below:

As a bonus for our customers running air-gapped deployments of Anchore Enterprise, there is no more need to run a second deployment of Anchore Enterprise in a DMZ to pull down the data feeds. Instead a single file is pulled from ADS then transferred to a USB thumb drive. From there a single CLI command is run to update your air-gapped deployment of Anchore Enterprise.

Increased AnchoreCTL Ecosystem Coverage

We have increased the number of supported ecosystems (e.g., C++, Swift, Elixir, R, etc.) in Anchore Enterprise. This improves coverage and increases the likelihood that all of your organization’s applications can be scanned and protected by Anchore Enterprise.

More importantly, we have completely re-architected the process for how Anchore Enterprise supports new ecosystems. By integrating Syft—Anchore’s open source SBOM generation tool—directly into AnchoreCTL, Anchore’s customers will now get access to new ecosystem support as they are merged into Syft’s codebase.

Before Syft and AnchoreCTL were somewhat separate which caused AnchoreCTL’s support for new ecosystems to lag Syft’s. Now, they are fully integrated. This enables all of Anchore’s enterprise and public sector customers to take full advantage of the open source community’s development velocity.

Full list of support ecosystems

Below is a complete list of all supported ecosystems by both Syft and AnchoreCTL (as of Anchore Enterprise 5.10; see our docs for most current info):

After you update to Anchore Enterprise 5.10, the SBOM inventory will now display all of the new ecosystems. Any SBOMs that have been generated for a particular ecosystem will show up top. The screenshot below gives you an idea of what this will look like:

Wrap-Up

Anchore Enterprise 5.10 marks a new chapter in providing reliable, enterprise-ready security tooling for modern software development. The introduction of the Anchore Data Service ensures that you have consistent and dependable access to critical vulnerability and exploit data, while the expanded ecosystem support means that no part of your tech stack is left unscrutinized for latent risk. Upgrade to the latest version and experience these new features for yourself.

To update and leverage these new features check out our docs, reach out to your Customer Success Engineer or contact our support team. Your feedback is invaluable to us, and we look forward to continuing to support your organization’s security needs.We are offering all of our product updates as a new quarterly product update webinar series. Watch the fall webinar update in the player below to get all of the juicy tidbits from our product team.