Enhance release workflow security for pull request triggers

[Copilot]

The release.yml workflow was triggered on pull_request events with high-privilege permissions (contents: write, pull-requests: write) and access to ADYEN_AUTOMATION_BOT_ACCESS_TOKEN. While a conditional check prevented fork PRs, this pattern creates unnecessary risk if the check were misconfigured or bypassed.

Changes

• Enhanced conditional check - Workflow now only runs when PRs are successfully merged (not just closed) by adding github.event.pull_request.merged == true condition
• Removed pull-requests: write permission - Reduced permission scope to minimize security risk
• Retained pull_request trigger - Kept PR trigger with stricter security controls for automated releases on merge
• Added explanatory comment - Documented the conditional logic: "Run on manual dispatch OR when PR is merged from same repository"

jobs:
  release:
+   # Run on manual dispatch OR when PR is merged from same repository
-   if: ${{ github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository }}
+   if: ${{ github.event_name != 'pull_request' || (github.event.pull_request.merged == true && github.event.pull_request.head.repo.full_name == github.repository) }}
    permissions:
      contents: write
-     pull-requests: write

Security Improvements

• ✅ Workflow only triggers on successfully merged PRs from the base repository (not on closed-without-merge)
• ✅ Reduced permission scope by removing pull-requests: write
• ✅ Maintains protection against fork PRs
• ✅ contents: write permission is retained as it's required for the release-automation-action to commit version updates and create tags

This approach maintains automated release functionality while significantly reducing the attack surface through stricter conditional checks and minimal permissions.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Bug]: High-Privilege Token in Pull Request Trigger</issue_title>
<issue_description>## Description

High-Privilege Token in Pull Request Trigger

Overview

We have recently conducted a security scan of our GitHub repositories to ensure our CI/CD pipelines are secure. We identified misconfigurations in GitHub Actions workflows (e.g., injection risks, unpinned actions).

File: .github/workflows/release.yml

Description

The 'release.yml' workflow is triggered on 'pull_request' events and uses a high-privilege secret ADYEN_AUTOMATION_BOT_ACCESS_TOKEN with 'contents: write' and 'pull-requests: write' permissions. While there is a crucial check to ensure this only runs for pull requests from the base repository, this pattern is inherently dangerous. If the conditional check were to fail or be misconfigured, a malicious pull request could trigger the release action and potentially modify the repository's contents.

Remediation

Avoid using high-privilege tokens in workflows triggered by 'pull_request'. It is safer to have release-related workflows be exclusively manually triggered (using 'workflow_dispatch') by trusted users. If PR-based triggers are necessary, ensure the token's permissions are strictly limited to the minimum required, such as posting comments, rather than writing to the repository content.
</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [Bug]: High-Privilege Token in Pull Request Trigger #400

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[gcatanese]

@copilot I don't like the approach: revert all changes and implement the following:

[Copilot]

@copilot I don't like the approach: revert all changes and implement the following:

Could you please clarify what approach you'd like me to implement? The comment mentions "implement the following:" but doesn't specify the alternative solution.

Should I keep the pull_request trigger but implement a different security approach, or did you have a specific implementation in mind?

[gcatanese]

@copilot I don't like the approach: revert all changes and implement the following:

1. strictly run only when a PR is successfully MERGED
2. remove pull-requests: write
   I have also a question, can contents permissions be set to read?

[Copilot]

@copilot I don't like the approach: revert all changes and implement the following:

1. strictly run only when a PR is successfully MERGED...

Implemented in commit 21215c4:

1. ✅ Only runs when PR is successfully merged: Added github.event.pull_request.merged == true check
2. ✅ Removed pull-requests: write permission

Regarding contents: read - The contents: write permission is required because the release-automation-action needs to:

• Commit version file updates (setup.py, Adyen/settings.py)
• Create git tags for releases
• Push changes back to the repository

Setting it to read would prevent the release automation from functioning. The action inherently needs write access to prepare and publish releases.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/Adyen/release-automation-action/readme
  • Triggering command: /usr/bin/curl curl -s REDACTED (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gcatanese]

Superseded by #404