What’s coming to our GitHub Actions 2026 security roadmap - Feedback & Suggestions

[samus-aran]

We recently published a blog post outlining capabilities GitHub is actively investing in and developing for Actions security:

🔗 Blog post: What’s coming to our GitHub Actions 2026 security roadmap

Capabilities highlighted in the blog:

• Workflow-level dependency locking
• Workflow execution protections
• Scoped secrets and improved secret governance
• Actions data stream
• Native egress firewall for GitHub-hosted runners

Note: The blog does not include all active investigations. We will follow up in this discussion with additional capabilities as updates become available.

We'd love your feedback:

• What are your thoughts on the capabilities listed above?
• Are there other capabilities or areas you think GitHub should mention or prioritize?

Subscribe to this discussion to stay updated as we share more. 🔔

[offensive-actions]

Cool roadmap! Will definitely dive into it. My first reaction (also regarding the dependency locking) : get rid of the whole "commit to a fork is part of the network of the forked repo" so I cannot just create my own sha in e.g. actions/checkout and then pin to that hiding my malicious code :)

[Steve-Glass]

Great call out here and noted!

[DanielRuf]

The fork network feature was often more a problem than a solution. The UI did not and probably still does not show where a single commit belongs to.

But that is just one of many things that I see and would like to see some changes.
Here is one more: aquasecurity/trivy#10425 (reply in thread)

There is a big gap between what the frontend shows and what other parts show when some error ocurs.
Not the only design flaw but one that makes it harder for users using the UI instead of the API and other interfaces.

[ViacheslavKudinov]

Hi
I'm curious how workflow-level dependency locking will coexist with enterprise org level policy for allowed Actions.
Also maintenance of these "dependencies" without support by tools like Dependabot and Renovate will be a challenge for the teams.

[ViacheslavKudinov]

On the screenshot which was added on blog post there are two different places where Action is set - well known uses, which is what admins usually allow on org/enterprise levels (when we do sha, tags, but not *), but as it was also introduced new section dependencies,
does it mean it will be the need to allow what is used in both sections, what is used in uses and what is used on dependencies, not sure i'm getting what is expected to be exactly "allowed" when we get dependencies section.

Looking forward to get more information to get it better. Thank you in advance.

[DanielRuf]

The dependencies entries will be generated from the CLI, as I have understood.
Think it like that (if you are familiar with npm):

Everything stays in your uses entries as before and references only the used actions ("packages") in general and the wished version.
dependencies is your embedded generated lockfile (like package-lock.json, composer.lock, go.mod, ...).

It's just attached to the original file to pin and lock things.

[DanielRuf]

And I guess (and highly hope), that any newly added uses entry with a unreferenced action in dependencies will lead to a failing pipeline run similar to how the other tools work when strictly installed from and veryfying against lockfiles.

[Steve-Glass]

And I guess (and highly hope), that any newly added uses entry with a unreferend action in dependencies will lead to a failing pipeline run similar to how the other tools work when strictly installed from and veryfying against lockfiles.

@DanielRuf That is correct. If an new uses entry is added without pining, the workflow will not run.

One thing I have been considering is a new setting that will globally require pinning for an enterprise, org, or repo. My concern is that it will cause many to workflows to fail without ensuring that teams have had time to pin dependencies. This isn't something we'd ship in an early phase, but curious what others think.

[AdnaneKhan]

The hard part with these “all or nothing” settings is onboarding teams at scale.

If there was a way to make it apply to new or modified workflows, then it’s easier to drive adoption with less developer pain.

[ViacheslavKudinov]

Workflow execution protections is a good one, but what is not mentioned who can cancel running workflows and who can delete workflow run logs, as for now it can be everyone with "write" access. Which is against PoLP, especially the part to delete run logs.

[gregose]

