On April 2023 CISA released a new joint guide for software security called Shifting the Balance of Cybersecurity Risk: Security-by-Design and Default Principles. The Guide was composed with the cooperation of 9 different agencies including the NSA, Australian Cyber Security Centre (ACSC), and Germany’s Federal Office for Information Security (BSI), among others. The fact that multiple agencies from around the world have cooperated in preparing a cybersecurity guide should be a strong testament to the importance the topic of cybersecurity holds worldwide at this point in time.
Jen Easterly, CISA’s director has shared her thoughts on the topic of cybersecurity in a recent speech she gave to the students and faculty at Carnegie Mellon University in Pittsburgh. According to the CISA director, these guiding principles should help shepherd the global software industry in the coming years:
- The burden of safety should never fall solely on the customer. Software manufacturers should take responsibility for their products and code.
- Technology manufacturers should embrace radical transparency as a commitment to accountability for their products.
- Technology manufacturers should focus on building safe products, developing ones that are both secure by design and secure by default.
The CISA guide takes these basic principles and expands on them, including a comprehensive list of practical suggestions that software manufacturers can take to bring more secure products to the market.
It’s interesting to note that a lot of the explicit suggestions are based on NIST’s SSDF framework but phrased in a more practical, less voluntary fashion.
One of the suggestions in the guide, that directly relates to radical transparency, is for software manufacturers to include the production of an SBOM in their SDLC to provide visibility into their software’s components.
But is creating an SBOM and even publishing it really enough? What can a software producer or a software consumer actually do with an SBOM JSON or XML file?
In this article, we’ll look into the uses that an SBOM can bring to a software producer today, the information that can be added to an SBOM to enrich it, and the business intelligence that can be gained from examining such enriched documents. We’ll take a quick look into the compliance side of using an SBOM and where your liability lies as a software producer, a software aggregator, or an open-source maintainer. We’ll close by talking about risk management and how CISA’s principles of secure by design and secure by default mesh with cybersecurity regulatory compliance and enlightened risk management.
Not All SBOMs Were Created Equal
There are many tools available today for the creation of SBOMs, from open-source to proprietary solutions, a person or company wishing to include SBOM creation into their SOP could easily do so. One could choose between the different standards the one most suited to their needs but even then you could be facing way too many tools to make an informed decision. So, what more could you be looking for when deciding on just the right SBOM generation tool for you?
First, check what information is included or omitted in the creation of the SBOM. A bill of materials that includes tools and code that were part of the development process but not part of the actual product would probably contain a lot of redundant information that is very difficult to ‘clean’ out of the resulting file to enable you to keep only the most relevant information. Likewise, tools or code that is not included or purposely omitted would be conspicuously missing when you want to scan for vulnerabilities, for example.
The list of software ingredients and dependencies, in and of itself, is mostly meaningless. It serves very little purpose beyond what you can choose to do with it. The most prevalent use of SBOMs today is to scan the software components to get a list of vulnerabilities that might affect your product.
It’s important to remember that about 95% of vulnerabilities that you discover are not exploitable in your product. The trick is to find that elusive 5%, make a work plan and start dealing with these exploitable vulnerabilities. How to tell what is exploitable and what isn’t? That’s the big question that keeps security and engineering people up at night. One current suggestion is to employ a solution called VEX – a Vulnerability Exploitability eXchange, a form of a security advisory where the goal is to communicate the exploitability of components with known vulnerabilities in the context of the product in which they are used. It still leaves a lot of the work of sifting through the haystack of vulnerability information and finding the needle of exploitable vulnerabilities mostly up to the engineering team. After all – who would know their product better than the people who coded it?
There are other things you can do though, especially when it comes to inherited vulnerabilities that come from parent images of your docker image or from dependencies far back in your dependency chain. Using open-source tools like parentimage you can figure out which vulnerabilities came with the parent image and which were a direct result of your code. That should eliminate a potentially large pool of vulnerabilities and make the sifting job easier. Using various advisories about different vulnerabilities is also a good idea as once you have determined that a vulnerability isn’t exploitable it makes sense to let others on your team or your users know so that you don’t keep checking the same vulnerability in every version of your product where you didn’t even modify the module where it was found in. It’s also advisable to follow your open-source and 3rd party dependencies so that once they find and fix exploitable vulnerabilities you can update that code in your product to make sure you are also protected from that particular potential problem.
What More Can You Add Over an SBOM?
As stated above, one of the most common uses for SBOMs today is as a checklist for vulnerability scanning. Using various freely available databases like the NVD (National Vulnerability Database) you could scan a list of components, similar to the one provided by an SBOM, and see which vulnerabilities it contains. Once you have a list of vulnerabilities you can order it by severity, check if any have existing fixes, and so on.
Another layer of information that is useful to have about your components is their license. A lot of open-source components come with a license that is not compatible with commercial use. It’s important to make sure that all your open-source components, even ones you didn’t include yourself but were included by some other component, are compatible with whatever you’re trying to make in terms of their license.
One final suggestion is to follow open-source security ‘health’ meters for your dependencies such as the OpenSSF Scorecard. Having an objective relatively simple measure for open-source libraries’ cybersecurity health could be a great help in deciding which libraries to include or omit from your product. These scores combined with the vulnerabilities severity are a good way to help order the vulnerabilities you want to work on first.
Risk Management as a Business Intelligence Exercise
There exists multiple security risks for any software producer to deal with these days. Between malware, crypto miners, password stealers, and ransomware it’s a wonder manufacturers feel safe to bring anything to market. No one can handle everything all at once so companies create threat models and try to manage their risk according to what they consider to be their weakest links. The easiest first step is to make sure your code and development process is compliant with any relevant regulations and best practices. Nist’s SSDF and OpenSSF’s SLSA are a good place to start as well as the US requirements for things like an SBOM. Following the regulations and best practices could at least promise relative safety from litigation under the Safe Harbor program. But that is only the start.
The CISA guide encourages manufacturers to approach building their products with security in mind first. Some ‘bolt-on’ security after the product is done cannot mitigate some fundamental weaknesses that are part of the product’s architecture. According to the guide, products that are Secure-by-Design are those where the security of the customers is a core business goal, not just a technical feature. Manufacturers are also encouraged to embrace radical transparency and accountability. That means, among other things, ensuring that vulnerability advisories and associated common vulnerability and exposure (CVE) records are complete and accurate. It also means that the components of the code, its dependencies, and vulnerabilities are encouraged to be shared as a way to show users and customers that the manufacturer is at least aware of potential problems in the product.
According to Wikipedia, Business intelligence (BI) comprises the strategies and technologies used by enterprises for the data analysis and management of business information. As you can imagine, collecting an SBOM for each build as well as the vulnerability report, the license information, and the advisories that break down which vulnerabilities are and are not exploitable – that’s a lot of information. The number of information points increases when you factor in the lifespan of a typical software product and the fact that you want to have this information for any 3rd party code or tool you’re using as well as open-source packages you’re including, directly or transiently. In order to make sense of it all in a way that is usable by the security powers-that-be of the organization (probably the CISO and the people under them) you need a system, a single ‘pane-of-glass’ platform that allows you to organize all that information, search it effectively and present it in useful reports when needed. To give just one example of how critical a BI platform could be for a cybersecurity platform, imagine the Log4J drama of last year. Wouldn’t it be awesome to search all your products including dependencies and 3rd party tools with a few keystrokes for this ‘new’ menace? What about checking for the presence of a different new threatening CVE that just came out? Or preparing a report on how your company’s overall number of vulnerabilities is progressively decreasing over time (or at least not increasing). That’s the kind of useful ‘big picture’ information that only a BI system on top of a cybersecurity SBOM-enriched collection platform can offer.
Only once you have all the relevant information could you truly evaluate your risk, both in your current code, in your dependencies, and in choosing to include or omit some 3rd party tool or code from your product. When ran continually you could also use this risk assessment to gatekeep builds and stop them from production or delivery if some suspicious activity is discovered.
Looking to the Future
Technology keeps advancing all the time. If once monolithic code projects sitting on servers located in the organization’s office were the norm, nowadays it’s multi-cloud micro-services architecture and LLMs leading the way. SBOMs need to keep advancing to be able to support whatever complex architecture or infrastructure software utilizes to keep their relevance and usefulness. OWASP’s CycloneDX, for example, is already working on including ML transparency in their SBOM format. The same format is also making sure to include VEX capabilities and an SBOM sharing API when planning for the future. I predict that more and more platforms such as the one created by Scribe will be created for the accumulation and sharing of security-related information including SBOMs, both for regulatory reasons and for the benefit and value that such enriched information holds for the organizations utilizing it properly.
Scribe’s platform is about to release a new BI tool as part of the existing security platform with all the capabilities I suggested and more. I encourage you to give it a try, see the usefulness of such information accumulated over time and see what you can use the information for. Regardless if you chose to incorporate the Scribe platform into your SDLC or not, the race for a more secure ecosystem and a more comprehensive, useful SBOM is far from over. It’s better to get on the transparency wagon now rather than have radical transparency forced upon you by regulation or market pressure.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
