Towards a secure by default GitHub Actions

[Steve-Glass]

Why are you starting this discussion?

Product Feedback

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

Today, GitHub announced upcoming changes to the pull_request_target event, and environment protection rules. This is one of the first steps in a broader roadmap to make GitHub Actions more secure by default and we want to use this discussion post for collaboration and feedback on the changes we have planned towards this goal.

Historical context

Back in 2020, we introduced pull_request_target to help repositories run trusted workflows when pull requests are opened. Unlike pull_request, this event runs with the repository’s configured GITHUB_TOKEN permissions and other secrets, enabling deeper automation. That power comes with risk and this behavior has led to a number of impactful vulnerabilities in Action workflows. Because pull_request_target executes based on user-supplied pull requests, vulnerability patterns like pwn requests and script injection have shown how this flexibility coupled with a lack of an understanding of these security risks can lead to secret exfiltration or execution of untrusted code. The new behaviors scheduled for December 8, 2025 start to reduce these risks by anchoring execution to trusted, default-branch workflow definitions, allowing clearer remediation of vulnerabilities in pull_request_target workflows, and aligning environment policy evaluation with the workflow code that is executed.

What’s next?

We know more control and restrictions are needed to ensure these risky event types can be properly understood, governed, and restricted. Soon, we’ll update the public roadmap to share all of our priorities in this space, helping secure the workflows and code of millions of developers around the world.

This discussion is for collaboration and feedback. What changes or controls around pull_request_target or other functionality in Actions do you think would have an immediate impact on the security of Action workflows and the supply chains they power? With enforcement starting on 12/8/2025, we’d ♥️ to hear your thoughts on these initial changes and any constructive feedback you have as we refine our roadmap towards a secure by default GitHub Actions.

Looking forward to collaborating,
@Steve-Glass (Senior Product Manager - Actions) & @gregose (Principal Product Security Engineer)

