# Update Signatures Prove Provenance Not Freshness ## Claim A software-update signature proves who authorized an artifact, not whether that artifact is the newest safe version. <!-- atomicity: 1 idea ✓ --> ## Evidence > [!quote] > "The software remembers the highest version it's ever verified and installed, and refuses to accept anything older than that." The version ratchet exists because an old vulnerable release can retain a perfectly valid signature; provenance checks need monotonic version memory to reject replay. ## Scope & conditions - **Holds** when old signed releases remain downloadable or can be replayed by a compromised update channel. - **Strongest** for unattended updates where the site owner never compares release history manually. - **Weaker** when signed metadata expires quickly or a trusted service enforces freshness outside the client. ## Links - [[3. Resources/Permanent Notes/Supply-Chain Defense Tracks Bad Actors Not Bad Code]] — signatures bind an artifact to an authorized build identity while actor tracking watches changes around that identity - [[3. Resources/Permanent Notes/Zet · Rapid weaponization outpaces manual update workflows]] — a version ratchet keeps an attacker from reopening a vulnerability after maintainers have already paid the cost to patch it - [[WordPress Hosting Security Stack MOC]] — home for WordPress update trust, supply-chain defense, and patch deployment ## Source - [[3. Resources/Readwise/Articles/How Signed Updates Work - PattonWebz]] — William Patton, 2026; signed update keys, public transparency logs, client verification, and downgrade resistance.