First Up: What are SBOMs?
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 is simply a listing of the software ingredients that make up a specific application.
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!
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, and 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.
Similar to a standard SBOM is a SaaSBOM, where companies maintain listings of the SaaS offerings they partner 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. A company may also make the strategic decision to save developer time by using a SaaS tool to achieve a desired function, giving developers the ability to focus on other important tasks.
Tying in external SaaS services can be critical in delivering a company’s own, unique offering. 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 would want to know exactly how that affected product ties into their platform in every way 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.
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 SBOM 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.
Next Stop: Why SBOMs?
SBOMs are not an effort to be taken lightly. SBOMs have only recently come into the limelight as something which 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 which have occurred in recent years, where the attackers infiltrated the software supply chain in order to victimize other organizations downstream. There is also a direct push from governmental authorities around the world for increased transparency for this very reason. In the U.S., the 2021 “Executive Order on Improving the Nation’s Cybersecurity” specifically calls out a need for SBOMs and how SBOMs will act as “analogous to a list of ingredients on food packages.”
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, too. 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.
In Sun Tzu’s The Art of War, one translation states, “So in war, the way is to avoid what is strong, and strike at what is weak.” Attackers will seek to find ways to compromise trusted, well-known open source libraries and code repositories, and/or vulnerabilities with a high degree of prevalence, knowing that developers and companies already trust these sources. If they can compromise a trusted source, then that is much easier than trying to bypass a web application firewall or brute forcing authentication mechanisms.
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.
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.
Ready to learn more about SBOMs? Here’s some great links to get started: