Software Supply Chain Transparency: Why SBOMs Are the Missing Piece in Your ConMon Strategy

Two cybersecurity buzzwords are rapidly shaping how organizations manage risk and streamline operations: Continuous Monitoring (ConMon) and Software Bill of Materials (SBOMs). ConMon, rooted in the traditional security principle—“trust but verify”—has evolved into an iterative process where organizations measure, analyze, design, and implement improvements based on real-time data. Meanwhile, SBOMs offer a snapshot of an application’s composition (i.e., 3rd-party dependency supply chain) at any given point in the DevSecOps lifecycle. 

Understanding these concepts is crucial because together they unlock significant enterprise value—ranging from rapid zero-day response to scalable vulnerability management and even automated compliance enforcement. By integrating SBOMs into a robust ConMon strategy, organizations can not only mitigate supply chain risks but also ensure that every stage of software development adheres to stringent security and compliance standards.

A Brief Introduction to Continuous Monitoring (ConMon)

Continuous Monitoring is a wide ranging topic applied across various contexts such as application performance, error tracking, and security oversight. In the most general sense, ConMon is an iterative cycle of:

• Measure: Collect relevant data.
• Analyze: Analyze raw data and generate actionable insights.
• Design: Develop solution(s) based on the insights.
• Implement: Execute solution to resolve issue(s) or improve performance.
• Repeat

ConMon is underpinned by the well-known management theory maxim, “You can’t manage what you don’t measure.” Historically, the term has its origins in the federal compliance world—think FedRAMP and cATO—where continuous monitoring was initially embraced as an evolution of traditional point-in-time security compliance audits.

So, where do SBOMs fit into this picture?

A Brief Introduction to SBOMs (in the Context of ConMon)

In the world of ConMon, SBOMs are a source of data that can be measured and analyzed to extract actionable insights. SBOMs are specifically a structured store of software supply chain metadata. They track the evolution of a software artifacts supply chain as it develops throughout the software development lifecycle.

An SBOM catalogs information like software supply chain dependencies, security vulnerabilities and licensing contracts. In this way SBOMs act as the source of truth for the state of an application’s software supply chain during the development process.

The ConMon process utilizes the supply chain data stored in the SBOMs to generate actionable insights like: 

• uncovering critical supply chain vulnerabilities,
• identifying legally risky open source licenses, or 
• catching new software dependencies that break key compliance frameworks like FedRAMP.

SBOMs are the key data source that allows ConMon to apply its goal of continuously monitoring and improving an organization’s software development environment—specifically, the software supply chain.

Benefits of using SBOMs as the central component of ConMon

As the cornerstone of the software supply chain, SBOMs play a central role in supply chain security which falls under the purview of the continuous monitoring workflow. Given this, it shouldn’t be a surprise that there are cross-over use-cases between the two domains. Leveraging the standardized data structure of SBOMs unlocks a wealth of opportunities for automating supply chain security use-cases and scaling the principles of ConMon. Key use-cases and benefits include:

1. Rapid incident response to zero-day disclosure

• Reduced exploitation risk: SBOMs reduce the risk of supply chain exploitation by dramatically reducing the time to identify if vulnerable components are present in an organization’s software environment and how to prioritize remediation efforts.
• Prevent wasted organizational resources: A centralized SBOM repository enables organizations to automate manual dependency audits into a single search query. This prevents the need to re-task software engineers away from development work to deal with incident response.

2. Software dependency drift detection

• Reduced exploitation risk: When SBOM generation is integrated natively into the DevSecOps pipeline a historical record of the development of an application becomes available. Each development stage is compared against the previous to identify dependency injection in real-time. Catching and remediating malicious injections as early as possible significantly reduces the risk of exploitation by threat actors.

3. Proactive and scalable vulnerability management

• Reduced security risk: SBOMs empower organizations to decouple software composition scanning from vulnerability scanning, enabling a scalable vulnerability management approach that meets cloud-native expectations. By generating an SBOM early in the DevSecOps pipeline, teams can continuously cross-reference software components against known vulnerability databases, proactively detecting risks before they reach production.
• Reduced time on vulnerability management: This streamlined process reduces the manual tasks associated with legacy vulnerability management. Teams are now enabled to focus their efforts on higher-level issues rather than be bogged down with tedious manual tasks.

