`softprops/action-gh-release@v2` dependency within the workflow

[leighmcculloch]

In the release workflow there's a third-party dependency softprops/action-gh-release that presents a couple concerns from a security hardening perspective:

soroban-build-workflow/.github/workflows/release.yml

Lines 108 to 116 in 8764eba

	- name: Create release
	uses: softprops/action-gh-release@v2
	with:
	tag_name: ${{ env.TAG_NAME }}
	draft: false
	prerelease: false
	body: ${{ inputs.release_description }}
	files: '${{ env.BUILD_DIR_PATH }}/compilation_workflow_release/${{ env.WASM_FILE_NAME }}'
	token: ${{ secrets.release_token }}

1️⃣ – not pinned

The action is referenced with a mutable reference v2 rather than an immutable commit-sha.

Pinning to commit-sha's is a security best practices in GitHub Actions and the only way to make the reference immutable:

Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository

Ref: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions

2️⃣ – unnecessary permissions

The third party action is given the secrets.release_token that users of the workflow are encouraged to have given three permissions:

soroban-build-workflow/README.md

Lines 39 to 42 in 8764eba

	permissions: # required permissions for the workflow
	id-token: write
	contents: write
	attestations: write

The third party action does not need the attestation or id-token permissions.

Permissions cannot be controlled per step, but they can be controlled per job. A common way to separate the action into a different job is to have the first job upload an artifact, and a second job download that artifact. The second job can have a token with a narrower set of permissions.