A conversation on why software transparency is no longer optional, and how AI is about to make it more urgent than ever.
Every piece of software an organization runs today is, in reality, a patchwork: open-source libraries, proprietary code, and third-party components stitched together into a single product. Most buyers never see what’s inside. That blind spot, according to Dr. Allan Friedman, is one of the biggest unaddressed risks in enterprise technology.
Friedman has worked on this problem from inside government, at the U.S. Department of Commerce, CISA, and NTIA, and holds a PhD from Harvard in public policy; he is also a professor at Indiana University. He’s often introduced as the “father of SBOM,” but he’s quick to push back on the label. As he explains it, the idea of a Software Bill of Materials predates his involvement entirely; it was drawn from supply-chain and quality-management practices already common in heavy manufacturing. His actual contribution, he says, was helping carry that idea into policy circles and building a community, spanning hospitals, vendors, and the open-source world, willing to work through it together.
In a recent episode of the cyberc podcast by EC-Council, Friedman walked through the state of the SBOM movement, the rise of its sister concept VEX, and what generative AI means for an industry that has only just started taking supply chain transparency seriously.
What an SBOM Actually Is
Friedman’s explanation leans on a simple analogy: a candy wrapper’s ingredient list. Software, like packaged food, is assembled from many components: open-source libraries, proprietary modules, third-party code. An SBOM is the structured, machine-readable record of everything that went into building it.
That transparency serves multiple purposes at once, he explained. It lets an organization assess whether software carries known vulnerabilities, whether components are approaching end-of-life, and whether a vendor is managing open-source dependencies and licensing responsibly. It also has a quieter cost dimension: technical debt buried in outdated dependencies eventually gets passed on to the customer, whether through breakage, unsupported components, or expensive refactoring down the line.
Operationally, Friedman said, the real payoff is speed. When a new vulnerability breaks, an organization with SBOM data can immediately determine exposure across its software estate rather than scrambling to find out.
The WannaCry Moment That Changed the Conversation
Asked how he got software vendors and enterprises to take SBOM seriously when the concept was, in his words, close to “a career killer” as recently as 2014, Friedman pointed to a story from the WannaCry outbreak. A CISO at a major U.S. hospital had to pull his security team off active work simply to phone medical device manufacturers and ask what operating system their equipment ran on. One Fortune-listed device manufacturer reportedly couldn’t even answer consistently, and the device in question turned out to be running an unpatchable, vulnerable version of Windows.
That kind of incident, Friedman said, is what brought hospitals, critical infrastructure operators, and the open-source community into the same room. The turning point for broader industry buy-in, however, was the SolarWinds attack, even though, as Friedman is quick to point out, an SBOM would not have stopped it. SolarWinds was a compromise of the vendor’s build process, not of a vulnerable third-party component. “The mixing bowl wasn’t clean,” as he put it, a different supply chain problem than SBOM was built to solve. But the attack still shifted SBOM from an obscure corner of cybersecurity into a mainstream policy priority almost overnight.
Where Regulation Actually Stands in 2026
Sixteen years after supply chain risk first became a fixture of U.S. government conversations, Friedman says regulation has arrived, though not always in the clean-cut form it was first proposed.
A 2021 U.S. executive order originally called for an SBOM requirement across software sold to the federal government. By Friedman’s account, the requirement was progressively softened by the time the implementing language was finalized, and what emerged was less direct than the original order intended. Even so, he noted, enough major vendors had already committed to the idea that the effort pushed the industry toward building SBOM-generation capability for newer products.
More consequential, in his view, is the EU’s Cyber Resilience Act (CRA), which applies to digital products sold across the European Union’s 27 member states. Friedman described the CRA as requiring vendors to address a set of security properties, including software updates, coordinated vulnerability disclosure, and enumeration of software components, with an SBOM factoring into that compliance picture. He suggested that companies based outside Europe, particularly those selling IoT products or systems destined for critical infrastructure, are likely to draw early regulatory attention, and cautioned that many businesses aren’t yet aware of what the CRA will require of them.
Outside government mandates, the Payment Card Industry Data Security Standard (PCI DSS) has introduced a requirement that, while it doesn’t use the term “SBOM” directly, obligates organizations to track every software component, including open source, and determine whether it carries a known vulnerability, effectively imposing SBOM-like obligations through a private compliance regime. Japan and South Korea have their own national efforts underway, and Friedman noted that one of his last projects at CISA was a white paper, signed by representatives from 14 countries, affirming SBOM as a shared priority.
Confidentiality, Sharing, and the “1990s Web Portal” Problem
SBOMs are typically shared privately between vendor and customer, not published openly, partly due to intellectual property sensitivities that Friedman doesn’t expect to disappear soon. What frustrates him is how that data still gets shared: largely through static vendor portals, a mechanism he compares unfavorably to nearly every other modern data exchange. He pointed to OWASP’s Transparency Exchange API as an early, still-maturing effort to move SBOM sharing toward standardized, automatable APIs rather than manual portal downloads.
Introducing VEX: Telling Customers What Doesn’t Matter
One of the more practical concepts Friedman has helped develop is VEX, the Vulnerability Exploitability eXchange. Where an SBOM tells a customer that a vulnerable component exists somewhere in a product, VEX lets a vendor formally state that a given vulnerability doesn’t actually affect that product. Friedman’s own example: a product might use an old, flawed version of OpenSSL and still be untouched by Heartbleed, if the vulnerable code path is never exercised.
Friedman’s summary: “SBOM turns on the warning light. VEX lets you turn it off.” He expects VEX to become especially important under the CRA, which imposes tight deadlines for vulnerability response, since VEX data allows that response to be automated rather than manually verified case by case.
AI’s Double Impact on Supply Chain Security
Asked how artificial intelligence complicates the picture, Friedman broke the question into two parts: AI systems as products, and AI as a code-writing tool.
On the first, he described emerging work on what some call an “AI-BOM”: extending the ingredient-list concept to cover an AI system’s software and infrastructure, along with information about the data used to train the model. That matters commercially and geopolitically. Friedman pointed to a Chinese model such as DeepSeek as an example where a lack of transparency could create challenges for organizations trying to sell AI-based products into certain U.S. government or regulated environments, and suggested that tracking training-data provenance could help organizations flag intellectual property or bias concerns before they become liabilities.
On the second, AI-generated code, Friedman raised an open question rather than a settled prediction: will AI coding agents continue pulling in third-party dependencies, or increasingly write more self-contained code from scratch? He suggested either path carries risk worth watching. Coding agents draw on patterns and snippets from public codebases when generating “original” code, which raises the question of whether flawed or insecure patterns could work their way into generated code without ever showing up as a formal, trackable dependency. Friedman framed this as a reason SBOM-style transparency will need to keep evolving alongside how software itself is produced, rather than a settled outcome.
The Trouble With CVEs
Pressed on whether the CVE and vulnerability-database ecosystem is broken, Friedman was candid: there’s tension between adding richer, more detailed vulnerability data and keeping the system accessible enough for small vendors and open-source maintainers to participate. He pointed to a technical shift underway as one sign the system is evolving: for open-source components, package URLs (PURLs) are increasingly being used alongside the older Common Platform Enumeration (CPE) identifiers within CVE records, rather than replacing them outright. He also noted a real gap: CVE records traditionally don’t cover malicious packages, which means organizations tracking npm-style supply chain attacks need to pull from separate threat feeds entirely.
No Architecture Solves Trust Alone
Reflecting on incidents like SolarWinds, Codecov, and 3CX, each of which raised its own questions about software supply-chain trust, Friedman invoked Ken Thompson’s 1974 essay “Reflections on Trusting Trust,” arguing there’s no single point in the software supply chain where absolute trust can be established. Automatic updates remain good security policy on balance, he said, because they force vendors to build more disciplined, stable release processes. But that doesn’t remove the need to understand a vendor’s own upstream exposure, a lesson he says the 2024 CrowdStrike outage, which also disrupted Microsoft-based systems for many organizations, reinforced: your own software can be built well and you can still go down because of something it depends on.
What This Means for the Workforce
Closing on a workforce note, Friedman raised a concern less about tooling and more about people: as coding agents take over the work traditionally done by junior developers, the industry risks losing the pipeline of engineers who learn software by debugging it directly, the people who eventually become the senior engineers capable of deep incident response. He expressed skepticism toward claims that AI will eliminate software vulnerabilities within a couple of years, and argued the enduring value of the security profession isn’t self-perpetuation. It’s protecting the infrastructure everyone depends on. Attack surface management, he suggested, is where the field’s next generation of shared tooling and standards work needs to focus.
This article is based on an interview originally aired on the cyberc podcast by EC-Council, hosted by Jay Bavisi, featuring Dr. Allan Friedman.
Listen on:
 |
 |
 |
 |
