GitHub Ships an Actions Network Firewall in Technical Preview, Consolidates Months of npm and Actions Supply Chain Hardening

Overview

GitHub has put an Actions network firewall into technical preview and used a July 28 blog post to round up a string of default-behavior changes it has shipped across npm and GitHub Actions since February to disrupt supply-chain attacks, according to The GitHub Blog. The post, written by Greg Ose, principal product security engineer, and Zachary Steindler, principal software engineer at GitHub, frames the recent work as part of a pattern the company has tracked for the past year: attacks that “target weaknesses in package repositories and CI/CD systems to quickly spread malware to hundreds of open source projects,” seeking to exfiltrate credentials for both further spread and later exploitation.

InfoQ noted in its August 8 coverage that the post itself broke no new ground — “nothing in the post is new, since every item already landed through the changelog” — but that it clarified how many of the changes altered defaults rather than simply adding options. The article also reported that reaction on Hacker News split sharply over whether time-delay defenses are the right tool at all, a debate that ran alongside coverage of the announcement itself.

What We Know

GitHub structured its post around the stages of a typical supply-chain attack: initial compromise, credential exfiltration, propagation, and response. “There is no single security capability that can stop them,” the company wrote, arguing instead for “a holistic approach, prioritizing the mitigations that break the most impactful links in the attack chain,” per The GitHub Blog.

The newest and least mature control is the Actions network firewall, which GitHub says is “in technical preview.” According to The GitHub Blog, “this technical preview logs all outbound network traffic from your Action workflow runs so you can detect unusual behavior like pulling down malicious code or exfiltrating credentials to a new domain.” For now it only observes: “Future work will enable network egress restrictions and policies to block these attacks before they lead to further escalation and exfiltration.”

For initial compromise, GitHub said high-impact npm accounts are now placed into a 72-hour read-only mode whenever they change their email address or use a two-factor recovery code, a change it dated to June 2026 and designed to give maintainers time to recover a targeted account. On the Actions side, the default behavior of actions/checkout changed the same month to stop workflows from checking out untrusted code from forks in commonly exploited triggers — the pattern GitHub calls “pwn requests” — unless a team explicitly opts out; the change was also backported to older releases. June 2026 also brought workflow execution policies letting administrators govern who can trigger workflows and which trigger types are permitted, plus a read-only Actions cache for untrusted triggers meant to stop attackers from poisoning cache entries shared with more privileged workflows.

On credential exfiltration, GitHub called removing long-lived credentials from CI/CD pipelines “the number one thing you can do to disrupt these attacks,” and said npm trusted publishing added CircleCI as a supported provider in April 2026. Propagation defenses include npm staged publishing, which launched in May 2026 as an opt-in control holding new package versions until a maintainer completes an additional approval and 2FA step, and the breaking changes in npm v12 that disable install scripts and git- or remote-URL-based dependencies by default — a change Machine Herald previously reported when npm v12 itself shipped. The post also folds in the three-day Dependabot version-update cooldown that took effect in July 2026, which Machine Herald covered at the time. On the response side, GitHub pointed to self-service credential revocation tooling shipped in June 2026, building on enterprise-wide credential management tools released in February, and to an expansion of its credential revocation API in March 2026 to cover OAuth and App tokens in addition to the personal access tokens it originally supported starting in April 2025.

Community Reaction

InfoQ reported that Hacker News commenters focused less on any individual control than on whether delay-based mechanisms are the right approach at all. On the 72-hour account freeze, commenter datakan argued the window was miscalibrated: “There is a big difference between 3 days when someone may be sick or traveling and not looking and 30, which aligns better with 99% of scenarios this may be an issue with. 3 days is absurd. Even password apps with kill switches will default to 7 days.”

A sharper challenge came from commenter lrvick, who according to InfoQ described buying the expired email domain of a sole npm package maintainer for eight dollars, putting the ability to ship code to roughly 70,000 companies within reach of a simple password reset, and concluded: “72 hours would not make a difference here.” InfoQ reported that lrvick extended the point into a broader critique that the industry keeps building process gates while declining to adopt author-side package signing of the kind Linux distributions have used since the 1990s, and that npm has rejected proposals to implement it, even optionally, for a decade.

Commenter acdha pushed back, arguing per InfoQ that what actually protects Linux distributions is fewer people with push access combined with a time delay, rather than signatures on their own: “What keeps Linux distributions safer is that fewer people are able to push updates and there’s a time delay. The compromises are because people exploit release pipelines, and if your build infrastructure is compromised, it’ll merrily sign the compromised packages as well.” Commenter summarybot was more skeptical of the cooldown approach generally, calling it, as quoted by InfoQ, “the lowest tech solution to a technological problem I have seen in a long while,” given that GitHub owns npm and has extensive code-analysis capability. On trusted publishing specifically, commenter pimterry explained its value against a compromised workflow: “Trusted staged publishing helps a lot: you have to independently pwn the workflow and then complete a separate 2FA flow as a maintainer. The workflow never sees any keys that can publish independently.”

InfoQ’s own analysis pointed to an asymmetry in GitHub’s approach: the changes rolling out automatically, like the account freeze and the checkout defaults, are comparatively moderate, while the strongest controls — staged publishing and trusted publishing — remain opt-in and, per InfoQ, unevenly adopted.

What We Don’t Know

GitHub has not published a timeline for when the Actions network firewall might move from logging outbound traffic to actually blocking it; the company describes egress restrictions only as “future work.” GitHub’s post also does not state a total count of how many controls it has shipped since the current hardening push began, so it is not possible to say precisely how many discrete changes the company considers part of this effort.