Support use of GitHub apps for authentication

[martincostello]

I was looking to extend a GitHub actions workflow that runs scorecard-action to include a GitHub token to scan our repos. I didn't want to use a PAT tied to a person, so instead opted to use a GitHub app installed into our organisation. This allows us to then generate an access token dynamically.

See here for the specific change: justeattakeaway/httpclient-interception@37e56fb

However, I didn't realise until I merged the change that there are workflow restrictions that prevent us from uploading the results as the peter-murray/workflow-application-token-action action isn't in the approved list. Neither is actions/github-script, so we can't manually generate a token with the GitHub API either.

I feel that this is a reasonable use case (and I would argue it's more secure than using a long-lived PAT for a user account), so I propose that one (or both) of the actions are added to the list of supported steps:

scorecard-webapp/app/server/verify_workflow.go

Lines 166 to 170 in 6752fe0

	"actions/checkout",
	"ossf/scorecard-action",
	"actions/upload-artifact",
	"github/codeql-action/upload-sarif",
	"step-security/harden-runner":

GitHub Actions doesn't really support moving secrets between jobs, so I can't generate the token in a separate job and pass it as an input to the job actually running the workflow.

I'm happy to submit a PR to add them if this change would be welcomed.

[spencerschrock]

I was looking to extend a GitHub actions workflow that runs scorecard-action to include a GitHub token to scan our repos. I didn't want to use a PAT tied to a person

Is the default GITHUB_TOKEN available to the workflow insufficient? Branch Protection historically has been one problem with the default token, but for repository which use Repository Rules it's our recommendation over using a PAT. Or is this a rate limit / quota driven suggestion?

(The PR updating the docs hasn't been merged yet, I'll poke some other maintainers on getting that merged.)

[martincostello]

Yes, it was to be able to get the branch protection settings.

I've tried adopting repository rules, but the GitHub UI hasn't allowed me to actually configure things the way I need them in all my branches (I get vague "invalid") errors when saving changes.

I'll try them again shortly in case they've fixed that, but otherwise I wanted to use an app so we don't need to create a "bot" user account (with all the shared password/2FA burden that comes with) just so we can generate a PAT to get the additional permissions - equally, we don't want to have the workflow use a PAT belonging to a real person.

[martincostello]

Yeah, still fails with this when I try to add my existing status checks to the ruleset:

[martincostello]

I reached out to GitHub Support, and turned out the root cause was some unintuitive UI meaning I wasn't setting things up. With the change to repository rules branch protection is indeed now being reported with the default GITHUB_TOKEN.

[spencerschrock]

Note: this discussion came up again after talking to another user trying to do the same thing. I still think repo rules with the default GitHub token is the best outcome for new repos, but adding discussion details here so they're documented.

There is a first party GitHub action that accomplishes token generation (https://github.com/actions/create-github-app-token). So if anything would be added to the allowlist, it would probably be that one.

I feel that this is a reasonable use case (and I would argue it's more secure than using a long-lived PAT for a user account)

The generated token might be short-lived, but the private-key listed as a secret in justeattakeaway/httpclient-interception@37e56fb is just as long-lived.

I didn't want to use a PAT tied to a person, so instead opted to use a GitHub app installed into our organisation

This is a valid point

[martincostello]

Thanks for the information about the first-party action. It seems relatively new, I wonder if it was created after the previously recommended action's author left GitHub.