[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. ⭐

[queenofcorgis]

@widebang:
Unfortunately, we don’t currently have moderators for languages other than English. Until that changes, we need to ask that everyone use English here in the GitHub Community when posting to ensure discussions are adhering to our Code of Conduct.

We’ll be hiding your comment for now, but please feel encouraged to create a new comment in English to join the conversation.

[jessehouwing]

I love this! There are a few other things on my wish list:

• In the Security center for Organizations and Repositories add a dismissible security warning when the Actions Workflow settings are set to "read/write" or "Allow writing pull request and checks". Especially if these settings were never changed from their original defaults for old orgs.
• Same for the Require Approval for Workflow Triggered by External Contributors setting set to a permissive default. Especially if these settings were never changed from their original defaults for old orgs.
• Add the ability to pin actions from the actions editor in both GitHub Actions and the Visual Studio Code workflow editors. Automatically show the option to copy snippets with sha from the marketplace helper.
• Ensure that Custom CodeQL and dependabot workflows work with the new require pinned actions policy.
• Add the ability to pin actions from Dependabot.
• Enable CodeQL for Actions and Dependabot for Actions automatically
• Add the ability to scope secrets to workflows and branches
• Change the Cache task behavior to do the right thing for fork-pull requests by default instead of requiring people to pick the right cache-restore task. Same for the Nuget, NPM, PyPi setup tasks which shouldn't update caches from forks.
• Workflow Dispatch and Repository Dispatch triggers should have a branch filter configured in the main branch.

[fproulx-boostsecurity]

@Steve-Glass 100% agreed. I understand the issue with breaking changes for legacy customers.

But at the very least, do not make those new more secure defaults hidden, make sure they need actively Opt Out / Acknowledge.

[jessehouwing]

Add a ⚠️ This policy is not configured in its most secure setting. Read more.. banner when settings are set to a dangerous setting. Possibly with a when is this a bad idea explanation right on the warning or as a tooltip or anything.

This could be made clever and all... Showing the warning for external contributor fork actions require approval for public repos and private/internal repos that external collaborators for example...

But at the very least give me something I must dismiss when you add a new more secure setting. And help me roll it out.

For GitHub Actions Permissions for example, I'd LOVE a sort of tracer bullet option where you mark my token as a tracer token. Then I run the workflow in the 8 ways only I know how, and then you look in the audit log to see what permissions my token actually used. Then offer me a way to scope down the permissions. Or a similarly, an evaluate/enforce mode like you do with Repository Rulesets. Set the permissions stricter, but to evaluate. Tell me where my problems are, then let me fix them. Right now I must manually solve all the problems, or risk breaking things before I can turn on these better permissions. With 8000 repos in our org, that's just too hard to do.

[Marcono1234]

Add the ability to scope secrets to workflows and branches

Isn't this what Environments are for? You specify the secrets for the environment, define the rules when the environment may be used (branches, reviewers, ...) and refer to the environment in your workflow.

---

For GitHub Actions Permissions for example, I'd LOVE a sort of tracer bullet option where you mark my token as a tracer token. Then I run the workflow in the 8 ways only I know how, and then you look in the audit log to see what permissions my token actually used.

https://github.com/GitHubSecurityLab/actions-permissions might help with that.

[gregose]

Add a ⚠️ This policy is not configured in its most secure setting. Read more.. banner when settings are set to a dangerous setting. Possibly with a when is this a bad idea explanation right on the warning or as a tooltip or anything.

Love this idea, we have discussed this a few times for a number of known dangerous configuration combos (things like self-hosted runners in a public repo, etc). We try to warn strongly in the docs against these settings and highlight their risk (and what to consider if accepting the risk), but in UX warning before being set and when a repository / org is in an insecure state will allow us to communicate more secure defaults and encourage enablement if we cannot enable them for everyone at launch.

[jessehouwing]

Add the ability to scope secrets to workflows and branches

Isn't this what Environments are for? You specify the secrets for the environment, define the rules when the environment may be used (branches, reviewers, ...) and refer to the environment in your workflow.

But environments do not work for organization and repo level secrets. And would thus cause a lot of duplication because org level environment secrets don't exist.

They also don't work for required workflows. Yet the secret can't be scoped to be available in all repos, but only for that specific required workflow.

There would be a lot of value in scoping rules for org and repo level secrets similar to environmental, without needing to target an environment.

For GitHub Actions Permissions for example, I'd LOVE a sort of tracer bullet option where you mark my token as a tracer token. Then I run the workflow in the 8 ways only I know how, and then you look in the audit log to see what permissions my token actually used.

https://github.com/GitHubSecurityLab/actions-permissions might help with that.

Yes! Exactly like that! Thanks for sharing, I didn't know that existed. This should be a built in feature of any job not explicitly declaring permissions. Or at least be something an enterprise or org owner can enable for all jobs without permissions declared.

[gregose]

Security improvements to actions/checkout

We have released changes in actions/checkout v6 that provide a secure by default behavior in how the persist-credentials feature is implemented while also maintaining support for this commonly used functionality. This release is currently in beta and we are seeking any feedback or pre-release testing.

Background

Since v2 actions/checkout has supported persisting credentials across workflow steps in an Actions job. The persist-credentials flag is set by default and ensures that the git credentials used for the initial checkout (typically the GITHUB_TOKEN credential) can be used for git actions, such as pushing additional content, in subsequent steps.

The risk

To persist this credential, actions/checkout writes the token value to the .git/config file under the checked out repository. This has led to common cases where, if this file is not excluded from packaging and build processes, it could be exfiltrated out of the Actions runner into Docker images or other publicly available artifacts. While the default GITHUB_TOKEN has a limited lifetime to the duration of a workflow job, artifacts may be published and available prior to the completion of the job. Unless a developer is aware of this behavior in actions/checkout and knows to exclude these files, this could result in the compromise of this credential.

What is changing

With the change in v6, the stored credential is now written and persisted outside of the checked out git directory. This will prevent the common case of the credential being exposed within the git directory and reduces the likelihood of the exfiltration of this credential through artifact publishing. Instead of being written within the git directory, it is now stored in the $RUNNER_TEMP directory and referenced by .git/config to this external location. The $RUNNER_TEMP directory is cleaned up after each workflow job and is typically not used for the packaging of artifacts, limiting the risks of accidental exposure introduced by its prior behavior.

What alternatives were considered?

Disable persist-credentials by default

Many common workflows require this git credential to be available to git across steps in a job. By introducing a breaking change to remove or disable this functionality by default, we believe that many users will either re-enabled this feature or find less secure workarounds to implement this functionality. Additionally, it is important to note that the persist-credentials feature of actions/checkout does not increase the exposure of the GITHUB_TOKEN across steps in a job. Regardless of the usage of actions/checkout, the GITHUB_TOKEN is available to all steps within a job and removed and revoked when the job completes.

Store the credential in memory instead of a file

We investigated storing the git credential in memory instead of writing this to disk. However, given the complexity of various git credential helpers to implement this across all support Action environments (MacOS, Linux, Windows, etc), maintaining file-based storage was required.

We are excited to ship these changes to prevent this common vulnerability pattern and would love to hear any feedback you have about this change.

[gregose]

I want to share that actions/checkout v6.0 was released on Nov 20th and so far this change has rolled out smoothly with no reports of user disruption.

Props to @ericsciple in getting these changes architected and released and for all of the discussions here on additional improvements we could explore. I'm super excited that these credentials are moved out of the direct path of docker and other artifact generation!

[fproulx-boostsecurity]

@gregose is this going to be backported to other tags, or only on v6+ ?

[ericsciple]

@fproulx-boostsecurity only v6+. Otherwise we risk breaking customers who rely on the credential to be directly in the local git config for whatever reason.

[fproulx-boostsecurity]

Makes sense @ericsciple! Now there's good reason to recommend people to upgrade to v6 :)

[smlx]

I want to share that actions/checkout v6.0 was released on Nov 20th and so far this change has rolled out smoothly with no reports of user disruption.

Well... there was the one actions/checkout#2313. However since then I haven't seen other issues. 🙂

Props to @ericsciple in getting these changes architected and released and for all of the discussions here on additional improvements we could explore. I'm super excited that these credentials are moved out of the direct path of docker and other artifact generation!

Agreed!

[Marcono1234]

Thanks! Definitely a good thing that the security risks of pull_request_target are at least reduced to some extent.

What I am wondering though is if the change of environment branch protection rules related to pull_request_target actually introduces a new vulnerability (not sure what the current / previous behavior was):
If a repository already has a vulnerable pull_request_target workflow (e.g. which checks out and builds untrusted code of the PR), that workflow now gets access to the secrets of the environment intended for the default branch?

Or am I misunderstanding this?

[fproulx-boostsecurity]

My understanding is that the workflow YAML needs to explicitly mention the environment name. It’s just the rule matching in the environment itself. So I don’t think there’s any new threats for external contributions via forks.

[Marcono1234]

Ah good point. So this is probably not a security risk then, unless the vulnerable workflow is additionally configured to access the environment.

[fproulx-boostsecurity]

This is exciting. Finally some major changes to the threat model of GitHub Actions and this thread is great news for more transparency towards future changes.

[jessehouwing]

There is one more thing I'd love seeing changed:

It is specifically the "Allow actions to create and approve pull requests". This should NEVER have been a checkbox. Because now, when I toggle this off al the enterprise level, there is no way to turn it on at any of our orgs, or any specific repos.

So if I need this permission, I need to turn it on EVERYWHERE.

This should have been a dropdown like most all policies with:

Enterprise level: Org level: Repo level: [❌ deny v] [❌ deny v] [❌ deny v] |✅ allow | |✅ allow | |✅ allow | |❓Let the org decide | |❓Let the repo decide | 

And it should default to the most secure mode by default when you set it to "let X decide". So if the org is set to let "org decide", the repo should default to deny.

Preferably a separate option for Create pull requests and Approve pull requests. Cause they have similar, but different, security implications.

The all or nothing nature of this setting leaves it on in way too many places.

To be really honest, I'd love to be able, at the repo level, to set the default permissions for workflows as well to disallow certain permissions altogether. Let the workflow specify all they want, but if a repo doesn't need certain permissions, let a repo admin or org owner be the one to consciously add/remove a permission to the allow/deny list.

[joshuakeel]

I totally agree with all of this.

[Steve-Glass]

Preferably a separate option for Create pull requests and Approve pull requests. Cause they have similar, but different, security implications.

I ❤️ this and its one of the settings targeted for prioritization over the next year. Making it more granular is a great step.

[lishaduck]

I don't know if this is in-scope, but I know some people have been hesitant to move to Trusted Publishing because you can't force 2FA to approve deployments from GitHub environments, which feels related, so I thought it was worth surfacing over here as well.

[fproulx-boostsecurity]

@lishaduck that's interesting, you mean you'd like a step up, fresh 2FA, like when you do certain action in repo settings ? That would be nice... I guess that could be relatively easily be added to GitHub Actions Environment Rules, like "Required Reviewer", but make it mandatory to prove that it's really you... To harden the Trusted Publishing path even in the face of a threat actor with infostealer of githut.com session cookies that could approve the environment. That's definitely interesting. Are we including Repo Admin in the threat model?

[fkiriakos07]

I like the work done on immutable releases, any plan to enable it on repos by default?

[jayaddison]

Thanks @jessehouwing; I'm not completely sure I follow your line of thinking yet though?

I was raising a concern that SHA-versioning (aka hash-pinning) of GitHub action dependencies currently remains incompatible with Dependabot Alerts. Dependabot Updates work fine -- so you can receive pull requests that update your actions, but you won't be notified if a hash-pinned dependency contains a published vulnerability (as far as I understand it).

[jessehouwing]

By changing the way the actions are submitted to the dependency graph, I'm not just submitting the sha as the version of the task, but I'm resolving that to the most specific version tag as well and report that as a dependency too. That should allow dependabot security alerts to also trigger, since the repo now has the dependency also declare by version.

The dependency submission action also follows a forked action to its original source, so that enterprises that have forked all actions to an internal marketplace (essentially changing the namespace of the action), will also register a dependency on the original action's namespace and version.

From my understanding dependabot security alerts should be looking at the dependency graph to issue alerts, me manually fixing the graph should allow dependabot therefore to trigger anyway.

[jessehouwing]

in the example above, actions/checkout@08c69... is what's referenced in the workflow file. My dependency submission action queries the actions/checkout repo and resolves that sha to 5.0.0 and adds that version as a transitive dependency to the repo as well, and tell you what workflow file it picked that ref up from.

Now when dependabot queries the dependency graph, it should find both the sha as well as the version. And can trigger an alert. It probably won't generate a PR for you, but the alerting should work again.

I'm going to have to test my theory. for a number of scenarios, but I'm already quite happy that this will allow me to filter at the enterprise level on version ranges again, instead of needing to know all the specific SHASs.

[jayaddison]

Ok, I think that makes sense - thank you @jessehouwing for explaining. So, your action can accept dependencies -- specifically GitHub Actions actions deps? -- that are locked to a specific SHA, and then your action will identify the corresponding most-precise tag for those, and submit the result to the workflow-owning repository's dependency graph -- enabling Dependabot Alerts to identify reported vulnerabilities in those action dependencies, despite the repository natively referencing them by SHA (a reference style that Dependabot Alerts does not, itself, yet natively support alerting on).

[jessehouwing]

Yups that's the idea. The action parses all the workflow files.

[eregon]

Regardless of the usage of actions/checkout, the GITHUB_TOKEN is available to all steps within a job and removed and revoked when the job completes.

Is it? How?
At least it does not seem there in the environment variables.
Steps which are passed ${{github.token }} explicitly or actions which use it as an input's default get it in their ENV, but other actions & steps do not have any access to the token, right?

Thanks for this change, it certainly feels like a step in the right direction, though I think ideally it wouldn't be stored on disk at all, and only passed explicitly where needed.

[woodruffw]

The GitHub Runner itself (which orchestrates the job/steps) has the GITHUB_TOKEN in its memory and, and everything on GitHub Actions runs as root by default. Consequently, all a program needs to do is dump the Runner's memory (which it can easily do, since any privileged program can do that on Linux).

Here's a post (form 2023, but AFAIK is still accurate) that shows this technique: https://www.karimrahal.com/2023/01/05/github-actions-leaking-secrets/

[ewjoachim]

I reported exactly this issue via Hackerone in Dec. 2021 and got $200 and a tshirt (an awesome tshirt, btw). (GitHub didn't disclose but accepted that I talk about it).

It's fun to see that, 4 years later, it's finally fixed :)

[baynezy]

So I missed this, and now most of my deployments are broken. For pull_request, is it now impossible to have branch protection rules that match a specific branch name?

Update environment branch filters for pull_request, add patterns like refs/pull/number/merge.

This advice seems to make the branch protection rules pointless, unless I am missing something.

[baynezy]

@BarryDam - thanks. I did consider that, but I want to generate Terraform plans on the pull request rather than the push. So they can be reviewed in the PR, and I want to configure the TF credentials at the Environment level. Essentially, after the merge is too late. I will have a play and see if that helps.

[cawolfdev]

I really hope that a a reliable solution comes from this.
This is going to be a nightmare

[ArtGaif]

Horrible initiative. We're not paying for GitHub Enterprise just so our CI/CD breaks because someone decided to change something without thinking through all the use cases or providing a clear migration plan. I agree with @baynezy and suggest reverting this PR lol, as we don't have time to tweak our pipelines yet again. If it works, don't touch it. I understand why this is useful for open-source repos, but breaking enterprise workflows is a whole different story. We may even switch to GitLab if this continues to be unreliable.

[ArtGaif]

Simply provide a checkbox or toggle in the settings so that anyone interested in this feature can enable it. Set the default to "on" for open-source projects, but leave enterprise environments untouched - we're already under significant pressure, and unexpected changes that break production deployments (as happened in our case) feel like an attack vector originating directly from the GitHub developers! 😠

[AllanGuigou]

So I missed this, and now most of my deployments are broken. For pull_request, is it now impossible to have branch protection rules that match a specific branch name?

Correct, for workflows triggered by pull_request events it is no longer possible to match branch protection rules based on branch name. Previously with pull_request events it was possible to manipulate the HEAD_REF and gain unintended access to environment secrets. This breaking change was made to remove the false sense of security and accurately represent what version of the workflow was being executed for pull_request events.

Each customer will have different security and workflow requirements, but some possible workarounds are:

• Use branch filters or if conditions to limit which branches will run a workflow https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#running-your-pull_request-workflow-based-on-the-head-or-base-branch-of-a-pull-request
• Use alternative environment deployment protection rules (required reviewers or custom protection rules) to gate access to environments when using pull_request events https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments
• Use alternative workflow triggers, like push and continue to use branch protection rules based on branch name https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#push.

The decision to make these breaking changes was not taken lightly and it was a necessary step to build a more secure future for GitHub Actions.

[EliottMontero]

I have some workflows that can be run on pull_request_review: types: [submitted]. And since yesterday they are broken : asking for an environment approval, however there's no approval request anywhere.
I tried to put the relevant secrets in a specific environment with 0 restriction and I still have the issue. Are we the only ones with this issue or is this kind of workflow launch impossible anymore ?

[AllanGuigou]

👋 we are investigating issues with pull_request_review and environment protection rules, do your environments have any Deployment branches and tags selected?

[AllanGuigou]

@EliottMontero we've rolled out a fix for workflows triggered by pull_request_review from getting stuck on environment approval when branch policies are selected, they should now be evaluated against the merge ref as mentioned in the announcement.

[EliottMontero]

It's working again thanks a lot !

[cawolfdev]

Previously, any branch within the parent repository set as the base branch of a pull request could have been used as the source of the executed workflow (GITHUB_REF/GITHUB_SHA) and could result in the execution of outdated workflows

What is the recommended manner now to test changes to workflows using PRs?
Our workflows are extensive, and in the process, must connect to external services, pull and publish artifacts, and generates a full environment for the PR to be reviewed. When workflow issues occur, new features are needed, or new environment integrations are required to support a PR and it's deployment -- the PR is the source of the changes.

Are dozens of people weekly now expected to push directly to main to test changes to workflows that are used only for specific PRs (Which may not even be accepted, and thus need to be reverted after the fact)?