Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / Why Supply Chain Attacks Keep Getting Worse
Transcript
- Lucas: If you're running enterprise security and you've locked down every front door, attackers have figured out they can just walk in through a vendor you trust. Luna: Supply chain attacks. And they're accelerating. Lucas: Yeah, and not just SolarWinds — that was the wake-up call in 2020. But the follow-through has been slow. We're looking at data from 2025 now, and the trend line is still steep. Luna: Before we dive into the numbers, Lucas — quick honest thing. A handful of our listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making these episodes. So if this kind of deep dive is useful for what you're building or running, that's where it comes from. Lucas: Yeah, and we keep it ad-free because of that. Appreciate everyone who does. Luna: All right — so supply chain attacks. Let's start with what actually changed after SolarWinds. Lucas: Right. SolarWinds was a watershed because it showed that a single compromised update could hit thousands of organizations simultaneously — including government agencies. But here's the thing: five years later, we're still seeing the same basic pattern. The MOVEit breach in 2025 was essentially the same playbook — attackers compromised a file-transfer tool and then piggybacked into hundreds of downstream victims. Luna: And MOVEit actually had a higher victim count than SolarWinds, right? I think it was something like two thousand organizations. Lucas: Closer to twenty-five hundred. And the reason this keeps working is structural. Modern software is built on a mountain of third-party dependencies. The average enterprise application pulls in something like five hundred open-source libraries. If any one of those is compromised, you're exposed. Luna: So the attack surface is massive. But what's the actual economic incentive for attackers? Why not just target the big companies directly? Lucas: Because targeting a single vendor gives you leverage over hundreds or thousands of customers at once. It's return on investment. You write one piece of malware, compromise one update pipeline, and you get access to every organization that uses that software. The cost per victim is tiny. Luna: And the defenders are still playing catch-up. Most security teams focus on their own perimeter. They don't audit their vendors' software development lifecycle. Lucas: That's exactly the gap. Let me give you a concrete example. In early 2026, a vulnerability was found in a widely used logging library called Log4j — actually, that was 2021, but the echoes are still being felt. The fix was deployed, but because the library is embedded in thousands of products, many organizations didn't even know they were running it. The patching cycle took years. Luna: So the problem isn't just detection — it's visibility. You can't patch what you don't know you have. Lucas: Exactly. And that's led to a push for software bills of materials — SBOMs. The idea is that every software vendor should provide a manifest of all the components in their product. Then the customer can cross-reference that against vulnerability databases. Luna: But adoption has been slow. What's the holdup? Lucas: Multiple things. First, generating an accurate SBOM is technically hard — especially for legacy code. Second, there's no standardized format that's widely enforced. And third, even if you get the SBOM, you now have a data management problem. A large enterprise might have tens of thousands of software assets. Cross-referencing that against millions of known vulnerabilities is a massive effort. Luna: So the solution might be more automation. But that also creates new risks — you're trusting the tool that generates the SBOM. Lucas: Right. And that's the circular nature of supply chain security. Google has been pushing something called SLSA — Supply-chain Levels for Software Artifacts. It's a framework that defines security levels for build and deployment pipelines, kind of like a maturity model. Luna: How widely adopted is SLSA? Lucas: Not very, yet. As of mid-2026, it's mostly used by large cloud-native organizations. The barrier is that achieving SLSA Level 3 or 4 requires a pretty sophisticated CI/CD infrastructure — reproducible builds, signed provenance, tamper-proof audit logs. For a small SaaS vendor, that's a significant investment. Luna: And the market doesn't always reward that investment. Customers don't ask for SLSA certification; they ask for SOC 2 reports and maybe a penetration test. Lucas: That's changing, but slowly. The SEC's new breach disclosure rules that took effect in 2024 have started shifting behavior. Now publicly traded companies have to disclose material cyber incidents within four business days. That creates a stronger incentive to know your supply chain. Luna: Has that led to actual changes in vendor management? Lucas: Preliminary data suggests yes. A survey from early 2026 found that 62% of large enterprises now require their critical vendors to provide SBOMs — up from 28% two years earlier. But enforcement is still weak. Most respondents said they don't have the tools to verify the SBOM's accuracy. Luna: So the SEC rule is a nudge, not a silver bullet. What about cyber insurance? I know in a previous episode we talked about insurers driving security improvements. Lucas: Insurers are definitely paying attention. Some are now requiring supply chain security questionnaires as part of underwriting. But the challenge is that the data isn't mature enough to price risk accurately. A company might have a great security posture internally but a weak third-party vendor that exposes them. The insurer can't easily model that. Luna: So the entire ecosystem is still figuring out how to quantify and manage this risk. Lucas: Yes. And one of the more interesting developments is the rise of vendor security rating platforms — companies like BitSight and SecurityScorecard. They continuously monitor the external security posture of thousands of organizations by scanning public data. So a customer can get a real-time score on a vendor's security hygiene. Luna: But those scores are based on observable data — like unpatched services, open ports, certificate issues. They don't capture the security of the vendor's software development process itself. Lucas: That's the blind spot. A vendor could have a perfect external rating but still push out compromised updates. That's exactly what happened with SolarWinds — their external posture looked fine. Luna: So we need deeper visibility. Some companies are starting to demand access to vendors' build logs or even run-time monitoring of vendor software in sandboxed environments. Lucas: And that's moving toward a zero-trust model for software supply chains. The idea is: don't trust any software component just because it came from a legitimate vendor. Verify its integrity at every stage — from development to deployment. Luna: Which is a massive operational shift. Most organizations can barely manage their own code, let alone verify every dependency. Lucas: Right. So the pragmatic approach has been to focus on critical vendors first — the ones that have broad access to your network or sensitive data. For those, you might require a signed provenance attestation for every release. Luna: And what about open source? The Log4j example showed that even the most widely used components can have devastating vulnerabilities. Who's responsible for securing the open source ecosystem? Lucas: That's a huge question. A lot of critical open source projects are maintained by volunteers or very small teams. The Linux Foundation and others have tried to fund security audits, but it's a drop in the bucket. In 2025, the White House released a report recommending that companies using open source contribute back — either financially or with engineering time. Luna: Is that happening? At scale? Lucas: Slowly. Some large tech companies have dedicated open source security teams. Google, Microsoft, and Amazon all contribute to projects like oss fuzz, which does automated vulnerability discovery. But for the thousands of smaller libraries that get pulled into enterprise apps, there's still very little oversight. Luna: So what's the one thing you'd tell a security leader listening right now? Lucas: Start by mapping your critical software supply chain. Know which vendors have the most access to your environment, and ask them for an SBOM and a signed build attestation. If they can't provide it, that's a risk you need to explicitly accept or mitigate. Then, for open source dependencies, use automated tooling to track known vulnerabilities and prioritize patching based on actual exploitability — not just CVSS score. Luna: CVSS — the Common Vulnerability Scoring System — is flawed because it doesn't measure context. A library might have a high score but not be reachable in your application. Lucas: Exactly. So the trend is toward risk-based vulnerability management. Tools that understand your code's data flow and can tell you if a vulnerable function is actually called at runtime. That's where the industry is heading. Luna: And regulation is likely to push further. The SEC rules are just the beginning. We're seeing similar proposals in Europe and Asia. Lucas: Yeah, the EU's Cyber Resilience Act, which came into force in 2025, requires manufacturers of connected devices to ensure security throughout the product lifecycle — including software updates. That's going to force more transparency in supply chains globally. Luna: So the direction is clear — more mandates, more visibility, more verification. But the gap between intent and execution is still wide. Lucas: It is. And that gap is exactly where attackers are operating. Until the cost of a supply chain attack exceeds the cost of prevention for the entire ecosystem, we're going to keep seeing these breaches. Luna: Which is a sobering thought. But also a reminder that security is never finished — it's an ongoing process. Lucas: Yeah. And the process is getting more sophisticated. The question is whether it's getting sophisticated fast enough.