Four security features every GitHub Actions pipeline needs in 2026

SolarWinds in 2020. Codecov in 2021. event-stream in 2018. Three supply chain attacks that shaped six years of CI/CD security thinking, and every one of them started in the build process. On March 26, 2026, GitHub published a security roadmap for Actions aimed squarely at that gap. Four features, with the first public previews due in three to six months and GA in six to nine.

Most teams we work with put a firewall on their production database but leave their CI runner wide open to the internet. That gap is exactly where attackers operate.

The egress firewall changes everything

This is the one that matters most. Start here.

Today, when npm install runs inside your pipeline, it can reach any server on the planet. A compromised package phones home, exfiltrates your CI secrets to an external endpoint, and you find out days later from logs. Maybe. Or you never find out at all.

GitHub is adding a Layer 7 firewall that runs outside the runner VM. You define a whitelist of allowed domains (registry.npmjs.org, github.com, your private registry) and everything else gets blocked. No DNS resolution, no TCP connection, nothing.

That placement is the whole point. An attacker who gets root on the runner still cannot bypass the firewall, because the rules run on a layer they never reach. Inside the VM, root would have ended the argument.

What you can configure:

• Allowed domains and IP addresses
• Allowed HTTP methods
• TLS requirements (minimum version, certificate pinning)

If you already run client-side security properly, this is the half you were missing. CSP headers and SRI hashes defend what happens in the browser. The egress firewall defends what happens in the build. Skip either one and the hole is still there.

A typical supply chain attack follows one shape. The compromised dependency calls home, exfiltrates tokens, or injects malicious code into the output bundle. The egress firewall kills that at the network level. Not with logging, not with an alert. The connection simply does not happen.

Runner VMs currently have unrestricted internet access. That is like running a database without a firewall and hoping for the best.

Public preview for the egress firewall lands around the turn of Q4 2026 into Q1 2027, with GA sometime in Q1 or Q2 2027.

Dependency locking via SHA

This one has been a long time coming. It works like go.mod or package-lock.json. Every action in your YAML gets a SHA hash instead of a tag.

Today:

uses: actions/checkout@v4

The v4 tag is just a pointer. It can shift to a different commit at any time. One force push to the tag and your next build pulls entirely different code. No warning.

With locking:

uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Changing a SHA now takes an explicit update, and a workflow carrying an unlocked reference will not run at all, because validation happens inside the pipeline itself. Dependabot never got that far. It can update SHA references but it cannot force anyone to use them. A developer adds a new action with a tag, Dependabot stays quiet, nobody notices.

Some teams pin SHAs manually. Fine. But maintaining it by hand is extra work and most teams stop after a while (how many people on your team know what SHA actions/setup-node@v4 resolves to?). Native platform support solves this the same way package-lock.json solved npm dependencies.

Public preview in Q3 or Q4 2026, GA between Q4 2026 and Q1 2027.

Policy controls

A centralized ruleset framework at the organization level. Admins define who can trigger workflows, which events are allowed, which actions are approved, which runner labels are required. One place instead of 40 pull requests into 40 repositories.

Today this is handled by a patchwork of branch protection rules, CODEOWNERS files, required status checks, and workarounds. The result is fragmented and painful to audit. For regulated industries (banking, healthcare, public sector), the new framework covers audit trail requirements that also matter when preparing SaaS, ERP, and HR systems for NIS2.

Take a bank. Production deployments there can only be triggered by a release-engineering team member, only via the main branch, only with an approved PR. Under the new framework that is one policy in one place. Public preview arrives alongside dependency locking in Q3 or Q4 2026.

CI/CD telemetry

Actions Data Stream, near real-time telemetry to S3 or Azure Event Hub. GitHub also signals future process-level visibility. Not just "step X took 45 seconds" but "step X spawned processes A, B, C and opened network connections to these addresses."

If a step that normally takes 30 seconds suddenly runs for 5 minutes, something changed. Streaming to S3/Azure Event Hub means you plug into your existing SIEM (Splunk, Elastic, Datadog) without custom scripts. Useful for compliance audits and forensic investigation after incidents. Public preview spans Q4 2026 and Q1 2027, GA together with the egress firewall in Q1 or Q2 2027.

What to do now

Pin your SHAs using pinact or pin-github-action, that is half a day of work that drastically cuts supply chain risk. Check workflow token permissions, because most workflows do not need write on contents or packages, so switch the default to read. Drop third-party actions from unknown authors with 50 stars. Fewer dependencies, smaller attack surface. And figure out how many secrets your organization has and when they were last rotated.

Two decent starting points are GitHub's security hardening guide and the OWASP CI/CD Security Top 10.

Last time we audited a client's pipeline, we found 14 dependencies without SHA pinning. Half a day to fix. Without the audit they would still not know. If you want to find out where your pipelines stand, get in touch.