What’s coming to our GitHub Actions 2026 security roadmap - Feedback & Suggestions #190621
Replies: 19 comments 34 replies
-
|
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 :) |
Beta Was this translation helpful? Give feedback.
-
|
Hi |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
For 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I would love secrets to not just be available to any action (as an environment) but only when explicitly provided using |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
Love this! Also we need the policies here to be quite flexible. —- On a similar note, we need oidc for GitHub apps. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
I see this as a first step into the right direction. Congrats on that, expect the timing could a bit better. And that is to implement real secrets management with bulk rotation / revocation. I'm having a background in specific areas and worked with GH Enteprise for one customer in the past. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
Please have a look at Also see a post from Chainguard's CEO regarding that. |
Beta Was this translation helpful? Give feedback.
-
|
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). Examples:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing the roadmap! Here's my feedback on each area: Restricting which branches can trigger certain workflows Scoped secrets and improved secret governance OIDC improvements for more cloud providers |
Beta Was this translation helpful? Give feedback.
-
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.
Process-level and network-level visibility will significantly improve security audits and diagnosis after an incident, as well as deeper Actions debugging and troubleshooting. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Please see this suggestion for potential inclusion as well https://github.com/orgs/community/discussions/191125 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
We'd love your feedback:
Subscribe to this discussion to stay updated as we share more. 🔔
Beta Was this translation helpful? Give feedback.
All reactions