Bringing trust to your CI System
How would you even know if your build pipeline was compromised — not your code, the system that builds it?
That question is basically what pulled me down a rabbit hole last weekend. I was just going back to basics, re-reading the fundamentals of secure software delivery, and somehow landed right back on the one question that always pops up eventually: how much does anyone actually trust CI?
Because if someone quietly got a foothold in a build system, the artifact that comes out the other end still looks completely legitimate. Nothing downstream catches it, because most pipelines are built to just trust the artifact by default. That's the same pattern behind incidents like SolarWinds and Codecov — not application bugs, trust failures in the delivery path itself.
So I went down the rabbit hole properly — the current SLSA framework, provenance, in-toto attestations, the whole "how do you actually prove what happened during a build" question. Turns out the industry's answer is pretty elegant: provenance is a verifiable record of what happened during the build. Attestation is how that record gets proven, cryptographically, at every step after.
A few late nights later, my notes turned into something worth keeping — a handbook I know I'll come back to, more than once. The whole thing distills into one line I keep coming back to:
Git → Build → Artifact → Deploy → Runtime — identity, evidence, and independent verification at every boundary.
If you operate any part of a software delivery path to production, ask yourself that question today.
Read the handbook at https://securesoftwaredelivery.wckd14.xyz/
\#PlatformEngineering #SupplyChainSecurity #SLSA #SSDLC #DevSecOps
https://redd.it/1v7cj9j
@r_devops
How would you even know if your build pipeline was compromised — not your code, the system that builds it?
That question is basically what pulled me down a rabbit hole last weekend. I was just going back to basics, re-reading the fundamentals of secure software delivery, and somehow landed right back on the one question that always pops up eventually: how much does anyone actually trust CI?
Because if someone quietly got a foothold in a build system, the artifact that comes out the other end still looks completely legitimate. Nothing downstream catches it, because most pipelines are built to just trust the artifact by default. That's the same pattern behind incidents like SolarWinds and Codecov — not application bugs, trust failures in the delivery path itself.
So I went down the rabbit hole properly — the current SLSA framework, provenance, in-toto attestations, the whole "how do you actually prove what happened during a build" question. Turns out the industry's answer is pretty elegant: provenance is a verifiable record of what happened during the build. Attestation is how that record gets proven, cryptographically, at every step after.
A few late nights later, my notes turned into something worth keeping — a handbook I know I'll come back to, more than once. The whole thing distills into one line I keep coming back to:
Git → Build → Artifact → Deploy → Runtime — identity, evidence, and independent verification at every boundary.
If you operate any part of a software delivery path to production, ask yourself that question today.
Read the handbook at https://securesoftwaredelivery.wckd14.xyz/
\#PlatformEngineering #SupplyChainSecurity #SLSA #SSDLC #DevSecOps
https://redd.it/1v7cj9j
@r_devops
Secure Software Delivery Architecture
A Platform Engineer's Guide to Trust, Identity, and Software Supply Chains — from Git commit to running workload.