A little more than a year ago — in response to SolarWinds and Log4j exploits — the White House issued Executive Order 14028 on Improving the Nation's Cybersecurity.

Of particular emphasis in that order was the mandate to enhance software supply chain security, and, more specifically, the introduction of the Software Bill of Materials (SBOM).

Commercial software often lacks transparency, sufficient focus of the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. Essentially an SBOM is a list of ingredients, components and libraries used by software — in theory it will allow organizations to determine exactly which third-party commercial and open-source software makes up the enterprise software package.

Here are some of the most important SBOM discussions that should be on every security leader’s radar as the security strategy graduates from the definitions phase and makes the first steps toward real-world implementations:

1. The front- and back-ends of SBOMs still yet to be defined

SBOMs will need a secure back-end layer for storage and integrations. Developers will need a front-end that brings security vulnerabilities into their workflow in a way that doesn’t cripple productivity.

2. Automation will be critical

Maintaining terabytes of data and logs that no one is looking at is a waste of time and money. Federal and state governments — by virtue of the Executive Order — will be the first major consumer of SBOMs. But for SBOMs to take off, they will need to be designed with automation in mind. For SBOMs to take off in government, they will need to bring automation to the Federal Risk and Authorization Management Program (FedRAMP) process.

3. Continuous monitoring may help maintain SBOMs

The world has so much software — open source projects, programming language frameworks and libraries — that not only did most organizations not know about the Log4J vulnerability, but even when they did know, they didn’t know if and where they were running Log4J. One SBOM feature will be continuous monitoring that tells organizations not only when something has changed that changes their security posture, but if and where they are running it.

4. Without uniformity of SBOM information, this will be a mess

As an industry, cybersecurity leaders should aim to streamline the SBOM process and treat it as uniformly as possible. The worst scenario is having a complex framework that nobody understands and therefore ignores. Security leaders should think of SBOMs as a first step in software supply chain security.

5. There will be multiple SBOM frameworks

National Institute of Standards and Technology (NIST) and Open Web Application Security Project (OWASP) have different frameworks. The government can not determine that an organization must have one framework over another, but companies will need to be agile enough to be able to consider any SBOM framework.

6. Better collaboration between companies and agencies

The SBOM's ability to accelerate collaboration between security peers will have a great impact on the nation. Theoretically, if the cybersecurity field can achieve better information sharing on security exploits through SBOMs, the country is going to see a lot more of this type of collaboration in safe spaces.

Log4j and SolarWinds woke the industry up to the side doors presented by insecure software artifacts and the exploits made possible by their transitive nature. Government and companies alike are in total agreement that organizations need to know what’s inside their software and where it is running — and that this is step one in this software supply chain security movement.