Miles Ashworth: You know what I find philosophically offensive about 2020? Not the year in general, though obviously — specifically SolarWinds.
Megan Skiendel: Oh, I've been waiting for this conversation. Tell me.
Miles Ashworth: The attackers went inside the build process. Not around it, not after it — inside it. And the resulting artifact, distributed to thousands of SolarWinds customers, carried a cryptographic signature that was completely valid. The chain passed every check. It's the verification working exactly as it's supposed to, and it still shipped malware.
Megan Skiendel: Because digital signatures authenticate provenance — they tie an artifact to an identity. They don't authenticate the identity's integrity.
Miles Ashworth: Right. And here's what I find almost elegant about it, in a horrible way — software supply chain integrity, the actual property organizations are trying to guarantee, is that what deploys to production is a faithful representation of reviewed source through an authorized build. SolarWinds violated that property completely, and yet a checksum, a signature, an attestation — all of it would have read clean.
Megan Skiendel: Because the attacker was the authorized build. That's — honestly, that's the part that doesn't get said plainly enough.
Miles Ashworth: The CI/CD pipeline is supposed to be the trust boundary. The thing that enforces integrity at every handoff. And SolarWinds demonstrates that a compromised build runner produces a validly signed malicious artifact, which means the trust boundary became the attack surface.
Megan Skiendel: Which most organizations never model as a threat. Their pipeline is a black box — source in, artifact out, signature valid, ship it.
Miles Ashworth: And nobody reads the attestation. The automation handles it, the deploy button gets pressed, and the implicit assumption is that a valid signature means a clean product. Which leads to the only question I actually want to answer today: if cryptographic verification can guarantee a poisoned product, what is it guaranteeing?
Megan Skiendel: That whoever built it had the keys. Full stop.
Miles Ashworth: Right — but 'whoever had the keys' is actually the whole problem dressed up as a solution, isn't it. Because there are three different things organizations think they're buying when they do this, and they keep conflating them.
Megan Skiendel: Walk me through that.
Miles Ashworth: Think of it like — and this is the only analogy I'll use — a package arriving at your door. A tamper-evident seal tells you nobody opened it in transit. A return address label tells you where it claims to be from. A notarized shipping manifest tells you exactly what was packed, by whom, at what warehouse, on what date. You need all three to actually trust what arrived. One of them alone is nearly useless.
Megan Skiendel: And most teams stop at the seal.
Miles Ashworth: Most teams stop at the seal. The SHA-256 checksum — that's your tamper-evident seal. All it proves is the artifact hasn't changed since the digest was computed. Nothing about who computed it. Nothing about what went into it.
Megan Skiendel: And the digital signature is the return address. It ties the artifact to an identity — a key — but only as far as you trust that the key hasn't been stolen or, honestly, that the person holding it wasn't the attacker all along.
Miles Ashworth: Which is SolarWinds, precisely.
Megan Skiendel: So the third layer — build attestation, the provenance record — that's your notarized manifest. It's signed metadata that actually says: this specific source commit, this build system, these inputs, these conditions. The narrative of what happened, not just a stamp that says it happened.
Miles Ashworth: And that's what distinguishes a legitimate binary from one that merely has a valid signature.
Megan Skiendel: SLSA v1.0 — OpenSSF published it April 2023 — basically formalizes this as a four-level model. Level 1 is just: automated build, generate provenance. Level 2 says the consumer has to actually verify that provenance. Level 2 doesn't tell you if the build system itself was clean, though.
Miles Ashworth: Good lord. A maturity framework with a ceiling you can hit and still be compromised.
Megan Skiendel: Which is why Rekor exists — it's the transparency log inside Sigstore. Append-only, publicly verifiable. Every signing event gets recorded, so if a key signs something outside its normal channels, that anomaly is detectable. It's the thing that — actually, no, it doesn't prevent the bad signature, it makes the bad signature visible. That's a meaningfully different promise.
Miles Ashworth: Detectable after the fact. Which means the chain — hash, signature, attestation, transparency log — is complete in theory. And 'complete in theory' is precisely where the next problem lives.
Megan Skiendel: Because somebody has to be watching Rekor. And that somebody is not the automation.
Miles Ashworth: And nobody built a system to watch Rekor the way it needs to be watched — which is the thing that breaks the whole promise cleanly in two. Now, XZ Utils.
Megan Skiendel: Oh, this one's worse.
Miles Ashworth: The attacker didn't steal a key. Didn't compromise a build runner. Spent months — actually months — making legitimate contributions to the XZ Utils repository. Real commits. Real fixes. Building a clean, verifiable identity. By the time the backdoor went in, the signing identity was bulletproof. Because it had been earned.
Megan Skiendel: So Rekor would have logged the signing event perfectly. A valid identity, signing in exactly the way it always had.
Miles Ashworth: Immaculate record. The anomaly was only detectable if someone was actively comparing that signing event against the actual code change. Which is — I mean, that's not a transparency log problem, is it. That's a vigilance problem. And cryptography doesn't scale to vigilance.
Megan Skiendel: It's the same structural fact as SolarWinds, actually. Different entry point — one attacker compromised the build environment directly, one earned their way into being the trusted builder — but the output is identical. Valid signature. Poisoned artifact.
Miles Ashworth: Which is what I mean when I say verification shifts from prevention to containment under these conditions. And containment is — look, it's real, it matters — but it's a much, much weaker promise than what teams think they're buying.
Megan Skiendel: Forensics, basically. You can prove what happened. You can't stop it.
Miles Ashworth: Now contrast that with Codecov. 2021. Build artifact modified after production — after it left the builder's hands. And there, signing directly addresses the problem. The downstream consumer checks the signature, it doesn't match, something happened in transit. That's the control working.
Megan Skiendel: Right — but the part that doesn't fit is that most teams can't cleanly separate which threat they're actually defending against. Codecov is post-build tampering. SolarWinds and XZ Utils are builder compromise. The control that stops one does nothing against the other, and the average engineering org is treating them as the same problem.
Miles Ashworth: Good lord. One attack surface is the transit channel, one is the builder identity itself — genuinely different threat models requiring different controls — and keyless signing via Fulcio actually makes this more interesting. You eliminate the long-lived private key, which is good, but now the Fulcio certificate authority infrastructure is its own attack surface. You've moved the problem.
Megan Skiendel: You've traded one chokepoint for another, and whether that's better depends entirely on how well the CA is defended. Which — honestly, that's a whole separate conversation, and the adoption question underneath all of this is actually the darker part.
Miles Ashworth: Meaning — wait, go on.
Megan Skiendel: Meaning NIST SSDF exists, Sigstore is free, OpenSSF published SLSA v1.0 nearly two years ago — and most organizations still treat the pipeline as a black box. The ceiling on verification is real, but I'd argue we haven't even hit the floor yet. That's the thing we need to actually pull apart.
Miles Ashworth: And not hitting the floor is — well, that's actually the thing, isn't it. Because the tools exist. Sigstore is free. Cosign for artifact signing, Fulcio for keyless certificate issuance, Rekor for the transparency log, Gitsign for commits. OpenSSF built the entire stack and handed it out. The bottleneck is not capability.
Megan Skiendel: It's not. And I've watched this up close — you get a VP mandate, the architects nod, the platform team says 'we can absolutely do this,' and then it hits the individual contributors who ask who pays for it in sprint velocity. That question never gets answered cleanly.
Miles Ashworth: But here's what I'd push on — is the framework proliferation actually the cause of that paralysis, or is it the excuse? Because SLSA, NIST SSDF, Sigstore, SBOMs — that's four overlapping systems, and a small team stares at that and decides it cannot move until they converge.
Megan Skiendel: The excuse. Honestly. Because the organizations that picked one framework — just one — and executed it imperfectly had measurably better outcomes than the ones waiting for industry consensus. That's not a theory, that's what the evidence shows.
Miles Ashworth: Good lord. So the frameworks are cover.
Megan Skiendel: Partial controls are cover too, and that's actually the darker version of this. Checksums without signatures — you've proven the artifact didn't change in transit, you've proven nothing about who built it. Signatures without attestations — you know the key was used, you don't know what the build consumed. Each layer alone creates a false sense that the problem is solved.
Miles Ashworth: Which is the fintech team on a Tuesday morning.
Megan Skiendel: Exactly that scenario. They pull an artifact from the registry — signed, checksummed, attestation looks clean, automation handles the verification check. Deploy button gets pressed. The builder was compromised six weeks ago. The team still doesn't know. Everything read valid because it was valid, technically, from a compromised source.
Miles Ashworth: That's SolarWinds at smaller scale — build-stage compromise, valid output. And Codecov is the other half: post-build tampering, different point of failure entirely. Most teams cannot tell you which one they're actually defended against.
Megan Skiendel: And then Log4j happens — one dependency, suddenly the entire ecosystem is asking 'what is actually in our builds?' That's when SBOMs became urgent. A structured inventory of every component, every library — it complements the cryptographic controls by making the dependency graph visible. You can't sign what you can't see.
Miles Ashworth: You can't see what you never mapped. And nobody mapped it because the pipeline was a black box — source in, artifact out, trust assumed.
Megan Skiendel: Which brings us back to the actual diagnosis. It's not the tooling. Sigstore exists, NIST SSDF is documented, SLSA v1.0 is two years old. The bottleneck is adoption — and I'd argue specifically it's accountability. Nobody wants to own a build failure, so they sign things, check a compliance box, and move on.
Miles Ashworth: Quite. And that's the thing nobody says plainly — cryptographic verification is honest theatre under those conditions. It doesn't prevent compromise. It proves you were compromised. The promise organizations hear is 'we'll catch tampering.' What they're actually buying is 'we'll know who to blame.'
Megan Skiendel: And 'who to blame' is not a security posture. The transparency log, the attestation, the SBOM — none of it fires a single packet back at an attacker. What it does is make the gap visible after the fact. Which means the real question isn't whether to implement these controls. It's whether the organization has the actual capacity to act on what the controls surface.
Miles Ashworth: And I keep turning this over and can't quite land it. If you require policy-enforced verification at deployment — not just 'is the signature valid' but 'did this signature come from the right builder, at the right time, matching the expected identity profile' — does that shift the economics of a builder-compromise attack? Or does it just give you a better report after the building's already on fire?
Megan Skiendel: Honestly, I think it makes the attacker's job more expensive — meaningfully so. Because now they can't just compromise the builder once and walk away. They have to maintain the identity profile, hit the timing windows, match the expected patterns continuously. That's operational overhead. But — and this is what I can't fully dismiss — it doesn't move the needle on prevention. It contains the blast radius. It makes the investigation possible. That's real, but it's not what organizations are telling themselves they bought.
Miles Ashworth: More expensive, not impossible. XZ Utils — the attacker ran that identity for months. That's already expensive by any normal measure, and it still worked.
Megan Skiendel: Which is — yeah, that's the thing I can't resolve. Verification is honest about what it is, if you read the fine print. It proves you were compromised. It doesn't promise you won't be. Most organizations are buying it like it's the second thing when it's only ever been the first.
Miles Ashworth: Quite. I don't think there's a verdict here. Not an honest one.
Megan Skiendel: No. Necessary, foundational, insufficient — that's about as far as it goes. I'll take it.
