Nate Walker

First Up: What are SBOMs?

SBOMs are revolutionizing the cybersecurity approach in software development. SBOM (typically pronounced "es-bom", phonetically) stands for "Software Bill of Materials" but has recently grown to include the meaning "SaaS Bill of Materials", as well. An SBOM simply functions as a comprehensive listing of the software ingredients that make up a specific application. Just as a chef meticulously lists every ingredient that goes into crafting a delectable dish, a software engineer catalogues the components that constitute an application through an SBOM.

The Evolution From Manufacturing to Software Development

For several decades, a traditional Bill of Materials has been used throughout modern industry to list all the materials required to produce a particular product. Think about manufacturing, for example, where workers on the production floor may receive a production order in which to create a particular product. Part of the order that comes through may contain a certain kind of BOM, telling them exactly which ingredients to procure and how much of each kind is required for the needed product. Accuracy here is paramount, as you may imagine, since if your BOM is not accurate then you will not produce the product you need to ship.

While the manufacturing industry may have their own issues to worry about, such as structural integrity and maintaining consistency across a product line, software developers leverage a Software Bill of Materials to keep an accurate accounting of the software components found in their application. This SBOM effort benefits both the software company and the company’s customers by elevating their software supply chain risk management posture.

IMPORTANT: SBOMs do not mean that developers give away their precious crown jewels!

The Core of the SBOM

Having an SBOM does not mean that developers and software companies betray how they designed algorithms or that they divulge architectural details beyond that which is necessary for compliance and B2B transparency.

What an SBOM is, however, is a listing of the software componentry included within a given company’s software product. Depending on the nature of that product, the details of the SBOM could vary widely, but should include information like:

  • Key third-party libraries
  • Open source dependencies
  • Licensing information
  • Version numbers
  • Any and all software relationships critical to the functioning of the application. 

Keep in mind that this documentation not only lists that there is such a relationship, but where that relationship lives. The where is critical as that helps security teams and developers hone their attention if a particular component requires remediation.

For example, if I made the best scrambled eggs in the world and told you that such a recipe only required three eggs, then I have not told you exactly what to do in order to achieve culinary success with those ingredients; there’s a difference between knowing the ingredients and knowing the recipe. 

Introducing the SaaSBOM

Similar to a standard SBOM is a SaaSBOM, focused on the SaaS offerings a company  partners with. Modern companies rope in SaaS organizations all the time to deliver a wide variety of services, ranging from security-related purposes like authentication and web application firewalls, to other key company functions like task management and marketing campaign creation.

Tying in external SaaS services can be critical in delivering a company’s own, unique offering, but it can introduce a new layer of security risks that must be noted. What if a company relied on a SaaS product or identity provider to provide authentication for their platform, and that SaaS product went down? Or, worse yet, what if that SaaS product is the victim of a compromise? A company’s leaders would want to know exactly how that affected product ties into their platform so they can act decisively and communicate effectively, both internally and externally. In this case, their SBOM would contain their own code elements plus the SaaS solutions they subscribe to for product delivery. 

SaaS functions run the gamut and organizations need to keep track of what SaaS solutions are in place and what role they play.

Navigating Transparency

Now, what if there are ingredients that you do not want to be made public? Or, perhaps you only want to make certain information public and then share more information only after you have established a trusted relationship with another party?

You could have an SBOM that is made publicly available with limited information, while another, more detailed document is then ready to share once an NDA is signed. Or, perhaps you are reticent to share details like version numbers and the like. The good news here is that there is no cut-and-dry approach to the creation or maintenance of an SBOM. Planning, developing, and sharing that SBOM is what matters and what elevates your company’s transparency to the next level.

Consider using a tool such as SafeBase to easily publish Trust Center Updates for customers to easily be made aware of information about the SBOM details you want to share publicly and any other security protocols they should know about. Get in touch to learn more about our Trust Center platform today.

Next Stop: Why SBOMs?

SBOMs have only recently come into the limelight as something that companies have been requesting when evaluating another company’s software product and/or security posture. Why is that, you may ask? Well, the answer lies in a string of high profile cyber attacks that exploited vulnerabilities in the software supply chain to target downstream organizations which have occurred in recent years.

