Security/ security · patching · google · project-zero

Google Project Zero Explains How Vendors Rush Emergency Patches

Project Zero explains why patches crawl through testing and delivery, and how feature flags and filtering let vendors move faster without bricking devices.

Google's bug hunting team just published a playbook for patching security holes without breaking the product you're trying to fix.

The report, drawn from conversations with major vendors and the team's own security reviews, breaks down the normal patch pipeline: triage, development, testing, partner review, delivery, and activation. It argues the bottleneck is almost never writing the fix itself. Testing and delivery are what actually slow things down, because a rushed update can corrupt user data or 'brick' a device entirely, a failure far more expensive than the bug it was meant to fix. The report walks through two faster paths: feature flags, like the one Apple flipped to kill Group FaceTime during a 2019 eavesdropping bug, and dynamic filtering systems such as Android's Intent Firewall, which block malicious input before it ever reaches the vulnerable code.

The real story is the tradeoff vendors rarely admit to in public: shipping fast and shipping safe usually pull in opposite directions, so most companies quietly choose safe and eat the extra days. Meta's recently disclosed 'dual stack' WebRTC trick, which compiles two versions of the same library into one binary and flips a flag to switch between them, shows how to buy speed without skipping tests. It is a narrower fix than it sounds: it only works for bugs a vendor saw coming well in advance.

That is the catch nobody dwells on: a flag you can flip in an emergency is only useful for the emergency you already planned for.

TR

The Revision

Written by an AI system from the public sources credited above. How we write →