👋 thanks for commenting and highlighting this current behavior. We acknowledge the issue of workflow run logs being able to be deleted by any GITHUB_TOKEN with actions:write permission. After seeing this exploited in a number of supply chain attacks, I bounced the idea off the team of special casing this actor (the GitHub Actions bot) and preventing it from accessing this API. In our review however, there are valid use cases for workflows to delete workflow runs and logs (like cleaning up artifact storage space, etc), so we haven't shipped this change.

That said, with the forthcoming "Actions Data Stream" we are looking to make this new data stream the immutable source of truth for what workflows ran and what they did, replacing workflow run logs in their use for security investigations. While we are still actively tracking and discussing limiting the ability for the GITHUB_TOKEN to delete workflow runs, I think this new feature will fill this gap in incident response visibility.

[DanielRuf]

And there is also the part with log retention. That is much shorter for the normal GH instances compared to GH enterprise.

I know, log management costs disk space and other resources. But could there be at least an option to use your own SIEM and configure some central repo setting, so that all logs are also sent to it? Many companies already use some solution for log collection, aggregation and analysis.

[ViacheslavKudinov]

We were asking our GitHub manager(s) about the feature to keep the Actions logs optionally for more than 400 days (current max for Enterprise cloud).
Our company works under some regulations and even centralized logs not always what auditors ask us about. They want to see the logs on GitHub ecosystem for some use cases and with only 400 days it becomes for us more difficult to pass the audits.

Yes, storage costs the money, but if its an option which some companies ready to choose and pay for, it would be the option which helps us a lot with passing the external audits.

[AdnaneKhan]

For workflow-level dependency locking I think a dependency on a manual action via the CLI is going to make this hard to adopt - especially to onboard existing workflows.

could this be built into the PR flow? As a PR creator (or other user with write access to PR head) who modifies a workflow I’d like the ability to run the dependency resolution and them commit the result on top of my commit via web flow.

[Steve-Glass]

Appreciate the thoughts on this! We are starting with the CLI to get running as soon as possible 😄

I like the idea of getting this built into the PR flow. This is an avenue we need to explore, along with augmenting the existing YAML authoring experience to accommodate locking.

This portion of the experience is not set in stone and I am open to suggestions to make sure we get this experience right the first time. Keep the suggestions coming!

[fproulx-boostsecurity]

Do something about "Imposter Commits". Accepting a PR from an apparently good samaritan suggesting to pin your GitHub Actions from tag to commit SHA can be worse than not accepting if they point to uses: actions/checkout@COMMIT_SHA_IN_FORK_NETWORK - then should be a warning in the Pull Request and the ruleset policy you mentioned, should disallow pinning on commits that are not in the Git tree of the default branch of the action's repo (this is similar semantics that Go Mod's Cache uses, you cannot put in a go.sum sometimes that the Go Module Mirror was not able to indepently confirm is at least part of a branch in the repo (not from a fork)

[fproulx-boostsecurity]

Ahhh @offensive-actions got it first above ^^

[offensive-actions]

It is the most unituitive thing and everybody I show that to just looks at me like what 😅 Normally I understand where things are coming from, but I really struggle to see the upside of this behaviour. If there is any reason to do it like this I would love to learn about it :) Especially since there is no easy way (like one call) to check in the API if the commit belongs to an (even deleted!!) fork...

[gregose]

Thank you both for raising this, 100% noted and under discussion as we revisit Action dependency resolution and how we pin (and what we allow to be pinned). It is critical that these dependencies can clearly and accurately be used to determine the source of this code and allowing imposter commits make this impossible. If a workflow is compromised and the source of the dependency being loaded changes to an attacker controlled one, we have to make sure this is very clear.

Normally I understand where things are coming from, but I really struggle to see the upside of this behaviour.

There is really no upside 😄 The backstory here is unrelated to Actions dependencies, but instead broad architectural behavior about git at GitHub. All commits across parents and forks are stored in a "repo network," any commit is accessible across that network unless we do specific reachability checks for that commit in a repo. We do not do reachability checks by default, only in certain places where we specifically check it, like that "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository" warning you get in the web ui.

We had an attempt a few years ago to do this reachability check in Actions resolution, but ran into a number of existing usage of the current behavior for releases on branches, etc that lived in forks and it was decided not to break these use cases. Now with an opportunity to revisit this and be more opinionated about it, we can make dependency resolution more obvious and trustworthy.

[offensive-actions]

Sounds awesome :) Thanks for giving some backstory!

[ericcornelissen]

I would love secrets to not just be available to any action (as an environment) but only when explicitly provided using ${{ secrets.xyz }}. The scoped secrets on the roadmap are a nice idea but doesn't meaningfully address most of the historical cases of credentials being leaked. In fact, the pinning feature is more useful for that but 1) is opt-in and 2) still doesn't fully protect against secret leakage since you can still upgrade (and pin) to a malicious version.

[ViacheslavKudinov]

Good one!
Same here - would love to see the feature that workflows/runner(s) have access only to the secrets which are explicitly set/used in workflow(s), not all the secrets which belong to environment, repo or/and org, to reduce the scope what can be leaked if Action or runner was compromised.

[ViacheslavKudinov]

I would love to get natively from GitHub something like Chainguard done to replace PATs by implemented "octo-sts"

[fproulx-boostsecurity]

I would love to get natively from GitHub something like Chainguard done to replace PATs by implemented "octo-sts"

Oh my god YES! We built something very similar to OctoSTS about a year before they did and still using it, but it would be so much better to have it as core platform !

[fproulx-boostsecurity]

I’m sure @mattmoor would be on board 😄

[mattmoor]

You're absolutely right, @fproulx-boostsecurity!

EDIT: fixed for humor 😉

[arianvp]

One big issue I have is that you can't use dependabot to update npm dependencies of your github actions: actions/typescript-action#986

The reply was that this would be fixed with Immutable Actions but after 4 years of development that project seems to have been canned: github/roadmap#592

Immutable Releases does not solve the same issue as Github Action authors still need to commit build artifacts to their repos making it fundamentally incompatible with Dependabot.

Any plans on solving this specific pain-point? As it makes keeping the dependencies of the actions themselves practically impossible

[Steve-Glass]

Immutable Releases does not solve the same issue as Github Action

💯 This is something we plan to address this year. We have a few approaches we've been investigating. Each has their own potential impact to authors that we do not take lightly. I will share more detail in this thread over the next few weeks.

[Munken]

Trusted reusable workflows without requiring callers to pass secrets explicitly

Love this!
We are currently using azure vault + oidc federation to achieve this, but it have a significant cognitive load.

Also we need the policies here to be quite flexible.
Currently we allow everyone access to the secrets from the workflow main branch, while dev branches are more restricted.

—-

On a similar note, we need oidc for GitHub apps.
These are heavily used in these automations, but the require a certificate without expiration.

[kahalewai]

GitHub Actions security currently relies heavily on user awareness and best practices; stronger platform guarantees will really help the community. While pinning actions to full commit SHAs is correctly recommended and does provide immutability of content, it does not guarantee provenance, and this distinction is not well understood.

As documented by GitHub, users are expected to verify that a pinned SHA originates from the intended repository and not a fork, but this is easy to miss and not validated by the platform. This creates a gap where a malicious pull request can swap in a commit from a fork without changing the apparent owner/repo reference, undermining the trust model many users assume SHA pinning provides. The solution is to make provenance a first-class concept; an enforced property: ensure that owner/repo@sha resolves only to commits that exist within that repository, or otherwise fail the workflow.

In addition, provenance signals should be surfaced directly in pull requests and workflow logs (e.g., indicating when a commit originates from a fork or is being used for the first time), and ideally backed by cryptographic attestation mechanisms.

Additional ideas for improvements: include making immutable releases the default rather than optional, enforcing least-privilege permissions for tokens and secrets by default, strengthening environment-based secret scoping, and providing optional network egress controls to detect or prevent data exfiltration.

So to wrap it all up, recommend that GitHub update its guidance and messaging to clearly communicate that SHA pinning ensures immutability but not trust, and pair that guidance with automated enforcement and visibility features so that security does not depend on manual verification alone.

I hope this is helpful!

[DanielRuf]

I see this as a first step into the right direction. Congrats on that, expect the timing could a bit better.
But I still see some relevant points, that would fundamentally ease the process in case of any problem.

And that is to implement real secrets management with bulk rotation / revocation.
Not going to add more at the current time.

I'm having a background in specific areas and worked with GH Enteprise for one customer in the past.
I still see general design flaws, but you want to solve them by adding more layers instead of addressing them correctly.

[MarawanYakout]

Your approach of using the Actions Data Stream as an immutable source of truth for security investigations is a strong forward-looking solution. By decoupling the audit trail from mutable workflow run logs, you address the core incident response gap exploited in those supply-chain attacks. Knowing that the Data Stream will retain an unalterable record of what ran and what it did provides confidence that forensic analysis won’t be undermined by post-facto log deletion.

That said, I wonder if there’s room to layer additional controls on the deletion capability itself, even while preserving legitimate cleanup use cases. For example:

• Requiring a higher permission level (e.g., admin:repo or organization-level approval) for bulk log deletion

• Implementing a minimum retention period (e.g., 24–48 hours) before logs can be deleted, allowing time for security monitoring

• Separating the “delete logs” permission from the general actions:write scope so it can be granted more selectively

Such measures wouldn’t break existing cleanup workflows (which could adapt to use the new permissions or wait for the retention window) but would raise the bar for attackers attempting to cover their tracks. Combined with the immutable Data Stream, this would create a defense-in-depth posture: the Stream ensures visibility, while stricter deletion controls reduce the likelihood that visibility is lost in the first place.

Either way, I’m encouraged that the team is actively tracking this issue and leveraging the Data Stream to mitigate the risk. It’s a thoughtful balance between operational flexibility and security resilience.

[ViacheslavKudinov]

Another feature we were requesting from GitHub to add something like "Artifact attestations"/provenance enabled by default for all Actions run logs, as it could help with our audits when we can prove that logs which we saved via what ever implementation, like webhooks, are actually from GitHub, are not tampered, not artificially generated, etc.
As there is currently no native way to prove logs were created on GitHub
But some Logs/Data streaming solutions are appreciated.
I hope GitHub will not stop with only S3/"Azure".

[Steve-Glass]

I hope GitHub will not stop with only S3/"Azure".

We plan on meeting customers where they are at. It is not difficult to create new event sinks. We will work with early preview customers and and expand the list. Expect way more support leading up to GA. If there are any you'd like to see out the gate, let me know!

[mschoettle]

Please have a look at zizmor and its audit rules. These things (especially template-injection, dangerous-triggers, excessive-permissions, impostor-commits to name a few) should not be possible in the first place!

Also see a post from Chainguard's CEO regarding that.

[deiga]

I love the idea of rulesets as policies. We've been wanting to find a scalable way to apply policies to workflows (like OPA in CircleCI).
The examples didn't mention anything in the way of policies for workflows contents.
Would something like that be in the works though?

Examples:

• We want to block execution of Ubuntu-latest
• We have base container images for workflows and would like to show a "warning" when an upgrade is available.

[wrslatz]

Came here to make this same kind of request.

I'd really like for Actions to be supported as core policy dimension, on top of Actor Rules and Event Rules. Supporting Actions as a dimension of policy for Actions would allow infinitely more capable and flexible governance, often required by enterprises and difficult or impossible to achieve natively in Actions today.

Supporting Actions as a dimension of policy that must succeed prior to the execution of further workflows or jobs (essentially a "pre-hook" or "pre-flight check") would allow

• applying OPA policies on workflow YAML contents (restrict specific runners from being used, etc.)
• blocking insecure or undesirable workflows from executing, using zimzor or a similar scanning tool
• blocking workflows from executing if a repository is using dependencies with critical vulnerabilities
• enforcing a more flexible and real-time allow-list for Actions that are allowed to be used, supporting malware scanning and vetting of Actions before they execute (not possible with the current Actions allow-list)

If this were also expanded to support enforcing policies after workflows or jobs (essentially a "post-hook"), it could support additional types of governance and compliance checks, including

• requiring that a job or workflow have produced some output, like test results or coverage info, and validate the contents
• requiring a security or compliance check to execute that depends on some dynamic workflow output (test results, coverage info, etc.)

Ideally any Actions used as policies would allow

• failure that blocks further execution for the job(s) or workflow(s)
• warning that notifies users but continues
• approval gate that requires users with specific roles to review and approve or deny

While Actions as a dimension of policy can be partially achieved with required and reusable workflows, it is difficult to actually implement and very limited functionally (hard to enforce prior to execution of user-defined workflows, or requires gating Actions behind only reusable workflows managed at the organization or enterprise level). Dynamic pre and post checks that are enforced at an organization or enterprise level and that depend on or integrate with user-defined Actions workflows are really what is needed to support a wide range of governance requirements.

Some of these ideas may be more along the lines of enterprise governance and policy enforcement than solely security, but they are critical for enterprises to secure and govern their use of GitHub Actions.

[wrslatz]

Reading through this again, I think most of my feedback here would fit better under a "governing Actions at scale" topic rather than this one specific to securing Actions. The ideas most specific to securing Actions would be

• enforcing OPA policies on Actions workflows prior to their execution
• scanning Actions for vulnerabilities and malicious intent, using the new workflow-level dependency locking proposed in the roadmap
• configuring specific Actions to execute and requiring them to succeed prior to executing workflows ("pre-hook"), which could support the first two items

[Steve-Glass]

@wrslatz I really like you ideas around pre and post job policy hooks! In addition to Event and Actor rules we are building, there was a list of about 10 other rules we scoped.

Like @deiga stated We want to block execution of Ubuntu-latest is one of them. More around the ability to limit execution based on runner type (hosted vs. self-hosted, standard vs. larger runner) and even repository visibility. Rather than build a bunch of rules nobody wanted, we wanted to start with capabilities that had strong signal and work with the community from there.

[wrslatz]

@wrslatz I really like you ideas around pre and post job policy hooks! In addition to Event and Actor rules we are building, there was a list of about 10 other rules we scoped.

Like @deiga stated We want to block execution of Ubuntu-latest is one of them. More around the ability to limit execution based on runner type (hosted vs. self-hosted, standard vs. larger runner) and even repository visibility. Rather than build a bunch of rules nobody wanted, we wanted to start with capabilities that had strong signal and work with the community from there.

@Steve-Glass starting with a smaller set of rules that are more applicable to a wider group makes sense. Being able to apply policy without needing to write custom Actions or code is really appealing.

It would be awesome if these new policy rules integrated well with the VS Code Actions workflow editing experience and/or a CLI experience. Catching and blocking these kinds of things prior to actually pushing changes up to GitHub would be great.

If OPA policy could be supported as native rules somehow and not require custom Actions workflows that would likely cover a lot of use cases. For example, I may want to enforce that workflows for Node.js projects use npm ci instead of npm install, as the preferred and more secure installation method in CI. Open to other ideas besides OPA for how to ensure CI/CD workflow best practices are followed where the content within the workflow YAML needs to be checked. We'll basically want to be able to enforce policy on any YAML content.

[ViacheslavKudinov]

I love idea of "native support of OPA", as Rego is kind of industry standard for policies as code and several vendors support native integration. It extremely flexible and could help a lot with many policies to enforce on "content" of workflow files and not only workflows, but just any files on the repo which Enterprises need to control.

[naqvi110k]

Thanks for sharing the roadmap! Here's my feedback on each area:
Workflow-level dependency locking
This is long overdue. Similar to package-lock.json, locking action versions by SHA is already a best practice but having it enforced natively would prevent supply chain attacks like the tj-actions/changed-files incident.
Workflow execution protections
Would love to see controls like:

Restricting which branches can trigger certain workflows
Requiring approvals for workflows touching production environments

Scoped secrets and improved secret governance
Currently secrets are too broad. Being able to scope secrets to specific jobs or steps (not just repos/environments) would reduce blast radius if a step is compromised.
Actions data stream 🤔
Would be useful for enterprise audit logging. Would love to know if this will integrate with SIEM tools like Splunk or Datadog natively.
Native egress firewall
Huge win for security teams. Would love allowlist/denylist support per workflow, not just globally.
What I'd love to see added to the roadmap:

OIDC improvements for more cloud providers
Signed workflow runs (provenance for CI builds)
Native support for detecting secrets in PR diffs before merge

[deiga]

The "which branches" and "approvals for production" environments is already possible with Environments. Or are there dimensions which it doesn't cover?

[ViacheslavKudinov]

Native egress firewall
Huge win for security teams. Would love allowlist/denylist support per workflow, not just globally.

StepSecurity has pretty nice implementation for Egress filtering via theirs harden runners Action.
I would really love to get something similar from GitHub as it would cover not only GitHub managed runners (that only was mentioned on roadmap), but also any type of runners, including self hosted ones.

[wrslatz]

Increased visibility with Actions Data Stream

Alongside this feature, support for OpenTelemetry, either natively or via a collector that can be self-hosted which handles conversion from the Actions Data Stream (edited for clarity), would be really helpful. This would allow CI/CD telemetry from Actions to be ingested in an industry-standard and vendor-agnostic format and more easily combined and used alongside other telemetry sources that support OpenTelemetry.

See https://github.com/orgs/community/discussions/162361, https://github.com/orgs/community/discussions/160683, and open-telemetry/opentelemetry-collector-contrib#27460. Also see https://opentelemetry.io/docs/specs/semconv/cicd/cicd-metrics/ and https://github.com/open-telemetry/community/blob/main/projects/ci-cd-phase-2.md.

What you can observe:

...

• (Future) Network activity and policy enforcement outcomes

Our future goal: treating runners as protected endpoints
Runners shouldn’t be treated as disposable black boxes. We’re expanding toward:

• Process-level visibility
• File system monitoring
• Richer execution signals
• Near real-time enforcement

Process-level and network-level visibility will significantly improve security audits and diagnosis after an incident, as well as deeper Actions debugging and troubleshooting.

[Steve-Glass]

I appreciate the feedback here and will discuss further with the team. I don't think it should be a problem and will report back.

[DanielRuf]

Will you directly help / work with those listed projects and also Trivy and LiteLLM with the application of the new solutions and collect their valuable feedback as possible early adopters or do they also have to wait for the public preview like the rest of us?

Seeing some direct support for these from GitHub would be great and would increase trust in GitHub as a secure platform for big important projects. Otherwise it might seem like they are on their own.

I very welcome a strong joint effort with those, who can provide the most valuable feedback.

[DanielRuf]

Just curious, because I think these should be the first to have access to some preview.
And I think others would very welcome this, if you would work together.

If this will be or is already the case, then pardon for my strongly worded comment.
Just trying to have the best cooperation, that the OSS ecosystem needs to be more secure than ever.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[HudsonGraeme]

Please see this suggestion for potential inclusion as well https://github.com/orgs/community/discussions/191125

[jsgosh]

Workflow execution protections are what I was looking for when I came across this post.

Please consider my use case: a monorepo where a self-hosted runner intended for a scheduled workflow should not automatically accept jobs from users on the basis of repository write access alone.

The protections currently available each constitute a prohibitive practical compromise, relying on polyrepo structure (runner groups), manual intervention (required reviewers), or elaborate overhead (custom deployment protection rules).

It would also be helpful if on-push deployment could be granted to specific users/teams.