DevSecOps and vulnerability management are receiving a crucial upgrade as **GitHub**, a subsidiary of **Microsoft**, rolls out its new package firewall. This feature, presently supporting only **npm** packages, is available in public preview for all **GitHub Enterprise Cloud** customers.  ### How the Package Firewall Works The firewall acts as an install-time policy gate, inspecting both metadata requests and package downloads for indicators of malicious activity. It is strategically positioned between endpoints (such as development machines or internal registries) and upstream package repositories. This architecture is vital for preventing malware attacks that leverage package installations, especially given the increasing reliance on automated dependency installations by **AI** agents and **CI/CD** pipelines. These automated processes can inadvertently pull in malicious packages without explicit user intervention, leading to severe security compromises. Instead of directly accessing public package registries, endpoints will now route their requests through the firewall. The firewall then cross-references package downloads against predefined policy controls, blocking any that fail to meet these security standards. ### Configurable Policy Controls Administrators can configure various policy controls to tailor the firewall's behavior: * **Malware Blocking**: Checks against the **GitHub Advisory Database** for active malware advisories. * **Vulnerability Severity**: Blocks packages based on the severity of known vulnerabilities in the **GitHub Advisory Database**. Defaulting to "Critical only," this can be adjusted to "High or higher," "Medium or higher," or "Any severity." * **Attestation Downgrades**: Compares **SLSA** attestations for requested package versions against earlier versions, blocking downloads if attestations are downgraded. * **Newly-Introduced Install Scripts**: Detects packages that have recently added `preinstall` or `postinstall` hooks, which are often abused for data exfiltration. * **Cooldown Period**: Prevents the installation of package versions newer than a configurable minimum age, ranging from 1 to 365 days (defaulting to 1 day). This can be disabled by setting the value to 0.  For instances where a legitimate package is erroneously blocked, users can submit an exception request for approval by enterprise administrators and security managers. ### Broader Industry Trend: Cooldown Periods This initiative aligns with a growing trend across open-source ecosystems to implement cooldown periods for new package releases. For example, **Rust 1.100**, slated for release on November 12, 2026, will introduce support for a configurable minimum publish age. This feature, defined via the `global-min-publish-age` option in `cargo/config.toml`, will apply a default seven-day waiting period if unspecified, giving security scanners and maintainers time to identify and block malicious releases. Similar cooldowns have been adopted by **npm**, **Python**, **Microsoft Visual Studio Code**, **Ruby**, **Bun**, **pnpm**, and **Yarn**. These waiting periods are crucial for adding friction to attack chains, particularly those involving compromised maintainer accounts. By delaying the immediate availability of a newly published, potentially poisoned package, these measures provide a window for detection and remediation before widespread adoption. As **Socket** noted, while legitimate fixes may also face delays, the primary benefit lies in granting researchers, maintainers, and registries critical time to act. This proactive approach helps prevent malicious code from rapidly propagating through automated dependency updates, significantly strengthening the overall software supply chain security posture.