Technisch sitzt die Firewall zwischen Endpunkten oder internen Registries und den vorgelagerten Paket-Repositories. Statt direkt auf die öffentlichen Registries zu zeigen, sollen Endpunkte wie Coding-Agenten und CI/CD-Hosts ihre Anfragen über die Firewall leiten. Diese gleicht Downloads mit Richtlinien wie einem Mindestalter der Pakete und Malware-Advisories ab und blockiert alles, was den Vorgaben nicht entspricht. GitHub verweist darauf, dass besonders dann Risiken entstehen, wenn KI-Agenten und CI-Runner Abhängigkeiten automatisch und ohne ausdrückliche Zustimmung installieren, um eine Aufgabe oder einen Build abzuschließen.

Administratoren müssen dafür Richtlinien konfigurieren. Vorgesehen sind unter anderem:

  • Blockieren bekannter Schadsoftware durch Abgleich mit der GitHub Advisory Database auf aktive Malware-Advisories.
  • Blockieren anhand des Schweregrads von Schwachstellen, die laut GitHub Advisory Database die angeforderte Paketversion betreffen. Voreingestellt ist „nur kritisch"; wählbar sind außerdem „hoch oder höher", „mittel oder höher" und „jeder Schweregrad".
  • Blockieren von Attestierungs-Downgrades: Die Attestierungen der angeforderten Version werden mit denen früherer Versionen verglichen; fehlt der angeforderten Version eine SLSA-Attestierung, wird der Download gestoppt.
  • Blockieren neu hinzugefügter Installationsskripte, also kürzlich ergänzter preinstall- oder postinstall-Hooks, die zum Abgreifen sensibler Daten missbraucht werden können.
  • Blockieren über eine Abkühlphase, die Versionen unterhalb eines konfigurierten Mindestalters ausschließt. Der Wert reicht von 1 bis 365 Tagen, Standard ist 1 Tag; mit 0 lässt sich die Regel abschalten.

Wird ein Paket irrtümlich blockiert, können Nutzer eine Ausnahme beantragen, die von Enterprise-Administratoren und Security-Managern genehmigt werden kann.

Parallel bereitet auch das Rust-Ökosystem eine vergleichbare Schutzmaßnahme vor: Rust 1.100, dessen Veröffentlichung für den 12. November 2026 geplant ist, soll ein konfigurierbares Mindest-Veröffentlichungsalter unterstützen. Sicherheitsscanner und Maintainer erhalten damit Zeit, schädliche Crate-Releases zu kennzeichnen und zu blockieren, bevor sie installiert oder genutzt werden. Festgelegt wird der Wert über die Option „global-min-publish-age" in „cargo/config.toml", angegeben in Tagen oder Wochen. Ohne eigene Angabe gilt eine Wartezeit von sieben Tagen, in der neu veröffentlichte Releases übersprungen werden.

Im vergangenen Jahr haben zahlreiche Open-Source-Ökosysteme ähnliche Wartezeiten eingeführt, darunter npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm und Yarn. Ziel ist es, die Sicherheit der Software-Lieferkette zu erhöhen, indem neu veröffentlichte, ungeprüfte Versionen nicht unmittelbar in Builds gezogen werden. Solche Abkühlphasen bremsen insbesondere Angriffe, bei denen Täter nach der Übernahme eines Maintainer-Kontos eine vergiftete Version eines populären Pakets veröffentlichen und diese sich über manuelle oder automatisierte Installationen rasch verbreiten würde.

Socket wies zugleich auf die Grenzen des Ansatzes hin: „Der Nachteil ist, dass auch legitime Fehlerbehebungen warten müssen, sofern Entwickler keine Ausnahme machen." Schadcode werde mit zunehmendem Alter nicht harmlos: „Ein Release, das der Erkennung entgeht, kann die Abkühlphase schlicht überdauern. Der Wert liegt darin, Forschern, Maintainern und Registries Zeit zu verschaffen, um zu handeln, bevor das nächste Abhängigkeits-Update einen Angriff weiterträgt."