4 ms·
Yes. Solarwinds. Code checked out from the repository was not the same that was used to build the actual release. These are not high-likelyhood incidents but w
by bostik 2y ago
Yes. Solarwinds.
Code checked out from the repository was not the same that was used to build the actual release. These are not high-likelyhood incidents but when they do occur, they tend to have high impact.
And more recently, semantically similar code-vs-build mismatch: CrowdStrike. The broken release was modified after the actual build step, as per their own build process, and the modified artifact is what was released.
- irundebian 2y agoTo which CrowdStrike incident are you refering to? The global impact CrowdStrike incident was caused due to a driver defect which wasn't caught by quality assurance processes. It had nothing to do with malicious actors which were interfering with the code repository or the software deploment process.
- bostik 2y agoThe same incident, because the root causes are even more messed up than just shoddy QA. Yes, the thing wasn't caught because of missing QA. What I find even worse is that the build process for their "channel files" involved: * building a release in CI, for which tests were run * modifying the built artifact as a post-process step, and * uploading this modified end result into their CDN infrastructure In effect, what they actually built from their sources in the CI pipeline was not what was delivered to end users. You are correct in that attestations wouldn't help against such flagrant lies. And it wasn't a malicious act (although maliciously incompetent might qualify). That post-build modification step would fly in the face of the attestation concept. It wouldn't help against having an empty set of tests, but an attestation-friendly build process at least would discourage messing around with the artifacts prior to release.