How SBOMs and The Digital Supply Chain Converge

Don’t Reinvent The Wheel - The Popularity of Open Source Software

Software development is not slowing down and neither are the demands for new features. In order to keep up with the needs of the market and tight deadlines, software engineers have become adept at leveraging the massive ecosystem of 3rd party libraries available in source code management repositories such as GitHub. After all, why build something yourself and waste precious time when you can use what someone else has already created?. 

3rd party library usage has become so pervasive in modern-day applications that the percentage of codebases found to contain open source code was overwhelming —98%. But what kinds of functionality are we talking about here?

The Same Faulty Lock on Every Door - The Weakness of Open Source Software

If we look closer at some of the more popular GitHub repositories, we will see API libraries like SendGrid at the top of the popularity chart. SendGrind is a cloud-based SMTP provider that allows you to send email without having to maintain email servers. Now, let's consider the scenario in which SendGrid has been adopted by a significant number of organizations around the world.

A hacker analyzes the open-source API libraries on GitHub, discovers there is widespread adoption of SendGrid, and manages to find a way to exploit it in such a way that they could hijack the email communication functionality of any web applications using SendGrid. The attack surface would be massive and these are the typical targets when it comes to 3rd party libraries – the ones that are used by many organizations with exploits that could wreak havoc. This is similar to the same faulty lock installed on many doors, thereby compromising the security of all the houses with those doors. Due to this risk in the digital supply chain, these exploits are categorized as supply chain attacks.

Protect What You Know, Know What You Protect - SBOM

Perhaps it shouldn't be a surprise then that the Biden administration's recent executive order on cybersecurity contained a requirement for a Software Bill of Materials (SBOM) to address this, but what is that exactly? 

An SBOM is a formal record containing the details and supply chain relationships of various components used in building software. In addition to establishing these minimum elements, this post defines the scope of how to think about minimum elements, describes SBOM use cases for greater transparency in the software supply chain, and lays out options for future evolution.

An SBOM provides those who produce, purchase, and operate the software with information that enhances their understanding of the supply chain, thereby providing  multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks. An SBOM will not solve all software security problems but will form a foundational data layer on which further security tools, practices, and assurances can be built. The minimum elements as defined in this document are the essential pieces that support basic SBOM functionality and will serve as the foundation for an evolving approach to software transparency. These minimum elements comprise three broad, interrelated areas:

SBOM v1 to v2 - Protecting The Entire 3rd Party Ecosystem

As you can see, looking at the Data Fields row above, the first version of the SBOM, let’s call it v1is predominantly focused on 3rd party library risk. However, this version was prescribed months ago and the world has moved on by now with adjusting to the new normal of SBOM. While SBOM v1 is helpful, it is not a silver bullet for preventing security issues that arise from leveraging 3rd parties. It's only a matter of time until there is an SBOM v2, but what could that encompass? Enter 3rd party software and their APIs.

Organizations communicating with 3rd party software via their APIs has become nearly as commonplace as using 3rd party libraries in modern-day software. However, unlike 3rd party libraries, you do not have the same level of control in remediating vulnerabilities with 3rd party software. You can bring your own open source vulnerabilities under control by updating them to less vulnerable versions, patching them yourself, or removing them but you do not control your 3rd party vendors' security postures.
‍
To add to the risk, it can be a daunting task to try to keep track of what data you are sending to your various 3rd party vendors. Imagine the flow of data in these APIs you're using from your 3rd party vendors looking something like a ball of spaghetti.

If not carefully tracked, you could be sending Personally Identifiable Information (PII) about your users without even realizing it and find yourself violating standards such as GDPR or CCPA/CPRA. Those violations often lead to large fines by regulators and legal action by aggrieved parties.