# A Release Policy Should Separate Code-Integrity Risk From Patch-Delivery Urgency ## Claim A distribution gate built to catch malicious releases and a fast lane for already-disclosed vulnerability fixes are solving different problems, so routing both through one review clock optimizes neither. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when the release population contains both classes — code whose integrity is unverified, and code that's a legitimate maintainer's fix for a publicly known flaw — and both must currently pass through the same gate. - Breaks when the two classes can't be reliably distinguished at intake (a false "security fix" label would create exactly the bypass the differentiated path is trying to avoid), so a fast lane is only safe once identity and disclosure verification are solid. - Reported concretely by Patchstack: across the sample it tracked, CVE-associated releases showed similar gate durations to routine, non-security releases. ## Evidence > [!quote] > Malicious releases and disclosed vulnerabilities are different problems. Protect The Shire treats them identically. The underlying logic: a hold is genuinely useful against threat model one (a compromised account or supply-chain injection, where time buys detection) and genuinely costly against threat model two (a legitimate fix for a known bug, where time only extends exposure). Treating them the same optimizes for the wrong average. ## Links - [[3. Resources/Literature Notes/Protect the Shire Solves One Problem, but Risks Making Another Worse]] — source literature note, §H2 - [[3. Resources/Permanent Notes/Supply-Chain Defense Tracks Bad Actors Not Bad Code]] — because extends: that note's actor-vs-code distinction is the same move one layer up — different threat models need different defensive machinery, not one blanket control - [[3. Resources/Permanent Notes/A Single Discretionary Update Channel Is a Security Dependency]] — because applies-in: whichever channel eventually carries the fast lane inherits the same governance-is-part-of-security requirement - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — applies-in: repository release-gate design ## Tests / falsifiers - A transparent, reproducible release-latency study (build identity, timestamps, exclusions published) that finds CVE-associated releases already move measurably faster than routine ones — would weaken the claim that today's gate is undifferentiated. - A trial fast-path that gets exploited via false security-classification within its first measured window — would show the differentiation itself needs stronger identity/disclosure verification before it's safe to ship. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/Protect the Shire Solves One Problem, but Risks Making Another Worse - Patchstack]] — reports gate-duration parity between routine and CVE-associated releases.