Last Updated on May 9, 2023
How long will it take the software bill of materials (SBOM) concept to move from buzzword to an expected part of every software release?
Tim Mackey, Head of Software Supply Chain Risk Strategy at Synopsys, thinks it will happen within the next 18 to 36 months.
“It’s going to come on us very quickly, where most enterprise level organizations—your midsize businesses and higher—will be operating with an SBOM-centric mindset for their application procurement and governance,” Tim relates.
Why so fast? The biggest driver is US government policy, currently taking the form of the National Cybersecurity Strategy from March 2023. Government agencies are mandated to use their purchasing power to up-level the application security and overall cybersecurity capabilities of their suppliers, which at the end of the day touches nearly every US software producer.
Baking in SBOMs
Should development orgs bake SBOM generation into their secure software development lifecycle (SDLC)?
“Yes, categorically,” Tim underlines. “In fact, we should think of it as multiple phases of SBOM. So, the developers have their SBOM, which represents the packaging side of the equation. And we need something that represents the running state. Now you can start to say, ‘This is the set of changes that the development team is producing. I want to make certain that my operations team understands the implications of those changes.”
In short, security-related decisions on the part of developers will impact the operations team. For example, if you need to quickly patch something, should you do it in the VM or in the container image itself? Dev and Ops will use the same SBOM to guide their planning.
“[An SBOM] gives them an opportunity to say, ‘Hey, wait a minute, you’ve changed the risk profile of this application,’” says Tim.
He uses the example of a third-party, AI-powered spell checker in a web application. Initially it’s accessible in only a few areas of the application, which is OK. But then someone decides to apply spell checking across the application, without fathoming the security questions. Suddenly responses are sent over a non-US cloud service to be spell-checked.
That’s basically a data leakage issue. What are the ramifications for security, compliance, and operations? Better to see these things coming proactively by sharing an SBOM between Dev and Ops during the SDLC.
Belt and suspenders
Seen in a broader context, an SBOM is akin to a “belt and suspenders” for threat modeling.
“As we through this SBOM world, today we always think about it in terms of understanding open-source vulnerabilities,” offers Time. “But the real challenge is to start saying, ‘If I don’t use the word open-source and I don’t use the word vulnerability, what other kinds of things can I do if I only knew what was inside the software?’”
For example, a robust SBOM can give teams a way to map APIs and the data flows going out of them. What component is actually doing a specific operation? What component actually supports a specific data traffic flow? It could be a hidden “phone home” mechanism you didn’t previously know about.
For more guidance on this topic, listen to Episode 116 of The Virtual CISO Podcast with guest Tim Mackey from Synopsys.