4. Automated non-compliance alerting and enforcement

• Reduced risk of non-compliance violations: Proactive monitoring of SBOMs for compliance policy violations identifies issues early and prevents compliance fees from being assessed—or worse certification revocation.

5. Automated compliance report generation

• Reduce time spent generating compliance audit evidence: Manual generation of compliance audit reports to prove security best practices are in place is a time consuming process. SBOMs unlock the power to automate the generation of audit evidence for the software supply chain. This protects organizational resources for higher-value tasks.

6. Automated OSS license management

• Reduced legal risk: An adversarial OSS license accidentally entering a commercial application opens up an enterprise to significant legal risk. SBOMs enable organizations to automate the process of scanning for OSS licenses and assessing the legal risk of the entire software supply chain. Having real-time visibility into the licenses of an organization’s entire supply chain dramatically reduces the risk of legal penalties.

In essence, SBOMs serve as the heart of a robust ConMon strategy, providing the critical data needed to scale automation and ensure that the software supply chain remains secure and compliant.

Interested to learn about all of the software supply chain use-cases that SBOMs enable? Read our new white paper and start unlocking enterprise value.

Download Now

SBOMs and ConMon applied to the DevSecOps lifecycle

Integrating SBOMs within the DevSecOps lifecycle enables organizations to realize security outcomes efficiently through a cyclical process of measurement, analysis, design and implementation. We’ll go through each step of the process.

1. Measure

Measurement is the most obvious stage of ConMon given its synonym “monitoring” is in the name. The measurement step is primarily concerned with collecting as much data as possible that will later power the analysis stage. ConMon traditionally focuses on collecting security specific data like:

• Observability Telemetry: Application logs, metrics, and traces
• Audit Logs: Records of application administration: access and modifications
• Supply Chain Metadata: Point-in-time scans of the composition of a software artifacts supply chain of 3rd-party dependencies

Software composition analysis (SCA) scanners and SBOM generation tools create an additional dimension of information about software that can then be analyzed. The supply chain metadata that is generated powers the insights that feeds the ConMon flywheel and increases transparency into software supply chain issues.

External measurements (i.e., data sources)

Additionally, external databases (e.g., NVD or VEX) can be referenced to correlate valuable information aggregated by public interest organizations like NIST (National Institute of Standards and Measures) and CISA (Cybersecurity and Infrastructure Security Agency). These databases act as comprehensive stores of the collective work of security researchers worldwide. 

As software components are analyzed and tested for vulnerabilities and exploits, researchers submit their findings to these public goods databases. The security findings are tied to the specific software components (i.e., the same component identifier stored in an SBOM).

After collecting all of this information, we are ready to move to the next phase of the ConMon lifecycle: analysis.

2. Analyze

The foundational premise of ConMon is to monitor continuously in order to uncover security threats before they can cause damage. The analysis step is what transforms raw data into actionable security insights that reduce the risk of a breach. 

• Queries over Software Supply Chain Data:
  • As the central data format for the software supply chain, SBOMs act as the data source that queries are crafted to extract insight from
• Actionable Insights:
  • Highlight known vulnerabilities by cross-referencing the entire 3rd-party software supply chain against vulnerability databases like NVD
  • Compare SBOMs from one stage of the pipeline to a later stage in order to uncover dependency injections (both unintentional and malicious)
  • Codify software supply chain security or regulatory compliance policies into policy-as-code that can alert on policy drift in real-time

3. Design

After generating insights from analysis of the raw data, the next step is to design a solution based on the analysis from the previous step. The goal of the designed solution is to reduce the risk of a security incident.

Example Solutions Based on Analysis

