GitHub Actions in 2026: four security features every pipeline needs

Three supply chain attacks defined the last six years of CI/CD security: SolarWinds (2020), Codecov (2021), event-stream (2018). Every single one started in the build process. On March 26, 2026, GitHub published a security roadmap for Actions that directly addresses this: four features, first public previews in 3–6 months, GA in 6–9.

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.

The architecture matters. The firewall sits outside the VM, which means an attacker who gains root on the runner still cannot bypass it. The rules execute on a layer the attacker cannot touch. Compare that to firewalls running inside the VM where root access means the game is over.

What you can configure:

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

For teams already working on client-side security, this fills the other half of the picture. CSP headers and SRI hashes handle runtime threats. The egress firewall handles build-time threats. Without both, you have a gap.

A typical supply chain attack works like this: compromised dependency calls home, exfiltrates tokens, or injects malicious code into the output bundle. The egress firewall stops this 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 arrives Q4 2026 – Q1 2027, GA sometime in Q1–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, not 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 the SHA requires an explicit update. A workflow with an unlocked reference will not run, because validation happens directly in the pipeline. That is the difference from Dependabot, which can update SHA references but cannot enforce their use. 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 Q3–Q4 2026, GA in Q4 2026 – 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 we discussed in the context of Slovakia's cybersecurity strategy 2026–2030.

Example: a bank needs production deployments triggered only by a release-engineering team member, only via main branch, with an approved PR. With the new framework, that is one policy in one place. Public preview alongside dependency locking in Q3–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 Q4 2026 – Q1 2027, GA together with the egress firewall in Q1–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.

Good starting points: 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.