Last week, the godfather of AI, Geoffrey Hinton smashed the glass and activated the big red AI alarm button warning all of us about creating a world where we won’t “be able to know what is true anymore”. What’s happening now with everything AI makes all the other tech revolutions of the past 40 plus years seem almost trivial.

With all the cybersecurity benefits an SBOM offers, it’s a wonder they weren’t used in the software development life cycle long ago. Today, the need for SBOMs has grown more urgent because open source has become a core part of modern software development. At least one report finds that 75% of all codebases audited were composed of open-source components with known security vulnerabilities.

The software bill of materials (SBOM) has become an increasingly important tool for providing much-needed clarity about the components that make up software — both for application security purposes and governmental compliance. Unlike manual spreadsheets, SBOMs standardize everything into a particular format to minimize inconsistencies. There are three primary SBOM formats currently available, which allow companies to easily generate, share, and consume SBOM data.

Computer software is a complicated construct composed of numerous diverse components. Open-source software is becoming ever more common as a building block in software. This phenomenon is accompanied by an increase in exploitable vulnerabilities, so being able to tell quickly what your software is composed of is becoming increasingly important - both in applications that you develop yourselves and the ones from suppliers and vendors.

A Software Bill of Materials – better known as an SBOM – can enhance your compliance posture. But how do you structure and operationalize it to ensure that it is helping with that objective? And how do you know if your SBOM complies with the Executive Order that mandates maintaining an SBOM?