• Vulnerability Remediation Workflow: After analysis has uncovered known vulnerabilities, designing a system to remediate the vulnerabilities comes into focus. Utilizing the existing engineering task management process is ideal. To live up to the promise of ConMon, the analysis to remediation process should be an automated system that pushes supply chain data from the analysis platform directly into the remediation queue.
• Dependency Injection Detection via SBOM Drift Analysis: SBOMs can be scanned at each stage of the DevSecOps pipeline, when anomalous dependencies are flagged as not coming from a known good source this analysis can be used to prompt an investigation. These types of investigations are generally too complex to be automated but the investigation process still requires design.
• Automated Compliance Enforcement via Policy-as-Code: By codifying software supply chain best practices or regulatory compliance controls into policy-as-code, organizations can be alerted to policy violations in real-time. The solution design includes a mapping of policies into code, scans against containers in the DevSecOps pipeline and a notification system that can act on the analysis.

4. Implement

The final step of ConMon involves implementing the design from the previous step. This also sets up the entire process to restart from the beginning. After the design is implemented it is ready to be monitored again to assess effectiveness of the implemented design.

Execution of Solution Design

• Vulnerability Remediation Workflow: Configure the analysis platform to push a report of identified vulnerabilities to the engineering organization’s existing ticketing system. Prioritize the vulnerabilities based on their severity score to increase signal-to-noise ratio for the assigned developer or gate the analysis platform to only push reports if a vulnerability is classified as high or critical.
• Dependency Injection Detection via SBOM Drift Analysis: Integrate SBOM generation into two or more stages of the DevSecOps pipeline to enable diff analysis of software supply chain analysis over time. Allowlists and denylists can fine tune which types of dependency injections are expected and which are anomalous. Investigations into suspected dependency injection can be triggered based on anomaly detection.
• Automated Compliance Enforcement via Policy-as-Code: Security policies and/or compliance controls will need to be translated from english into code but this is a one-time, upfront investment to enable scalable, automated policy scanning. A scanner will need to be integrated into one or more places in the CI/CD build pipeline in order to detect policy violations. As violations are identified, the analysis platform can push notifications to the appropriate team.

5. Repeat

Step 5 isn’t actually a different step of ConMon, it is just a reminder to return to Step 1 for another turn of the ConMon cycle. The ‘continuous’ in ConMon means that we continue to repeat the process indefinitely. As security of a system is measured and evaluated, new security issues are discovered that then require a solution design and design implementation. This is the flywheel cycle of ConMon that endlessly improves the security of the system that is monitored.

Real-world Scenario

SBOMs and ConMon aren’t just a theoretical framework, there are a number of SBOM use-cases in production that are delivering value to enterprises. The most prominent of these is the security incident response use-case. This use-case moved into the limelight in the wake of the string of infamous software supply chain attacks of the past decade: Solarwinds, Log4j, XZ Utils, etc.

The biggest takeaway from these high-profile incidents is that enterprises were caught unprepared and experienced pain as a result of not having the tools to measure, analyze, design and implement solutions to these supply chain attacks.

Large enterprises like Google responded to this deficit by deploying an SBOM-powered software supply chain solution that generates over 100 million SBOMs a year! As a result of having this system in place Google was able to rapidly respond to the XZ Utils incident without having to utilize any manual processes that typically extend supply chain attacks like these from minutes into days or weeks. Brandon Lum, Google’s SBOM lead, recounts that “within 10 minutes of the XZ [Utils] announcement, the entire Google organization was able to rule out that anything was impacted.”

This outcome was only possible due to Google’s foresight and willingness to instrument their DevSecOps pipeline with tools like SCAs and SBOM generators and continuously monitor their software supply chain.

Ready to Reap the Rewards of SBOM-powered ConMon?

Integrating SBOMs as a central element of your ConMon strategy transforms how organizations manage software supply chain security. By aligning continuous monitoring with the principles of DevSecOps, security and engineering leaders can ensure that their organizations are well-prepared to face the evolving threat landscape—keeping operations secure, compliant, and efficient.

If you’re interested in embracing the power of SBOMs and ConMon but your team doesn’t want to take on this side question themselves, Anchore offers a turnkey platform to unlock the benefits without the headache of building and managing a solution from scratch. Anchore Enterprise is a complete SBOM-powered, supply chain security solution that extends ConMon into your organization’s software supply chain. Reach out to our team to learn more or start a free trial to kick the tires yourself.