Protecting .github/workflows

Hi all,

It is mentioned onthis page that it is possible to restrict modifications of the workflow file.

However I there is no explanation on how to do it. Is there a doc somewhere?

I dig the actions/workflow framework but I am a little worried that anyone can change a workflow with a pull-request and expose secrets or disable checks.

Thanks in advance,


Those are the old docs for workflows based on HCL. You should look at the docs for the new YAML workflows because a lot has changed.

There are a few ways to control changes to workflows flows:

  • Workflow files will only execute in the context of a branch they exist in. If someone creates a PR with a change for a workflow file that targets master, it won’t run on master until that PR is merged into master.
  • You can use codeowners and branch protection to require reviews for changes to files in .github/workflows
  • Secrets aren’t passed to workflows that run in PR from forks, to prevent leaks.

Thank you @jeremyepling 

I will play with codeowners and see if works for me.

1 Like


Does it mean that if you have an org that folks can contribute to private repository by creating branches and waiting for it to be reviewed before merging the PR to master, can go ahead create a branch, change the a workflow on the branch (allowing them to read secrets), and if the workflow changes live deployments there is no protection we can put.

That eliminates the whole development workflow of having contirbutors helping collaborators on a repo and allowing them to make changes without a PR being approved and merged to master.

Any way of protecting these?

OK. I’ve ran few tests. It seems like you first have to make sure you have a workflow that is looking at non-master (or whatever protected branches you have) to be able to run on them.

You cannot create a branch, add a workflow in that branch and have it trigger on that branch if it’s not already merged to master(or default) which is great.

You just have to make sure you don’t accidently introduce workflow that can change your production env on non master branches(or production branches) -duh :slight_smile:

Let’s say we have a deployment workflow that uses a secret key stored in github secrets. Can’t a dev with write-access make a branch off master, create a new workflow that runs on push to their custom branch, utilize the secret key that gets passed in, and trigger a deploy? How do you protect against that?

Ideally I would like a dev to have write permissions but not deploy permissions

I’d like to avoid having all internal devs fork the repo

Edit: upon further investigation it seems like forks won’t run any workflows. That is a blocker for us because we need tests/linting to run on PRs


You cannot create a branch, add a workflow in that branch and have it trigger on that branch if it's not already merged to master(or default) which is great. 


How would you achieve the above which you said earlier?

Because I am able to do the exact opposite.

1 Like

I don’t know how to deal with this situation.

Let’s say I’ve a single workflow setup that runs on push to master only. But someone just forks the repo, add their own modified version of workflow and creates PR against master with on.pull\_request policy. Even tho secrets are not exposed to that PR, it’s still annoying if that PR contains something bad. Also even if base repo workflow contains policy for on.pull_request event, forked PR can still override base repo’s workflows. 

Am I missing something here? I’m not sure this is the desired behaviour.

I’m on the same boat. I have a public repository that anyone can fork and submitted PRs to and right now anyone can change the .github/workflow files as they please and it’ll get executed just fine. With GitHub-owned runners that is less of a concern but with self-hosted runners this is a major security flaw.

In Jenkins, we have a list of pre-approved users that will get their PRs built automatically and anyone else needs an okay from an admin before that happens. I don’t know how to implement this safely in GitHub Actions.

I played with some actions that limit builds to a certain user list but, because the user list is inside the workflow file, contributors can simply erase that from the file and be fine. It’s unsettling.

I think we need a flag somewhere saying the only workflows that will run are the ones in the master branch and not ones in other branches and/or PR’s.

As is already mentioned in prior comments, this question should not be marked “Solved”.

An example of the problem:
I have enabled GitHub Actions to deploy to my production environment. To do this, GitHub Actions checks for:

if: github.ref != 'refs/heads/master'

However, there is no way to prevent a malicious PR to my repository which simply removes this line, thereby accomplishing a production deployment without the PR being merged.


I think and agree with @bittelc 

So the issue is not solved.

And this issue should be differianted in 2 category.

  • workflow on branches (yes this can be fixed easy)

  • workflow on Pullrequests  (this is not fixed)

The solution here proposed is only for workflow running on Branches.

However if you have a workflow running for pull-request, there is no way by github to proctect a user to change the workflow for PR and redirect output.

1 Like

@jeremyepling this issue is very much not resolved today. Here is one example of how the protection around the .github/workflow files are not sufficient. As @mallozup said:

If a project has a workflow (example.yml) that is triggered on push to master, and I create a branch in the project and change the workflow example.yml to be triggered on pull_request against master and then change the workflow itself I can circumvent all branch protection and controls on the pipeline and use it to execute whatever I want and utilize the projects secrets.

I have opened an issue to runner repo regarding this:

Hi Everyone,

I’ve put together a Github App that will trigger a workflow based on the changed files, and the actor behind the change.

I’m looking for a few early adopters to provide feedback before releasing it.
If you are interested please let me know, and I’ll setup a place for us to talk.

1 Like

The app has been released.

1 Like

Hey there,
any news here because the missing security features is causing some workarounds for us in our project. Does everyone has a good way of prevent specific roles or users to edit the workflow file and so get access to the repo secrets?

Best regards Peter

Hi, so what is the conclusion. I just set up Github actions to deploy to firebase

But I also noticed that anyone could just edit the PR action to deploy to production instead and make a PR …

Perhaps PR/test and master/prod should be handled differently.

In the PR case, a new PR and use Github actions to spin up a new server and deploy it, using a service account that does NOT have access to production stuff.

Then when merging into master, instead, the production server can watch for webhooks and then pull/build/deploy it.

This would solve the issue.