logo

What Shall We Do With a Vendor SBOM?

2021-09-24

Authors:   Wendy Nather


Summary

The presentation discusses the limitations and challenges of using software bill of materials (S-BOMs) in cybersecurity and DevOps.
  • Automating the matching of vulnerabilities and exploits with threat intelligence and blocking them is not feasible as customers may not trust the organization to do it.
  • Not all customers know enough about their software to determine if it is safe to block something.
  • Partial remediation and tracking the timeline of remediation can be challenging.
  • Social graphs and tracing components may not be useful if customers do not know what to do with the information.
  • Consumers in the middle of the supply chain need to decide the depth at which they can investigate something and owe answers to downstream customers and partners.
  • The limits of S-BOMs and the knowledge that can be obtained from them should be considered.
  • SAS providers may not provide S-BOMs for their products.
The speaker mentions an application that purposely used SQL injection to update the database, and the developer was proud of themselves for coming up with the trick. This illustrates that not all customers know enough about their software to determine if it is safe to block something.

Abstract

The development and adoption of a Software Bill of Materials (SBOM) got a welcome boost from the White House’s Executive Order. Teams who have been working on this for years are addressing generation, standards, use cases, and more. Once they’re ready for consumption, though, what should an organization plan to do with them? Somebody set us up the SBOM, now what?

Materials:

Post a comment