Towards Secure and Transparent Software

When the Log4Shell vulnerability was disclosed in late 2021, we watched the largest and most mature enterprises around the world – including our own employers – struggle to answer a very simple question: “where is this library in my network (and my product line)?”

And despite the literal months of hair-on-fire phone calls to vendors, emails to engineers, urgent board meetings, and numerous excel spreadsheets – not to mention the ruined holidays and burned out security professionals – none of that work and pain left organizations better prepared, or with more visibility into their software supply chain. When the next supply chain vulnerability strikes, organizations will have to do the same exercise all over again, searching for a new library across a slightly different environment. 

It was hard to believe this was the state of affairs of software transparency and vulnerability management. Software shouldn’t have to be this away, and we wanted to help bring on this change. 

The solution sounds simple: when you build or buy something, you should know what’s in it. General Mills knows what’s in their cereal, and prints an ingredients label for consumers to read. We inspect houses before deciding whether to buy them and take on the costs and risk of ownership. 

In 2023, software is virtually the only thing we buy without knowing what’s inside of it. 

We had seen the promise of the Software Bill of Materials (SBOM), which is often referred to as a “software ingredients label,” a way to describe and share information about the contents of software. And we lauded Executive Order 14028, signed in 2021, that required that software vendors would eventually be required to provide SBOMs to any government agency they wanted to sell to. SBOMs seemed like the first step to allow organizations to address the Log4j problem of establishing a comprehensive software inventory. Progress!

But we felt that there were still unanswered questions to adequately address the problem. If the CISO of a large hospital or a government agency was going to receive hundreds, thousands, or even tens of thousands of SBOMs (which are effectively machine readable files that aren’t easily readable by humans):

  • What were they going to do with them?

  • Where would they store these files?

  • How would they use the novel data in SBOMs to actually take action to reduce their risk and respond faster to vulnerabilities?

  • How could they use SBOMs to buy more secure software in the first place?

We looked around the market and couldn’t find any tools that adequately address this gap.

We launched Manifest in 2022 to effectively solve the problem of SBOM operationalization, with the goal of helping organizations secure their software supply chain and turn the next Log4Shell nightmare into a one-click issue. Our mission is to make SBOMs and third-party risk the easiest thing your enterprise does. 

Since then, we have built the world’s first all-in-one SBOM management platform, allowing our users to generate, solicit, aggregate, monitor, analyze, and report on SBOMs, ultimately driving users towards action. We’ve raised multiple rounds of funding, partnered with some top-tier customers across healthcare, defense, and aerospace, and have been awarded several government contracts. 

It’s been an exciting first year, to say the least. And we can’t wait to see what the future holds for Manifest!

Previous
Previous

Introducing Manifest