A Call for Transparency

As noted before when talking about SaaSBOMs, more and more companies are wanting to see who the third-party servicers are that may be involved with any given product. Companies may not have had to worry about this in the past, but the heavily integrated fabric of SaaS products has created a demand for increased transparency. A compromise of any one SaaS offering has the potential to impact other companies downstream, so customers simply want to be aware so they are prepared. 

Governments are catching wind of this need for transparency and making a direct push for change. In the U.S., the 2021 “Executive Order on Improving the Nation’s Cybersecurity” specifically calls out a need for SBOMs and likens them to the “list of ingredients on food packages.” The European Union’s GDPR mandates a list of subprocessors, which are simply a list of all companies through which a customer’s data may pass through in the delivery of a particular service. 

Vulnerability Mitigation: A Case for SBOMs

One of the strongest arguments for SBOMs is the Log4j panic of late 2021, where a vulnerability was discovered within a very small Java logging utility. The vulnerability was critical because it allowed a knowledgeable attacker to inject malicious code onto a vulnerable machine, bypassing security controls. Published by the Apache Software Foundation, one of the largest open source software platforms in the world, this logging library has been incorporated into all kinds of applications.

What started out as a normal vulnerability disclosure soon became a crisis as IT teams all around the world realized that this Java vulnerability was everywhere. Many IT and security teams realized that they did not have full visibility over their IT assets, let alone the number of instances of the Log4j logging library as they began the laborious task of tracking down and remediating all instances. During this time, companies and customers wanted to know - “Are our vendors impacted?”, “Are any vendor subprocessors impacted?”, “Are WE impacted?” Large organizations and government entities found themselves wading through a never ending bog of vulnerability scans, sifting through the rubble of reports, looking to find what necessitated remediation.

Here is where the why of SBOMs steps into the spotlight.

Organizations were frantically attempting to find Log4j in every digital nook and cranny because they had zero visibility into what was inside of the applications they were using. Were they to have had SBOMs, which, remember, provide only a listing of certain software ingredients of a given application, they would have been better equipped to react in a more timely and strategic manner. This is the very reason why the Federal government is requiring SBOMs for software providers and why the Cyber Safety Review Board (a security industry group composed of U.S. government and private sector security leaders) dedicated their first report entirely to the subject of Log4j. What was one of their main suggestions for enterprise risk management? You guessed it - SBOMs.

The Benefits of SBOMs

By offering a bird's-eye view of your software ecosystem, an SBOM empowers you to:

  • Predict Vulnerabilities: A well-constructed SBOM lets you identify vulnerabilities in third-party components, ensuring that your application isn't compromised due to a weak link.
  • Accelerate Remediation: With clear visibility into software relationships, you can swiftly address vulnerabilities and initiate the necessary remediation steps, minimizing the window of exposure.
  • Enhance Compliance: Regulatory requirements are tightening across industries. An SBOM enables you to maintain compliance with regulations by providing transparent documentation of your software supply chain.
  • Strengthen Vendor Relationships: When vendors and partners recognize your commitment to transparency, it fosters trust and can lead to more collaborative relationships.

Remember that the why of the SBOM is two-fold: As you increase the transparency of your product, therefore enabling your sales team and adding luster to your external security posture, you simultaneously bolster your internal security posture.

Final Destination: The Purpose of SBOMs

What’s important to understand is how an SBOM is one piece of an organization’s security awareness and security preparedness program. Organizations with clear and accurate SBOMs are more prepared for security compromises and more readily prepared to meet the needs of B2B customers in an honest and genuine fashion.

Should a security incident arise where a software dependency or SaaS product has been compromised, well prepared teams, with SBOMs in hand, can take swift, targeted, immediate action since they will know where those dependencies lie within their environment.

Further Reading

Ready to learn more about SBOMs? Here’s some great links to get started:

‍

SafeBase is the scalable Trust Center that automates the security review process between buyers and sellers. With a SafeBase Trust Center, companies can seamlessly share sensitive security documentation with buyers and customers, including streamlining the NDA signing process by integrating with your CRM and your data warehouse. 

If you’re ready to take back the time your team spends on security questionnaires, create a better buying experience, and position security as the revenue-driver it is, get in touch with us.