ci: automate renaming of Snyk PRs to conventional commits (CN-841)

[parker-snyk]

Jira Issue: CN-841

Our linter requires the commit message to be a conventional commit. When merging a PR, the title is used as the git commit message by default.

This change automatically renames PRs starting with [Snyk] (e.g., [Snyk] Update) to follow the conventional commit format (e.g., fix: snyk update). This will make it easier for automated vulnerability fixes to merge in without issue and pass the existing pr-title-check job.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 No relevant tests

🔒 Security concerns Shell injection: Yes. The workflow is vulnerable to shell injection by directly interpolating untrusted input from github.event.pull_request.title into a shell script (line 23). An attacker or even a benign PR with specific characters (like double quotes) could execute arbitrary commands or break the workflow execution.

⚡ Recommended focus areas for review Potential Shell Injection 🟠 [major] Directly interpolating github.event.pull_request.title into a shell script using ${{ ... }} is a security risk. If a PR title contains shell metacharacters such as double quotes, backticks, or $(...), it can lead to command injection or cause the script to fail. For example, a title like [Snyk] Update "package"; whoami would result in the execution of the whoami command. To mitigate this, assign the title to an environment variable and reference that variable within the script. PR_TITLE="${{ github.event.pull_request.title }}" Workflow Logic Error 🟠 [major] The current logic will likely leave the PR with a failing status check that does not automatically recover. First, the Check PR Title step (line 29) uses the github context, which is a static snapshot taken at the start of the run; it will still see the old [Snyk] title and fail. Second, actions performed using the default GITHUB_TOKEN do not trigger new workflow runs. Consequently, the edited event resulting from the gh pr edit command will not trigger a fresh run to validate the new title. The PR will remain in a failed state until a user manually re-runs the CI or pushes a new commit. gh pr edit ${{ github.event.pull_request.number }} --title "$NEW_TITLE" --repo ${{ github.repository }} Aggressive Transformation 🟡 [minor] The tr '[:upper:]' '[:lower:]' command lowercases the entire PR title. This is destructive as it removes intentional casing in dependency names, acronyms, or vulnerability identifiers (e.g., [Snyk] Fix CVE-2024-1234 becomes fix: snyk fix cve-2024-1234). Consider using a more targeted sed command that only replaces the prefix while preserving the rest of the title's casing. NEW_TITLE=$(echo "$PR_TITLE" | tr '[:upper:]' '[:lower:]' | sed 's/^\[snyk\]/fix: snyk/')

[bgardiner]

This means the rest of the semantic PR checking will never happen for '[Snyk]' ... PRs, right? Will something else catch if the stuff after the [Snyk] violates conventional commit spec? Or does it not matter for some reason?

As an aside... have we asked in prod-sec or posted in #snyk-on-snyk-dogfooding if there is a way to change or configure the format of Snyk PRs?