• Home
  • Blog
  • The Benefits and Challenges of Reporting vs. Remediation with SBOMs

The Benefits and Challenges of Reporting vs. Remediation with SBOMs

Reporting vs. Remediation with SBOMs
Reporting vs. Remediation with SBOMs

As organizations look for solutions that enable them to create a software bill of materials (SBOM) to ensure they’re meeting new governmental mandates for protecting the software supply chain, it’s important to understand the difference between solutions based on reporting vs. remediation. The primary focus of any SBOM solution should be on open source code. The use of open source continues to expand exponentially. Open source components comprise 60%-80% of today’s applications. Unfortunately, open source is also attractive to cyber attackers. In 2020, almost 10,000 vulnerabilities were found in open source code.  

Unlike commercial third-party components for which the SBOM requirement can be rolled onto the producer, open source is written by communities that can’t take on such a responsibility. As such, organizations must create SBOMs that address open source code. Broadly speaking, the two types of solutions for doing so are reporting-centric solutions and remediation-centric solutions.

Reporting-Centric SBOM Solutions

Reporting-centric SBOM solutions basically do just that: report on various elements in software code. However, such solutions have a number of problems, including:

  • Slowing product development: Many SBOM tools identify vulnerabilities, but they don’t identify a clear pathway for remediation. Each time a vulnerability is identified, the development team must stop what they’re doing to research a fix, which slows down the speed of product development.
  • Lacking complete coverage: Many tools only cover certain languages or package managers, which results in an incomplete SBOM. Partial SBOMs don’t meet governmental requirements and expose the producer to risks.
  • Failing to automate: Government mandates call for machine-readable SBOMs that are automatically generated. Without full automation, SBOMs don’t meet governmental requirements and slow down product releases.
  • Not scaling: Many tools fail to scale across the software ecosystem, particularly across organizational boundaries. Such tools create an operational bottleneck and slow the release process.
  • Alerting on false positives: Most of these reporting-centric SBOM tools have a high false-positive rate, which adds to the burden placed on security teams as they struggle to identify which alerts need to be addressed first.

SBOMs created with reporting-centric solutions ultimately increase risk by including unfixable and sometimes nonexistent vulnerabilities. Likewise, they put users at a competitive disadvantage because their software is considered a security risk.

Bridge the Gap Between Security and Developers:

Remediation-Centric SBOM Solutions

Remediation-centric SBOMs address the weaknesses found in reporting-centric solutions and keep SBOMs from becoming another burdensome reporting requirement that fails to decrease risk. It’s also important to note that additional regulations are expected in the coming months that address fixing (and not just reporting) security vulnerabilities.

There are a number of benefits associated with SBOMs that are produced as part of an integral remediation-centric security program, including:

  • Identifying vulnerable components and fully integrating into the software development life cycle (SDLC): The focus is on helping developers remediate issues quickly and easily and keeping their code up to date. This starts at the sourcing stage by avoiding problematic components and continues with the identification and recommendation of component upgrades as they are released. This enables teams to stay up to date with the latest versions, which are usually the most secure.
  • Identifying vulnerable versions and suggesting the best fix: Merge Confidence is used to identify the version age and date of adoption, and identifying the potential for vulnerabilities to break the build. This gives development teams the data needed to quickly make remediation decisions.
  • Removing unreachable vulnerabilities: Analyzing whether a vulnerable component is referenced by the code provides teams with actionable insights on whether the vulnerability affects the code, and its exact location, if it does. This saves teams from the time-consuming task of eliminating false positives, and helps them zero in on the issues that matter most. 
  • Quickly and accurately assessing risks of newly uncovered vulnerabilities: This provides transparency across dependencies within the software ecosystem, improving both vulnerability identification and the speed of response.
  • Creating greater efficiency and effectiveness: Better visibility into code enables prioritization and better management of risk.
  • Automatically creating SBOMs in a machine-readable format: This makes vulnerabilities actionable and meets governmental requirements for SBOMs. 

Related: A Guide to Standard SBOM Formats

Remediation-centric SBOMs reflect the health of the product, and the process is used to continuously identify and address supply chain risks. This creates a competitive advantage for organizations by reducing the security risk and speeding the development process.

The new Mend SBOM is a remediation-centric solution that gives organizations these benefits and more. To better understand the benefits of Mend SBOM, you can take advantage of a free trial or reach out with questions today.

Meet The Author

Adam Murray

Adam Murray is a content writer at Mend. He began his career in corporate communications and PR, in London and New York, before moving to Tel Aviv. He’s spent the last ten years working with tech companies like Amdocs, Gilat Satellite Systems, Allot Communications, and Sisense. He holds a Ph.D. in English Literature. When he’s not spending time with his wife and son, he’s preoccupied with his beloved football team, Tottenham Hotspur.

Subscribe to Our Blog