That doc is very useful and confidence inspiring in terms of being mainly about people and process, rather than about one single technical solution.

Relevant parts for those who have cool-downs at the top of mind:

> Across Homebrew’s history far more users have been protected by shipping zero-day fixes quickly than have been exposed to npm-style token-theft or crypto-mining attacks, so a global cooldown would be a net negative for most users’ security. The deeper reason Homebrew does not need a general cooldown is that, unlike language package managers, it already separates publishing from distribution: an upstream release does not reach users until it has passed human review, CI and checksum verification, which is the very review window that language-ecosystem cooldowns are trying to recreate.

[...]

> For ecosystems with a track record of fast-moving supply-side attacks, Homebrew applies a download cooldown: a freshly-published upstream version is not adopted immediately, giving the wider community time to detect and report a malicious release before Homebrew users are exposed. Cooldowns have been added for:

    Bundler
    RubyGems livecheck
    npm and pip defaults
    PyPI resource resolution
    npm and PyPI in bump