How secure are secrets?

Has anyone done a thorough analysis of how secure secrets are?

I’m asking because with my macOS / iOS Actions I’m at a point where I need to start calling into Apple’s App Store Connect API - and that is a bit scary.

I’m less worried about GitHub accidentally exposing secrets - I assume the part that stores them on the GitHub server and substitutes them in inputs is pretty solid.

What I do not have a good grasp on for example is what happens to secrets in pull requests. Specifically in public projects. Could someone submit a pull request and modify files in .github/workflows with a malicious intent to retrieve a secret.

I’ll do more research but I am curious about other people’s thoughts and insight.


1 Like

The documentation states:

With the exception of GITHUB_TOKEN , secrets are not passed to the runner when a workflow is triggered from a forked repository.

So if someone forks your repository and creates a pull request they won’t be able to steal your secrets (assuming there’s no relevant bug in the code that enforces the restriction).

If someone manages to trick you into merging a malicious change to the workflow or tools used in the workflow with access to secrets that’s a very different story: Post-merge the workflow would run from your repository with access to secrets, and the exploit could steal them then. Though for the attacker there’s the major downside that their exploit is now part of your repository history…

That applies to on: pull_request. If you use on: pull_request_target instead then there is access to secrets, but the workflow version from the base branch will be used. That means a malicious third-party can’t create a PR that modifies the workflow to leak secrets. If you merge that PR however, then you are at risk just like with on: pull_request.

1 Like

Important catch with that: If the workflow gives secrets to any code from the repository (e.g. a deploy script), an attacker could potentially change that code.

Oh interesting …


This event is similar to pull_request , except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means that you can more safely make your secrets available to the workflows triggered by the pull request, because only workflows defined in the commit on the base repository are run.

That is really good to know.

I wonder though if there is a way to ‘lock down’ .github/workflows so that only certain people (admins?) can change files there.

I would feel a bit more comfortable when changing workflows needed some kind of elevated permission.

I would feel a bit more comfortable when changing workflows needed some kind of elevated permission.

I guess one could write a workflow for exactly this. Check if the changes include workflow changes and then fail a PR if the author is not in a specific allow-list?


For personal access tokens there is a workflow scope, which allows you to update workflows. I suppose you could leave that checkbox unticked?

Not sure if GITHUB_TOKEN could be used by forks somehow to modify workflows, but it is definitely more restrictive for forks in general: