“Frodo: I wish the Ring had never come to me. I wish none of this had happened. Gandalf: So do all who live to see such times, but that is not for them to decide. All we have to decide is what to do with the time that is given to us.”

In the Lord of the Rings, Book I, Chapter 2, the wizard Gandalf explains the history of the Ring to the small and frail hobbit, Frodo. The “it” to which Frodo refers is the finding of the Ring by the creature Gollum, as well as the return of Sauron, the dark lord. Gandalf’s response to Frodo’s lament is both heroic and fatalistic. The wizard’s words are heroic because they insist that one must rise to the challenge offered by one’s time.

At the same time, however, there is also the suggestion that one is born at a particular time and in a particular place for a certain preordained purpose. The decision is, of course, not one’s own to make; however, Gandalf implies that it is a decision that is made somewhere and that their “time” has been “given” to them. As I think about the time and the place that I am at as a security leader in 2022, I see an industry and colleagues living in challenging times. The task that we have been given is quite large, one could even say it is both heroic and fatalistic. When we are saying things like, “It's not if you are going to be breached, it's when” and constantly struggling with the basics. It can feel some days that the job we have is very daunting.

Software Bill of Materials, or SBOM – it is one of the biggest buzzwords associated with another famous buzz phrase, software supply chain. For me personally SBOM has been a two-year love affair. Having the early part of my career being started around technology, data and quality, and thinking about technology as really nothing more than manufacturing the elements of Six Sigma, Lean manufacturing and analogies to the management advancements of iconic companies like Toyota and Motorola, SBOM has captured my attention.

For those of you not familiar with SBOM, a SBOM is, From NTIA’s SBOM FAQ “A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e. compile and link) a given piece of software and the supply chain relationships between them. These components can be open source or proprietary, free or paid, and widely available or restricted access.” A good analogy that I have often heard around SBOM is that it is like a list of ingredients on the packing of a food product.

As a security leader I think about the SBOM as summary data of an asset or an endpoint. Just a lonely, little (or maybe huge) piece of information floating around in the environment I am charged with protecting. We security leaders have inventory of our other endpoints (laptops, servers, etc…). Having data about that SBOM is valuable. A month and a half ago spotting log4j in an SBOM would have been valuable. In the same way we can look at a single, lonely little laptop in our environment and see asset information such as OS, vulnerabilities, etc… We can also scan an SBOM for vulnerable packages. It’s insightful but not helpful at scale.

Organizations today rely on dozens, to hundreds to thousands of software to run their businesses. I’ve worked for companies that have thousands of 1st party software, most of that 1st party software is open-source software that is cobbled together in a way that solves a problem the company is trying to solve. And let’s not forget about the tens of thousands of 3rd party software that they rely on as well.

So, the question is, what is the security leader going to do with the SBOM? I’d like to propose that just like our lonely laptop example above, we need to have a complete and single view of the bill-of-materials that run our organization. Not just endpoints, but also resources; not just the SBOM for a single 1st or 3rd party application but everything. We need SBOMs, IBOMs (Infrastructure-Bill-of-Materials), API/URIBOMs, LocalFileSystemBOMs, etc.... Combining them together to form the OrgBOM. In short answering the question, what is the bill-of-materials for our organization?

One OrgBOM to rule them all. One OrgBOM that is a de-duplicated, single pane of glass, where I can compare my 1st party technology with my 3rd party technology. One OrgBOM where I can scan it frequently for Vulnerabilities, Compliance, Discovery and Completeness. One SBOM where I can drill in and determine the riskiest components that my organization relies on. One (S)BOM to rule them all.

My prediction is that this is going to be a category that is created over-night. As we read in the President’s Executive Order on Improving the Nation’s Cybersecurity, last May, the federal government has laid out the requirement of SBOM across all federal agencies. The key will be how can 1. Organizations that provide software to the federal government provide SBOMs on a frequent, automated and repeatable basis? 2. Can the federal agencies digest, organize and contextualize SBOM and understand the risk in its portfolio. 3. Can both the supplying organizations and the federal government interact and exchange and understand exploitation risk on those technologies? 4. What will the adoption be in the private sector as a result of this shift?

Using SBOM as a tool to enable organizations to manage their risk with clarity and speed will enable security leaders and organizations to granularly understand their software risk. Perhaps it will make our jobs a little less heroic and fatalistic. Like Frodo’s journey in Lord of the Rings, may we rise to meet the purpose we have in the time that we have.