Why SBOM's keep us secure, and should be mandated.

Transparency allows us to become more secure, and part of the CAPA development model is standardising the Software Bill of Materials (SBOM). This inventory list details all components, libraries, and dependencies within a software product. By including this, we enable our development teams, and security professionals to build, manage, and protect software, and you should be implementing it into your development process too.

What benefits does an SBOM offer?

Modern software often relies on a huge amount open-source and third-party components. Even your favourite, most traditionalist OT vendor systems will suck in libraries from the internet. Without visibility into these dependencies, you risk using outdated or vulnerable code without realising it. SBOMs provide a comprehensive view of the entire software supply chain, highlighting which components are in use and where.

When new vulnerabilities are discovered, such as the recent Shai-Hulud vulnerability, organisations need to know quickly if, and to what extend, they’re affected. SBOMs make this possible and simple, as security teams can cross-reference to published vulnerabilities (CVEs) and take corrective action.

Why are regulators and operator paying attention?

From a regulatory perspective, governments and industries are increasingly recommending the use of SBOMs as part of secure development practices. This began via a Presidential Order in the USA for defence and critical infrastructure sectors, and is now being introduced in Europe via the Cyber Resilience Act over the next 18 months.

From an IT infrastructure and operations perspective, SBOMs improve the operations process by providing an authoritative record of what’s in a production codebase for new releases and patches. For harder to maintain systems such as firmware releases, it provides a reporting and vetting checkpoint for OT site operators to validate what, where and when software systems are being modified, and an opportunity to catch issues before they are deployed.

What about their usage in Australia?

SBOMs become part of the source of truth for ongoing software lifecycle management around the world. With vendors in Europe and the US already making the investment to publish SBOMs with each product release, it seems a relatively simple and low cost way for Australian utility operators to improve their visibility with little extra cost through the supply chain.

Whilst operators can demand the disclosure of SBOMs today in contracts, Australia should put some thinking into a regulatory mandate that mirrors the other OECD jurisdictions in requiring their use across the energy and other critical infrastructure sectors.