Before I entered the cybersecurity industry, I never thought about the risks that come with programming or even the basics of software engineering. In all honesty, I was pretty naïve. You always hear about cyber-attacks, but you don’t expect them to happen to you. However, when the Log4J incident occurred last year, many organizations and companies were awakened to the risks to their software supply chains.  

On this week’s episode of Reimagining Cyber, “Do a little dance… Time for some SLSA!,” hosts Stan Wisseman and Rob Aragao welcomed guest Dan Lorenc, founder and CEO of Chainguard Inc., to talk about SLSA, software supply chain security risks, and his opinions on Software Bill of Materials (SBOMs). 

The Development of SLSA

Lorenc and some of his colleagues at Google started SLSA (Supply-chain Levels for Software Artifacts) to set up a checklist of standards and controls to help prevent tampering, improve integrity, and secure packages of software. Lorenc explains that SLSA is built on the principle of multi-party review for anything that could affect your software, whether in the end results, the end piece of software, the end binary, the development environment, the end container, or anything else like that.

While listening to the episode, I kept thinking of the phrase, “two eyes are better than one.” I will always ask my colleagues, friends, and family to look over anything I do. Seriously, I have asked my friends to proofread the simplest of social media posts hundreds of times before posting them. Lorenc proves that multiple eyes and reviews on a piece of software help prevent any corruption or mistakes that could be very costly.

Threats on the Software Supply Chain

However, sometimes risks to the software supply chains don’t just happen through attacks on the actual software, but maybe a different version of a package in a library that many people use. Typosquatting is a thing, and it is something we all should look out for. Typosquatting is when an attacker takes a popular package and creates and pushes a version of it with a slight change in the name. This subtle change could be a typo, inserting a hyphen, or even swapping out a Unicode character. This type of attack can be hard to distinguish because how are you supposed to know the difference between the credible one and the one trying to attack you? And Lorenc sadly admits that there is currently no real known solution for this type of attack.

SBOM, Is It Worth the Hype?

Lorenc also took some time in the episode to share his thoughts and opinions on SBOMs. For a little refresher, an SBOM tries to enable you to understand the components that make up a software package and respond faster to an incident with greater awareness. You can learn more about SBOMs in this episode of Reimaging Cyber with guest Steve Springett, or see this description from the Cybersecurity and Infrastructure Security Agency (CISA). 

SBOMs has become a sort of thing that either you love or hate, and there wasn’t an exception for Dan Lorenc. At first, Lorenc was skeptical of SBOMs since they really cannot prevent intentional injection of malicious code. But now believes there are use cases for them. One of the main ones being for inventory management transparency. Before SBOMs and the new world of transparency, many organizations were at the mercy of vendors in case something went wrong, and on top of that, they had to trust the vendors even to tell them that something went wrong. SBOMs are a solution to this possible problem. The other considerable use for SBOMs that Lorenc talks about is that it can be helpful during purchasing decisions. You can use a SBOM to help evaluate between different vendor’s applications by assessing the risks of the software components being used. Just remember, SBOMs still won’t solve problems such as the integrity of the component of software you started with.

The key takeaways from this week’s episode are:

• Progress in software supply chain risk management is finally being made through new regulations and best practices.
• SLSA is an excellent tool for CISOs and technical leaders to set goals for their team and have it decoupled enough that the team learns the how and asks what the next goal should be.
• And lastly, while SBOMs can be helpful in some cases, it will not prevent malicious injection of code or be effective without supporting processes and automation.

What are your thoughts on software supply chain risks? Let us know in the comments below.

You can find the latest episode of Reimagining Cyber on Apple, Spotify, Google, Stitcher, and Buzzsprout. Give it a listen and let me know what you think. Log in or register to comment below.

CyberRes is a Micro Focus line of business focused on helping companies protect, detect, and evolve their security framework and helping organizations become more cyber resilient. To learn more, visit CyberRes.com.