Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / How Security Teams Are Using Blockchain for Supply Chain Defense
Transcript
- Lucas: So we talk a lot on this show about detecting intrusions after they happen—threat hunting, deception tech, that whole toolkit. But there's a quieter problem that's been keeping CISOs up at night for the last few years, and it's not about stopping a hacker at the perimeter. It's about trusting the stuff you're already running inside your network. Luna: The supply chain problem. One bad package or a compromised firmware update and your entire infrastructure is a ticking bomb. Lucas: Exactly. And the industry response has mostly been more scanning, more signing, more audits. But there's a growing camp that says the real answer is cryptographic verification baked into a blockchain. Not as a crypto hype play—as an immutable record of who built what and when. Luna: I've seen a few vendors pushing this. But isn't it overkill? Why not just use a regular hash and a signing key? Lucas: That's the natural question. And for a long time, that's what the industry did—PGP signatures, SHA-256 checksums, all of it. But the problem is centralized trust. If the signing key gets stolen, or the build server is compromised, the signature is worthless. And we've seen that happen. Remember the Codecov breach in 2021? Attackers modified a bash uploader script, and the tampered version was still being signed by Codecov's own key. Luna: Right. The attacker had access to the signing infrastructure, so the signature itself was lying to everyone. Lucas: That's exactly the vulnerability blockchain addresses. Instead of a single signing key that can be compromised, you anchor the hash of each build artifact into a distributed ledger. Multiple validators—sometimes hundreds—attest to the fact that a specific binary came from a specific source at a specific time. Changing that record retroactively would require controlling a majority of the network, not just one server. Luna: So it's not about replacing hashes. It's about decentralizing the trust anchor for the hash. Lucas: Exactly. And this isn't theoretical. There's a project called Sigstore, which started at the Linux Foundation and has been rolling out in production since 2024. It uses a transparency log—essentially a blockchain-like structure—to record signatures for open source packages. Developers upload their signatures, and the log ensures they're verifiable by anyone, even years later. Luna: Right, I've heard of Sigstore. It's what npm and PyPI have been integrating. But I thought the log wasn't a full blockchain—it's more of a Merkle tree? Lucas: Technically it's a certificate transparency log, same concept Google uses for TLS certificates. It's append-only and cryptographically verifiable, but it's not a full proof of work chain. That said, some enterprise tools are going further. There's a startup called Transparent Supply Chain that runs a private permissioned blockchain specifically for software bill of materials, or SBOMs. They record every dependency hash and build step in an immutable ledger shared between the vendor and the customer. Luna: So the customer can check, 'Is this binary exactly what the vendor claims it is?' without having to trust the vendor's build server. Lucas: Exactly. And here's a concrete example from last year that made the case for this approach. In February 2025, a popular open-source registry—I won't name the specific one, but it's in the top ten—discovered that a maintainer's account had been compromised. The attacker pushed a package update that included a backdoor that exfiltrated environment variables. Luna: I remember that. It was in the news for a week. A lot of downstream users were affected before it was caught. Lucas: What's interesting is that one company that used Sigstore caught it within hours, not weeks. Their CI pipeline checked the signature against the transparency log before deploying. The signature for the malicious package didn't match the log entry for that version—the attacker hadn't been able to forge a valid log record—so the pipeline rejected the update. It was a clean block. Luna: So the blockchain-based verification actually prevented the breach, rather than detecting it after the fact. Lucas: Exactly. And that's the shift. Instead of scanning for malware after the package is already in your environment, you're verifying provenance before you even download it. It's a zero-trust approach to the supply chain. Luna: Okay, but what about hardware supply chains? Software is one thing, but if I'm a CISO at a semiconductor company, I'm worried about counterfeit chips or tampered firmware in the manufacturing process. Can blockchain help there? Lucas: It can, and it already is. There are consortia like the Trusted Computing Group and the Open Compute Project working on blockchain-based part tracking. The idea is that each component—say, a network card or a server motherboard—gets a unique cryptographic identity recorded on a ledger at the factory. Every step: assembly, testing, shipping, receiving—each participant adds a signed entry. Luna: So you can trace the entire lifecycle of a chip from the foundry to your data center rack. Lucas: Exactly. And if a component is replaced during repair, that's recorded too. The ledger becomes an immutable bill of materials for the physical device. One defense contractor I spoke to told me they're piloting this for their F-35 supply chain—not because they think China is going to swap a chip, but because they want to be able to prove the chain of custody in an audit. Luna: That's a strong use case. But I have to ask—what's the catch? Blockchain isn't free. There's latency, storage costs, and the complexity of getting all these different parties to agree on a shared ledger. Lucas: Those are real challenges. For software, the latency isn't a big deal because you're verifying during the build or deploy step, which already takes time. But for hardware, where you might have thousands of parts moving through a supply chain, the throughput of a public blockchain isn't sufficient. That's why most enterprise solutions use permissioned ledgers with fewer validators—higher throughput, lower cost, but less decentralization. Luna: And less trust? If I'm the one running the validators, isn't that back to the single point of failure problem? Lucas: It depends on the governance. If you have a consortium of ten defense contractors and the DoD, each running a node, it's not a single point. But if it's just one vendor controlling all the validators, you're right—it's just a fancy database. The value comes from diverse, independent validators. Luna: So the key is the number of independent entities that can attest to the data. Lucas: Exactly. And that's where the industry is still maturing. We're seeing more standards emerge—like the CycloneDX SBOM format, which now supports blockchain-based provenance fields. And the US Cybersecurity and Infrastructure Security Agency, CISA, has been pushing for software attestation standards that include distributed ledger references. Luna: You know, this reminds me of something we talked about a few episodes ago—the shift from perimeter defense to identity-based security. This feels like the same mindset applied to the software supply chain: don't trust the source, verify everything at the artifact level. Lucas: That's a great connection. It's zero-trust for builds. And it's not just about preventing attacks—it's about creating a forensic record that can be used after an incident. If you have an immutable log of every software component that ever entered your environment, you can answer questions like, 'Was this vulnerable library ever deployed to production?' within minutes, not weeks. Luna: That's a huge improvement over the current state, where most organizations don't even have a complete software inventory. Lucas: Right. And blockchain-based provenance gives you that inventory automatically. Every time you build or deploy, you're recording what you used. It's self-documenting. Luna: Okay, but let me play devil's advocate. A blockchain log only helps if the initial attestation is honest. If the attacker compromises the build process before the attestation is made—say, they insert a backdoor into the source code and then the legitimate build process signs the tampered binary—the blockchain record would say 'this binary is valid' when it's not. Lucas: That's a fair point, and it's a real limitation. Blockchain doesn't solve the problem of a compromised source. What it does is ensure that if the source is compromised, you can trace exactly which version of the source produced which binary. And if you also record code reviews and commit hashes on the ledger, you can pinpoint where the injection happened. It's not a silver bullet, but it raises the bar significantly. Luna: So it's more about integrity and accountability than about preventing every possible attack. Lucas: Exactly. And that's actually a good framing for where the industry is heading. We're moving away from the idea that any single tool can stop all attacks, and toward a model where we have multiple layers of verification. Blockchain-based provenance is one of those layers—and it's a layer that's becoming practical thanks to lower-cost ledgers like permissioned chains and more efficient consensus algorithms. Luna: I'd love to see some real numbers on adoption. Are CISOs actually buying this? Lucas: The data is still early, but there are signals. A 2025 survey from the SANS Institute found that 23 percent of organizations are already using some form of distributed ledger for software supply chain verification, and another 38 percent are piloting or evaluating. That's up from single digits two years ago. And the drivers are clear: the SolarWinds-style attacks haven't stopped, and regulators are paying attention. Luna: That's a pretty quick uptake for a technology that's often dismissed as overhyped. Lucas: I think the hype around blockchain for finance overshadowed real engineering use cases. But when you strip away the crypto speculation, what you're left with is a very practical tool for establishing trust in distributed systems. And supply chains are inherently distributed. Luna: And these conversations about rebuilding trust in complex systems—whether it's software supply chains or the broader tech ecosystem—they're exactly why we do this show. If you find these deep dives useful for what you're building or running, we hope you'll consider supporting the podcast. It keeps the show independent and ad-free. You can do that at buy me a coffee dot com slash fexingo. Just a simple way to say this content matters to you. Lucas: Totally. And to loop back—because we're seeing exactly that shift in how security teams think about trust. The old model was 'trust the vendor, verify if you have time.' Blockchain flips that to 'verify everything, trust the ledger.' Luna: It's a cultural change as much as a technical one. Lucas: Absolutely. And the technical pieces are falling into place. Tools like Sigstore are already integrated into major package managers. The next step is making this seamless in CI/CD pipelines—so that every build automatically generates a verifiable provenance record without developers having to think about it. Luna: Are there any major players pushing for standardization? Lucas: Yes, the Linux Foundation's Open Source Security Foundation, OpenSSF, has a working group on supply chain integrity that's been drafting a specification called 'SLSA'—Supply-chain Levels for Software Artifacts. It defines levels of attestation, and blockchain-based provenance is part of the highest levels. Google, Microsoft, and AWS are all contributing. Luna: So we might see this become a requirement for government contracts, like FedRAMP or DoD's Cybersecurity Maturity Model Certification. Lucas: That's the direction. CISA has already released guidance recommending software attestation, and the White House executive order on cybersecurity from 2021 explicitly called for supply chain integrity measures. Blockchain-based provenance is a natural fit for meeting those requirements. Luna: I'm curious if there are any downsides beyond the cost and complexity we already touched on. Lucas: One concern is privacy. If you're recording every dependency and build step on a shared ledger, you're potentially exposing intellectual property—what libraries you use, how your build process works. Permissioned blockchains with encrypted entries can mitigate that, but it adds complexity. Another issue is key management: if the private key used to attest is lost, you lose the ability to prove provenance for past builds. That's a recovery problem that still needs solving. Luna: So there's still engineering work to do before it's plug and play. Lucas: For sure. But the foundation is solid. And given the pace of attacks—the number of supply chain compromises has been rising year over year—I think we'll see blockchain-based verification become standard practice within three to five years, similar to how two-factor authentication went from niche to default. Luna: It feels like one of those rare cases where a technology's theoretical promise actually aligns with a real-world pain point. Lucas: Exactly. And that's the story that matters, not the token price. Luna: Well, thanks for walking through this. I think listeners have a much clearer picture of where supply chain defense is heading. Lucas: Glad to do it. Next episode, we'll look at another emerging technique—how security teams are using confidential computing to protect data in use. That should be a good one.