Does github script access secrets.GITHUB_TOKEN?

Question

I am using the github marketplace action 'github-script'. The code for which can be seen here. In particular I am using it to create a tag in my repo as described here. I suspect behind the scenes it is accessing secrets.GITHUB_TOKEN or something equivalent because as far as I know this is required to interact with the API. First, I'd like to know if this is in fact the case.

Second, I created a custom action within my organization which creates a tag, thereby bypassing the need for github-script in this particular case. For this custom action to work, I need to pass it secrets.GITHUB_TOKEN like so:

name: create tag
steps:
  - id: create-tag
    uses: my-org/customTaggingAction@v1.0.0
    with:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

I'd like to know if this is a security concern, and to what extent using 'github-script' is more or less secure in terms of passing around the GITHUB_TOKEN.

Answer 1

The action actions/github-script defines ${{ github.token }}, which is the same as ${{ secrets.GITHUB_TOKEN }}, as the default input for github-token:

# action.yml

inputs:
  # ..
  github-token:
    description: The GitHub token used to create an authenticated client
    default: ${{ github.token }}
    required: false
  # ..

---

In terms of security, you probably want to prefer an action that is maintained by GitHub rather than implementing one on your own as a general rule. GitHub will make sure their code follows best practices both in terms of passing around secrets, but also keeping the dependencies updated etc.

If you're curious about the difference between passing the token as an input an defining it as as environment variable like you did in your example, you need to know that inputs are passed to actions via environment variables; If you pass an input github-token to an action, then GitHub will actually define an environment variable INPUT_github-token and pass that to the action.

Lastly, it is good practice to limit the permissions of the token. This can be achieved by adding a small block of YAML to the top of your workflow, like so:

permissions:
  contents: read

By giving the token only read access to contents, you're basically only allowing it to read contents of your repository. This is what's needed to clone the repository, but an attacker wouldn't be able to e.g. read the issues from your repository.

If you're not sure what permissions you need to set, I recommend first giving it no permissions at all

permissions: {}

and then see where it fails and only give it access to that specific thing.