Why SBOMs are critical in the fight against software supply chain attacks

Our world is reliant on software: from the work we do to how we communicate with friends and family. But software is inherently unsafe, and many organisations simply don’t understand what makes up the software they so heavily rely on.

This has created a window for bad actors to exploit, and yet, less than half of Australian respondents to a recent survey are monitoring their third parties regularly for cyber risks, lagging behind global behaviour (44% vs 47%) according to a report by BlueVoyant.

The concept of a software bill of materials (SBOM) has emerged as a key line of defence against supply chain software attacks by helping to identify sometimes hidden components lying in third-party software. This concept, akin to a detailed recipe for software, plays a pivotal role in understanding the complexities of software components and their interconnection, leading us towards a more secure and transparent digital environment.

The goal is to clearly list every software component and every library used in creating a digital solution. This level of detail is invaluable in managing software supply chain risks and fortifying software security.

Whilst the ACSC introduced the ISM-1730 initiative in December 2021, mandating the use of SBOMs for all software products used by Australian government agencies, there is a lack of awareness in the private sector. And while Australia’s new cybersecurity strategy acknowledged the important role the government plays in “providing services to assess and secure clients’ supply chains” and wants to stamp out unsafe software, there is no mention of mandating SBOMs across the board.

Relying on real time

An SBOM should include detailed information about every software application and the presence of vulnerable packages.

When it comes to building an SBOM, most software vendors traditionally would need to involve their software development team to create and maintain them. Each newly released version of the software will need a new SBOM. However, it’s important to note that they will only be accurate at build time and will become outdated or inaccurate over time.

The lower reliability of SBOMs created at build time — as well as an over-reliance on developers and software vendors — has created a shift towards ‘runtime’ SBOMs. Leveraging real-time visibility, this approach provides continuous assessments of software components and will always provide an accurate representation of the SBOM state across all applications within an organisation on an ongoing basis without relying on input from developers and software vendors. This means you can be confident in understanding all software components in your environment and if any vulnerabilities exist at any given moment, not just when it was created.

From concept to reality

The tricky part is transforming the theoretical concept of SBOMs into a practical, powerful tool. This requires timely, accurate information about software components and vulnerabilities.

Imagine having a tool that not only tells you what’s inside your software at any given time but also alerts you to potential vulnerabilities before they become a problem. Automated endpoint management is like having a highly skilled detective who can not only identify the threat but also predict where and how it might appear next.

Having real-time visibility over your software allows you to perform software package identification at the click of a button. It’s like having X-ray vision, seeing through the complex layers of software to identify every component, whether that be a runtime library or an open-source package.

However, if you really want to get SBOMs right then you need to go beyond the identification of threats to enable granular decision-making that allows you to make nuanced decisions about your applications based on your organisation’s risk tolerance. These flexible remediation capabilities mean that organisations are not just identifying problems but are also equipped to solve them in a way that best fits their needs.

All of these insights provide the metrics an organisation needs to identify any risks posed by software. From understanding the percentage of endpoints with critical vulnerabilities or your software usage coverage, these metrics offer a tangible measure of an organisation’s cybersecurity health. It’s a way of quantifying the unquantifiable, providing organisations with a clear picture of where they stand and what they need to focus on.

The concept of an SBOM is about more than building a list of software components. It’s about building more transparent, secure and resilient organisations that are confident the software they use isn’t a threat to their cybersecurity posture.

SBOMs are not just tools but catalysts for change, driving a deeper understanding of the complexities of software and empowering organisations to take control of their digital assets. Having an in-depth understanding of your software and all the components it’s made up of seems like a no-brainer. That’s why we want to see SBOMs adopted as a minimum standard for all organisations, not just in the public sector, to give Australia a fighting chance against increasing software supply chain attacks.

James Greenwood is a Director of Technical Account Management at Tanium with 20+ years of experience in IT. James has a passion for helping customers solve complex problems through the use of technology and automation.

Top image credit: iStock.com/SerGRAY

Originally published here.