fix: [FL-29536] add explicit permissions to jira-sync workflow

[josue]

Description

Adds an explicit permissions block to the jira-sync.yml workflow, restricting the GITHUB_TOKEN to contents: read. This resolves CodeQL alert #4 (CWE-275: missing workflow permissions).

Motivation and Context

Without explicit permissions, the workflow inherits repository/org defaults which may be broader than necessary. The reusable workflow only reads PR event payload data and makes JIRA API calls using repository secrets — it needs no write access to the repo.

Jira ticket: FL-29536

How Has This Been Tested?

• Verified the reusable workflow at flume/github-actions/.github/workflows/jira-sync.yml — it only reads context.payload.pull_request (from the event, not the API) and makes external JIRA REST calls using secrets
• No GitHub API write operations are performed with the GITHUB_TOKEN

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the code style of this project.
• All new and existing tests passed.

🤖 Generated with Claude Code

[flume-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[Copilot]

Pull request overview

Adds an explicit permissions block to the jira-sync.yml GitHub Actions workflow to restrict the default GITHUB_TOKEN scope, addressing the linked CodeQL alert about missing workflow permissions.

Changes:

• Add top-level permissions: configuration.
• Restrict GITHUB_TOKEN permissions to contents: read for the JIRA sync workflow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[josue]

Adversarial Review — PR #99: Add explicit workflow permissions

Reviewer: Claude Opus (Gemini 2.5 Pro unavailable — 429 rate limit)

Primary fix is correct. The permissions: contents: read block is the minimal required scope — the reusable workflow only reads PR event payload data via context.payload (no GitHub API calls) and makes external JIRA REST calls using repository secrets. No injection risks found.

New Findings: 2 (pre-existing, in diff context)

Severity	Finding	File
MEDIUM	Mutable @main ref for reusable workflow — supply chain risk	jira-sync.yml:17
LOW	secrets: inherit passes all repo secrets, not just the 2 needed	jira-sync.yml:18

Note: Both findings are pre-existing (not introduced by this PR) but are visible in the diff context and worth addressing in a follow-up for SOC 2 / HITRUST supply chain integrity.

Source: Claude Opus adversarial review