Tutorial on good practices for GitHub actions (Continuous integration)

[hansvancalster]

I recently was warned about a security issue with one of the actions I used (tj-actions/changed-files). The action got hacked and could potentially retrieve tokens from actions logs.

I learned a few lessons from this which are good to share in a tutorial:

• avoid use of PAT (personal access tokens): GitHub now has short-lived permissions settings which can be used instead
• always use minimal required permissions (i.e. do not give write access if not needed)
• only use external actions from trusted sources (possibly a task for IT to set organisation level allowed/not-allowed actions)
• pinning an action by its version tag is not guaranteed to be safe: a hacker could point it to a different commit; to be safe, pin an action by the full SHA of the commit you want to use

Please leave comments in this thread if you know of other good practices.

[damianooldoni]

Nice idea, @hansvancalster. About short-lived permissions: can you provide a link?
Typically I use standard tokens, but I set always a validity period of 90 days. After that, I will have to generate a new one. Curious to learn better strategy.

[hansvancalster]

See GitHub actions permissions documentation

[damianooldoni]

Thanks @hansvancalster. Interesting. Ok, you refer here to the standard GITHUB_TOKEN then, which indeed should (I would say MUST) be used as standard way of working with actions. However, there are situations where personal tokens are needed and I had those "special" cases in mind.

[hansvancalster]

Can you give an example? I'm thinking about tokens for CODECOV or for ZENODO, like in this workflow, but maybe you have other in mind?

I don't know of a similar solution for those kind of tokens.

[damianooldoni]

My situation is when the output of an action triggers a second action. This is not directly possible of course (risk of infinite loops), so the use of an alter ego account (a so called "bot") is needed. Example:

• An action to fetch raw data is performed daily or it is triggered if new raw data files appear on main. A new branch starting with prefix automatic- is then created and a commit with the "interim" data is pushed. Also a new PR is created. Example: fetch-data.yaml.
• If a commit is pushed to a branch starting with automatic-, a second action is triggered to map the data to DwC and test the output. Example: mapping_and_testing.yaml.

@hansvancalster: this workflow has been already implemented in many repositories to automatize DwC mapping and also by Sander (FIS) for other type of applications. This approach has the advantage to:

• split fetching and mapping
• automatize fetching and mapping
• follow best git practices (work with branches, PRs)

Can this kind of workflow have security issue then? Again, consider the fact that the token we use in the secret ( called WORKFLOWS in the example) has a 90 days validity.

[hansvancalster]

Very nice example! I think your workflow only uses the GITHUB_TOKEN, so you can make it even more secure by removing your 90 day token altogether and use GitHub actions permissions documentation.

So in your workflow, you could try something like this (and remove references to secrets):

permissions:
  contents: write  # Required for committing and pushing changes
  pull-requests: write  # Required for creating and updating pull requests
  actions: read  # Required for reading actions