Moti Gindi, Chief Product Officer at Apiiro, recently sat down with VMblog to discuss the company’s new XBOM (Extended Software Bill of Materials) platform, modernizing the way organizations manage their software supply chains.
The Q&A is a must-read for anyone who is responsible for managing software supply chains in the cloud.
VMblog: Apiiro just launched a security solution we’ve never heard of before: XBOM. From reading the news, it seems like a next-generation SBOM that’s really meant to grapple with the complexities of cloud. Can you tell our readers exactly what this new feature is and why you’ve built it?
Moti Gindi: Exactly! And yes, it is a new, novel approach to a problem that’s just getting harder and harder. XBOM stands for eXtended software bill of materials and simply put, it is an inventory of everything in your application and the ecosystem surrounding it.
Apiiro was built from day one to deeply understand and analyze application components, their interconnected relationships, their associated risks, and how all of those pieces change over time. We also, along with every other security vendor, have an SBOM solution, but we heard from our customers that while SBOMs check a box, the real value they see from Apiiro is the platform’s deep visibility that they’d never had before. Putting two and two together, we decided to align our graph-based approach to visibility as the gold standard for XBOM going forward.
The list of technologies and frameworks supported in XBOM is pretty exhaustive and includes APIs, open source dependencies, data models, data access objects, protobuf messages, repositories, infrastructure as code, container images, and much more. Beyond that, XBOM includes connections between those components and the risks associated with them, their runtime context, and their changes over time.
VMblog: Can you explain a little more the decision behind creating a new term in ‘XBOM’ versus positioning as a more sophisticated or robust SBOM?
Gindi: Over the past few years, especially since the White House Executive Order on Improving the Nation’s Cybersecurity was released, we’ve seen the market decide, for the most part, that the definition of SBOM is simply a list of open source dependencies. Some are more metadata-rich and include vulnerability information, and others list additional types of components like infrastructure as code modules and container images. While there is a time and a place for those, XBOM takes a fundamentally different approach, one that is graph-based and built explicitly for cloud-native applications of which the lines between infrastructure and application layers are blurred and interconnected. XBOM mirrors the structure and reality of modern applications and solves a real need of comprehensive and real-time visibility that community projects like CycloneDX and SLSA acknowledge as well.
VMblog: I imagine that XBOM doesn’t solve all your problems in terms of application and supply chain security. Can you articulate the domino effect that will happen if security teams embrace XBOM?
Gindi: You’re absolutely right. XBOM is a tool to provide visibility into potential risks and in many ways is a starting point. But unlike SBOMs, an XBOM puts you ahead in two ways. 1) It connects the dots between multiple components to illuminate attack paths and uncovers blind spots that need to be prioritized. 2) With runtime context and deep understanding of code components, XBOM is able to understand what’s actually a risk and correlate risks to reduce backlogs. From here, you can allocate security and engineering resources efficiently.
VMblog: It seems like every security company is trying to say they do everything. They do app sec but they also do infrastructure, they do some supply chain stuff. Ultimately, it’s very difficult to tell exactly who does what unless you are very knowledgeable to figure it out. What do you make of this trend and where does Apiiro fit in?
Gindi: This is very true-and actually, that consolidation isn’t an entirely bad thing. Gone are the days where you can take a siloed approach to all those security domains. That’s just not realistic for modern applications. As the lines between application and supply chain and infrastructure layers blur-thanks to cloud-native technologies and the rise of platform engineering-security also has to evolve. Additionally, because everything is interconnected and the way components get permuted throughout the development lifecycle, it’s important to be able to connect the dots across stacks and across time. Lastly, risks can be associated with different types of technologies. For example, you can have an exposed secret in source code or a CI/CD config file. Or a vulnerability in an open source package or a container image. So being able to support multiple technologies, across the development lifecycle, and connect all the dots is crucial.
The main division in this world is between runtime environments and the code that defines them. At Apiiro, we focus on everything in code, providing industry-leading visibility across components in code and pipelines, pulling in context from runtime environments. That’s XBOM. Then we contextualize security alerts-from third-party SAST, SCA, etc. tools or native secrets, SCA, API security testing, etc. solution-within that inventory.
This has all coalesced in a new market-application security posture management (ASPM) which is a consolidation of tools plus a single pane of glass. Security teams and developers can now prioritize alerts based on several risk factors, spending less time triaging backlogs and more time addressing risks that matter to the business.
##
