In this article, we’ll cover an example that can explain what the Software Bill of Materials (SBOM) is, and how it is referenced by various SCA tools.
You can also listen to the audio version of this article:
Very often under pressure, the team of developers needs to deliver applications and solutions faster and faster. For the market, this is a positive aspect – having news or even adjustments in processes and features desired by customers. But how about security?
It is not easy for teams to maintain a secure process within the agility that these days demand, and more and more we will need to have more control over all the steps and everything we use in the developed solutions.
The fact that we try to use tools for this does not exclude the human factor – the developer – from the equation. On the contrary, the use of these tools can give the developer more time so that they can focus more on code security best practices.
One of these paths is the existence within its development process of tools such as SCA – Software Composition Analysis – which can, in general, and through an automated process, search for open source software components, identifying compliance with licenses, software quality, and also helping to identify possible components that need to be updated.
But, underneath these tools there is a pattern that is not very commented on, but when it’s used and understood, it helps in the security process of an application.
Before we get into the SBOM pattern directly, let’s understand a little about its concept. The goal is to keep a record of all the components of a software, which is not easy. After all, according to the Open Source Edition report, 71% of the analyzed software have vulnerability in some component, and of these, 47% have transitive vulnerabilities, that is, the vulnerability of a component of the component.
Picture the following situation
We are producing cookies, and our competitors have launched a new flavor that has been very successful. So our margin is now falling, and we need a new product. So we started working on that right away.
Well, our new product needs parts, individual parts and composed parts. In this case, let’s say that our new product is going to resemble a granola bar – and that our focus is on people who want to eat healthier. So we have some ingredients like caramel, honey, Brazil nuts, salt, and a set of other nuts that we buy from a supplier.
Thus, in this scenario, we have as our unique components: salt, Brazil nuts, and honey. Therefore, the other ingredients are the composed parts.
Imagine, then, that the ingredient we buy from our supplier has peanuts in its composition. And we need to know that, because we have to put this information on our packaging, so that our customers can know about it if they are allergic.
This is only possible if we also map the components of our entire chain, including those of products that are supplied by other companies. And this is called transitive dependency.
Having that said, we can now identify that one of our components might be dangerous for some people and we can write this down as an alert on our packaging.
Very well, having understood this concept, replace the biscuit with your software, and the ingredients with libraries, and then we will have a vision of what the SBOM is and how important it is within a software process.
With this mapping, it is possible to identify which components need attention and where these components are being used.
So, this vision will answer two basic questions: Am I under any threat? And where is this threat?
Do you understand now where this is going to take us? The vision brought by Software Bill of Materials (SBOM) is a vision of threats, of all the possible problems that are just around the corner and if we know it’s coming, we can avoid it.
The use and view of the SBOM became even more evident when the administration of US President Biden published an Executive Order to improve the cybersecurity process. In this order, the need to adopt the SBOM standard in all solutions sold to the US Government was made very clear.
But what is the Software Bill of Materials (SBOM) pattern?
In the big picture – and I believe that our example has already helped in this understanding – SBOM is a chained inventory that lists and records software components, effectively showing an entire supply chain.
Like any list, this one needs to define some data that is important for its understanding and better use. There are a few SBOM models. The Executive Order of the American Government brought a minimum list of data that must compose the SBOM, but this can be identified for or by each of the tools that use this standard as a basis.
But we have some points that can be understood as common. Below I will list some of them, and I understand that the description of each one is very clear.
- Author’s name;
- Provider’s name;
- Component cryptographic hash;
- Unique Identifier;
- Relationships of this component.
Are there others? Yes, other data are part of an SBOM but, as I said, here we have to have some starting point. But there are others, for example, standards like SPDX and SWID – both with their notation structures, and information necessary for their use. But as the documentation of these models tells us, there is no need to use all the fields identified by the model, the point is to deliver enough information for the goal to be achieved.
The SPDX standard, for example, in its specification gives us a framework standard that focuses on how best to communicate components, licenses, copyrights and security information.
The SWID standard is focused on delivering transparency so that organizations can track software components and where they are being used. It is a standard based on the ISO/IEC 19770-2/2015 pattern and basically gives the manager a component lifecycle, by adding a tag to the component at installation time and removing this tag when the process of uninstalling that component happens. .
Well, that alone would give us enough themes for quite a few articles.
I believe I have managed to explain what the SBOM is and how important it is. Well, now that you know more about it, answer: how does this influence your development process? How about leaving a comment?