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

[widebang]

ผมไปจากที่นี่ไม่ได้ผมชอบหาดูอะไรใหม่ในgithubแม้ว่าผมจะเขียนหรือใช้ไม่เป็นก็หาวิธีอื่นๆอาจก่อกวนสมาชิคทุกท่าน แต่ผมตั้งใจที่สุดเพื่อจะว่างผลงานแรกพร้อมกับทีมช่วยเหลือ แบ่งปันประสานสัมพันธ์ที่ดี ผมขออยู่เบื้องหลังพร้อมสนับสนุนความถูกต้องให้ชุมชนนี้ต่อไป ผมไม่ใช่บัคอย่างที่พูดกันนะ แค่ผมดวงดีบ่อยๆเท่านั้นเอง ขอบคุณมิตรรักสหายทุกท่านคับ

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

[woodruffw]

First, thank you for the work you're doing to make GitHub Actions more secure! I'm a huge fan of any work that makes the GHA ecosystem more secure by default.

I'm curious to hear more about the risks you foresee with the "disable by default" alternative: my experience with zizmor has been that >90% of (public) workflows can have credential persistence disabled without any breakage, and that the remaining ~10% typically have "obvious" usage patterns where the fix is straightforward (either re-enabling credential persistence, or explicitly passing what would have been the persisted credential in via env).

10% of all workflows is still extremely disruptive for a breaking change of course, but I think there's precedent for that with other breaking changes that have been made in the name of security to the actions ecosystem: the recent hidden files changes to upload-artifact, for example.

TL;DR: I think it is worth considering a breaking change here, and that users can be expected (with sufficient documentation) to re-enable the old default without doing things in unusual and more insecure ways. Tools like CodeQL are well suited to act as a forcing function in that regard 🙂

[gregose]

@woodruffw Thanks for your reply and all you've done in zizmor to help keep Actions users aware of security vulnerabilities in their workflows. Ideally we can start chipping away at the different rules zizmor detects by eliminating these vulnerability classes!

TL;DR: I think it is worth considering a breaking change here, and that users can be expected (with sufficient documentation) to re-enable the old default without doing things in unusual and more insecure ways.

This is definitely something we could still consider, but I think shipping a more secure way to store the persisted credentials in a non-breaking manner is the right first step. Then, if we do disable this by default, users needing the persistence for subsequent git operations can re-enable the setting without stumbling into the risk of those creds being in the working git repository.

The difficult part here is that we do not have visibility across all commands executed in Actions workflow runs and if git commands are utilizing the persisted creds or not. A quick public code search shows a lot of authenticated usage of git (in this case simply git push) that may or may not rely on the persisted credentials. Some of these obviously pass a secret in the command line call itself, but others seem to be relying implicitly on the persisted creds. Without having clarity on the breadth of breakage, it is hard to push for this change to the default that will result in work for developers to revert to the prior behavior.

I also want to detail a bit more on the risk here between having this enabled by default or not with the new storage location. I believe when moved out of the git working directory, the risk of exposure of these credentials is minimally increased by the persist-credentials behavior. The secret being stored by default (GITHUB_TOKEN) and other secrets for that job will still be available across all steps of the job in memory, regardless of the usage of actions/checkout. So really the risk here is less about the additional persistence of these creds across steps, but where they are being persisted and the likelihood of those being accidentally exposed before a workflow ends.

[woodruffw]

This is definitely something we could still consider, but I think shipping a more secure way to store the persisted credentials in a non-breaking manner is the right first step. Then, if we do disable this by default, users needing the persistence for subsequent git operations can re-enable the setting without stumbling into the risk of those creds being in the working git repository.

That makes sense! And yeah, I think your plan of first moving the credential to a less risky location is great -- I just wanted to nudge forward the idea that disabling on-disk credential persistence is a good long-term goal, even if it isn't something that there's breakage appetite for with the next upcoming major version of the checkout action 🙂

The secret being stored by default (GITHUB_TOKEN) and other secrets for that job will still be available across all steps of the job in memory, regardless of the usage of actions/checkout. So really the risk here is less about the additional persistence of these creds across steps, but where they are being persisted and the likelihood of those being accidentally exposed before a workflow ends.

Yeah, agreed -- I think the risk here hinges entirely on users not realizing that there's a plaintext credential on disk, rather than it being resident in memory (since a malicious party could always exfiltrate it there). Moving to RUNNER_TEMP will be a great step towards making it harder to inadvertently share the credential elsewhere; zizmor's users have already observed that I'll probably need to lower the severity on the "artipacked" audit to low thanks to this change!

(And yeah, long term I would love to be able to delete rules from zizmor entirely as GitHub changes towards more secure defaults! There's nothing better than a security tool that shrinks its footprint over time!)

[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?