Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / Why CISOs Are Betting on Supply Chain Security
Transcript
- Lucas: If the conversations we have on this show are useful for what you're building or running — if they help you think clearer about a security investment or a vendor risk — that's exactly why we do it. And the way we keep these episodes ad-free, no sponsorships, no mid-roll interruptions, is listener support. If today benefited you, toss a coffee our way at buy me a coffee dot com slash fexingo. All lowercase, one word, no spaces. It genuinely helps us stay independent. Luna: Yeah, and it's pretty low lift — just a one-time thing or a small monthly. We appreciate anyone who helps out. Lucas: Alright, back to the supply chain question — because even after SBOMs, the real work is figuring out what to do with them. Lucas: So, Luna, I want to start with a number that hit me this week. A Gartner survey from last quarter found that sixty percent of enterprises now require a software bill of materials — an SBOM — from every new vendor. That's up from maybe fifteen percent three years ago. Luna: That is a huge jump. And I remember when SolarWinds was the catalyst — but it took a while for procurement teams to actually enforce it. Lucas: Right. The SolarWinds breach was 2020. The Biden executive order came in 2021, mandating SBOMs for all federal software. But it's taken until 2025, 2026 for that to really cascade into the private sector. Luna: And what exactly is in an SBOM — is it like a ingredients list for software? Lucas: Exactly that. It lists every open-source library, every third-party component, every dependency, including version numbers and the supply chain relationships between them. So when a vulnerability like Log4j drops, you can instantly check your SBOMs to see if any of your vendors are using that affected version. Luna: Okay, so it's an inventory. But I've heard CISOs say that just getting the SBOM is step one — the hard part is actually analyzing it. Lucas: That's the real bottleneck. A typical enterprise might have hundreds of vendors. Each vendor's SBOM can list thousands of components. Multiply that, and you're drowning in data. Most security teams don't have tools that can automatically cross-reference those SBOMs against vulnerability databases. Luna: So what are the practical moves? I know some companies, like Microsoft and Google, have started publishing their own SBOMs publicly. Is that becoming a best practice? Lucas: It is for big tech. Microsoft publishes SBOMs for Windows and some Azure services. Google does for Chrome and Android. It's partly transparency, partly pressure on the rest of the industry to follow. But for a smaller SaaS vendor with a hundred developers, generating an accurate SBOM is non-trivial. Luna: Especially if they have legacy code that wasn't built with dependency tracking. I've seen cases where teams are manually reconstructing their component lists. Lucas: Yeah, and that manual process is error-prone. There are automated tools — software composition analysis tools — that can generate SBOMs from your codebase. But they only work if you have clean build pipelines. A lot of companies don't. Luna: So for a CISO evaluating a new vendor, how do they actually verify an SBOM? I mean, the vendor could just fudge the list. Lucas: That's a real concern. There's no central registry that validates SBOMs. What some enterprises do is require the vendor to use a specific format — SPDX or CycloneDX — and then they run a third-party analysis tool to compare the SBOM against the actual binaries. But that's still rare. Luna: And attackers are adapting. We've seen an uptick in supply chain attacks targeting package managers — like dependency confusion attacks on npm and PyPI. Lucas: Exactly. The number of malicious packages published to npm doubled in 2025 compared to 2024. Attackers know that if they can get a malicious component into a popular library, it spreads to every downstream product that uses it. Luna: And that's where SBOMs can help — if you have the list, you can at least check if any of your dependencies are known to be compromised. Lucas: Right. But the window between a package being compromised and that compromise being discovered can be weeks. So SBOMs are a necessary condition for supply chain security, but not sufficient. Luna: What about the role of the government? The executive order was a big push, but is there any new regulation on the horizon? Lucas: The FDA now requires SBOMs for medical devices. The SEC's cybersecurity disclosure rules indirectly push companies to know their supply chain. And there's talk of a federal SBOM repository — like a clearinghouse — but it's still in the proposal stage. Luna: So for a startup or a mid-market company listening, what's the one thing they should do this quarter? Lucas: Start generating SBOMs now, even if no customer has asked yet. Because by the time they ask, you don't want to scramble. Use an open-source tool like Syft or Tern to generate a CycloneDX SBOM from your container images. Then run a vulnerability scanner against it. That's the minimum viable practice. Luna: And for the buyers — the enterprises — what's the ask? Lucas: Demand SBOMs in your procurement contract, but also invest in the tools to actually use them. Otherwise you're just collecting paper. I know a couple of Fortune 500 CISOs who have built internal teams just to analyze vendor SBOMs. Luna: That's a whole new category of security operations. Supply chain analyst as a role. Lucas: It is. And I think we'll see that become standard within five years — just like we now have cloud security architects and incident responders. Luna: Alright, so to sum up: SBOMs are becoming table stakes, but the real work is in analysis and automation. Lucas: Exactly. And the attackers aren't waiting. So the question for every security leader is: do you know what's in your software? Luna: Good place to leave it. Thanks Lucas.