SBOM- Can it secure open source from vulnerabilities? (Part 1)

Open source is gaining popularity and developers make use of existing off-the-shelf software instead of reinventing the wheel. This comes with a necessary contract: an implicit trust that the software will perform as desired and comes with (little to) no vulnerabilities. Because of this, it has become a common practice for developers to inherently trust and use open-source software without validation.

But in reality, open-source projects do have vulnerabilities in them and if this goes unnoticed in the plethora of other dependencies used, the software/codebase is at a higher risk of being exposed. Commonly, these dependencies are used in a branch of code and then forgotten about, creating the perfect attack window for people who want to exploit vulnerabilities in the code. Such attacks are called supply-chain attacks and examples like the Solar winds, and the Log4J attack are two great examples of what can go wrong with supply-chain attacks.

A supply-chain attack or a value-chain attack is a type of cyber attack that targets organizations by focusing on weaker links in their supply chain resulting in the entire network being exposed. With developers having little or no knowledge of the dependencies that make up the software, it is easy for hackers to compromise the product as a whole, given access to one exposed or unguarded dependency.

In order to handle such scenarios and safeguard software from third-party attacks, the Cybersecurity and Infrastructure Security Agency (CISA) has proposed using SBOM to combat them.

So, now what is SBOM?

It stands for Software Bill of Materials and is a nested inventory listing all the dependencies present in the software. It includes the licenses that govern those components, the versions used in the codebase, and their patch status providing detailed visibility into the software dependencies. To sum it up, SBOM provides an in-depth composition of the codebase, a major factor that was overlooked.

It comes in 2 formats CycloneDx and SPDX; the industry is yet to standardize on a particular format and both are equally accepted.

Would having an SBOM help the situation?

Having an SBOM would be really handy in scenarios:

1. identify and remove dependencies that are rarely used.
2. replace with better alternatives, if they exist.
3. quickly revert or update vulnerable third-party patches.

But the question to ask here is: “Would having this visibility be enough to safeguard the software?”

NO. Using an SBOM can help quickly identify and reduce the time to address the vulnerabilities but is not a panacea for securing from supply chain attacks.

So, how to improve?

One possible solution would be to make use of the information present in SBOM and build a dynamic system that periodically identifies vulnerabilities and updates the SBOM as and when required. My proposal was to incorporate this as a part of the CI/CD pipeline, as it is an inevitable part of the delivery of every application and also has the capacity to perform a vulnerability scan before the product is out for production.

Another point that also needs to be considered is that SBOM is more or less like a manual inventory that needs to be updated regularly to reflect the current status of the codebase. Having an obsolete SBOM serves no purpose and is equivalent to not having one in the first place.

We will take a look into how we can automate the vulnerability scan process as a part of the CI/CD pipeline in part 2.