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 competitive pressure, 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 was overwhelming —98%, but what kinds of functionality are we talking about here?

If we double click on some of the more popular GitHub repositories then we will see API libraries like SendGrid. SendGrind is a cloud-based SMTP provider that allows you to send email without having to maintain email servers. Now, let’s imagine a scenario in which SendGrid has been adopted by a significant number of organizations around the world.

A hacker comes upon the open-source API libraries on GitHub, sees that there is widespread adoption of SendGrid, and manages to find a way to exploit these API libraries in such a way that they could hijack the email communication functionality of any Web Applications using SendGrid’s API libraries. 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.

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), 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 report 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, which enables multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks. 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:

minimum SBOM Requirements
minimum SBOM Requirements

As you can likely see, looking at the Data Fields row above, SBOM v1 is predominantly focused on 3rd party library risk. However, v1 was 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, but 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 3rd party 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 posture.

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 and Legal action taken against the offending organization.

So how should you safeguard yourself against this threat, even before it potentially becomes a part of the next SBOM? Look no further than Riscosity. Feel Free to Book A Demo and let’s chat about your goals, and how we can help!