As organizations grapple with increasingly complex software supply chains where open source components comprise 70% to 90% of modern applications, the need for comprehensive visibility and security has never been more critical. Yet Gartner research reveals that only 15% of organizations feel confident in their software supply chain management practices—a sobering statistic that underscores the magnitude of the challenge facing today's enterprises.

In this exclusive VMblog Q&A, we sit down with Neil Levine, Senior Vice President of Product at Anchore, to explore how the company's enterprise-grade Software Bill of Materials (SBOM) platform is addressing these challenges head-on. From introducing groundbreaking "Bring Your Own SBOM" capabilities to developing sophisticated vulnerability scoring systems, Anchore is pioneering a new approach to software supply chain security that goes far beyond traditional composition analysis tools.

Levine discusses how Anchore's SBOM-centric methodology enables organizations to maintain continuous visibility across distributed development teams, meet emerging regulatory requirements from around the globe, and respond effectively to critical vulnerabilities like Log4Shell. He also delves into the company's innovative approach to detecting "SBOM drift"—unexpected changes in software components that could indicate tampering or introduce new security risks.

With software supply chain attacks making headlines and regulatory frameworks tightening worldwide, understanding how to implement effective SBOM management has become essential for security teams and DevOps professionals alike. This conversation provides valuable insights into the practical implementation of enterprise SBOM strategies and the future of software supply chain security. 

VMblog:  What motivated you to introduce "Bring Your Own SBOM" support, and how does this enhance the capabilities of Anchore Enterprise for organizations managing diverse software supply chains?

Neil Levine:  Modern software is inherently complex, often developed by distributed teams using a mix of open-source and third-party components. (Driven by the rise of open source software (OSS), which Gartner estimates makes up 70% to 90% of any given software application, only 15% of organizations feel confident in their management practices.)Different teams within an organization may use varied toolchains and depend on external partners or consultants for parts of the codebase. Ensuring security and compliance across such a diverse ecosystem requires continuous, end-to-end visibility into the entire software stack, including components outside your direct control. By importing external SBOMs, users can extend their analysis beyond standard container scanning, incorporating data from other SCA tools or vendor-provided sources. This approach delivers comprehensive insight into all components of an application, regardless of origin.

VMblog:  Can you explain how Anchore SBOM's centralized management and analysis features help organizations meet new regulatory and industry requirements around software supply chain transparency? 

Levine:  If you look across both industry and government regulations from around the world, they all essentially contain the following common requirements:

• Supply chain transparency and security
• Asset management (dependencies)
• Vulnerability management (link CVEs to component versions)
• Incident response and recovery (impact analysis and remediation planning)

Anchore supports all of these requirements across the following core solution modules:

• Anchore SBOM: generates SBOMs by scanning source code repositories, CI/CD pipelines, and container registries, along with importing external SBOMs constructed outside of Anchore or provided by suppliers.
• Anchore Secure: analyzes the stored SBOMs for security issues, including vulnerabilities & advisories, malware, and secrets.
• Anchore Enforce: evaluates selected policies at every stage of the SDLC, raises alerts for developers, shows trends to the CISO, and generates evidence for auditors. Users can choose from standard policy packs (FedRAMP, NIST, DISA, and DOD) or build their own based on their compliance needs.

VMblog:  How does Anchore Enterprise validate the quality of imported SBOMs and ensure they are suitable for effective vulnerability scanning and compliance reporting?

Levine:  Anchore calculates a set of document insights that assess the following SBOM document criteria, and are combined into a numerical SBOM quality score:

• Valid Format: checks whether the SBOM format is CycloneDX, SPDX, or Syft Native.
• Valid Schema: checks whether the document schema is JSON, XML, or SPDX (tag/value).
• Supported Format: checks whether the SBOM format is one of the supported types for vulnerability scanning.
• Supported Schema: checks whether the SBOM schema is one of the supported types for vulnerability scanning.
• Has Artifacts: checks whether the SBOM document contains one or more packages.
• Has Dependencies: checks whether the SBOM document contains dependencies.
• Has Author: checks whether the SBOM document contains an author.
• Has Supplier: checks whether the SBOM contents include a supplier.
• Has Timestamp: checks whether the SBOM contents include a timestamp of when it was generated.

VMblog:  What are the main advantages of Anchore's SBOM-centric approach compared to traditional software composition analysis tools, especially in terms of vulnerability detection, policy enforcement, and remediation?

Levine:  Anchore allows you to generate and store SBOMs for every commit, every build, and every deployment. By storing this data and making it available for querying, Security Teams can ask the best questions to respond to the specifics of the latest issue. This approach yields multiple benefits. Principally, it means you can implement DevSecOps as part of an automated shift-left approach to secure software development, as well as having a platform for managing risks associated with using open source software. For Security Engineers, they will get insights for every piece of software from source code to production and can ask questions without needing access to the original software artifacts. For Developers, SBOMs allow high-quality vulnerability results, ensuring they don't waste time with noise or false positives.

VMblog:  With open source software now comprising the majority of modern applications, how does Anchore help organizations gain visibility into both direct and transitive dependencies, and what role does this play in responding to critical vulnerabilities like Log4Shell?

Levine:  Anchore Enterprise gives users the ability to identify and track open source dependencies that are incorporated at any stage in the software lifecycle. Anchore Enterprise scans source code repositories, CI/CD pipelines, and container registries to generate SBOMs that include both direct and transitive dependencies and to identify exactly where those dependencies are found.

VMblog:  Could you elaborate on how Anchore detects and manages SBOM drift, and why this capability is crucial for securing the software build process?.

Levine:  The use of SBOMs for containerized applications provides a unique opportunity to watch for SBOM Drift, unexpected changes in the contents of a software application, which can indicate potential tampering, new versions, or changes in dependencies.

Generating an SBOM creates a snapshot of the components of your container at a specific time during the development process. By generating an SBOM for each build and at each step in the development process, you can look for differences over time. Some of those differences might be expected, like upgrading a package to a more recent version, but any changes should be investigated to determine if they introduce new risk.

For example, you generate an SBOM at the early stages of a build. You identify all of the commercial software, code, and open source software being used in your containers. As your build progresses, these components can change. New pieces can be introduced to the container by developers or the software used could have an updated version. These changes need to be identified and addressed to prevent new risk and vulnerabilities from being introduced to your finished product.

VMblog:  How does Anchore's scoring system (Anchore Score) help organizations prioritize vulnerabilities, and what data sources are used to inform these risk ratings?

Levine:  The Anchore Score is a computed composite security index that provides a numeric value for each vulnerability in the system. It is derived from a combination of the CVSS score, vulnerability severity, EPSS percentile, and KEV status, but can also factor in additional data. Currently, the CVSS score & vulnerability severity, EPSS percentile, and KEV status are equally weighted. The Anchore Score is used to generate the Anchore Rank value, indicating the relative importance of a given vulnerability within a particular set of vulnerabilities defined by an SBOM Group or individual SBOM context. This ordering helps users focus on the most critical issues for efficient security analysis and remediation planning.

##