Jm test1 - Is dev any different?

[jeremymoskowitz-netwrix]

Jm test1 - Is dev any different?

The optimal fix is to add an explicit permissions: block restricting GITHUB_TOKEN scopes for the jobs that do not already have one, or at the workflow root to cover all jobs by default. For this workflow, the build job already has permissions: contents: read, but the determine-environment job is missing a permissions block. Since determine-environment only runs shell checks and sets an output, it should receive the absolute minimal permissions, typically contents: read. Optionally, if even read access is not needed, you may set all permissions to none, but contents: read is the standard minimal value. To ensure all future jobs are also limited by default, you may also add a workflow root-level permissions: block, but for this fix, we will add a minimal permissions block just for the flagged job.

Edit .github/workflows/build-and-deploy.yml and add

permissions:
  contents: read

under the determine-environment: job (line 21), e.g., right after runs-on: before outputs:.

General Fix:
Explicitly add a permissions: block to the top-level workflow or to the deploy job specification. The block should be as restrictive as possible, granting only the permissions required for the job (ideally, contents: read as a minimum starting point unless more are needed—none of the workflow’s steps in deploy appear to require even contents: read, so we could safely set it to none).

Best Single Fix:
Add a permissions: contents: read (or, more restrictively, permissions: none) block to the deploy job, just below runs-on: ubuntu-latest and above steps: (i.e. below line 101 and above line 105). This confines the GITHUB_TOKEN scope for this job, aligning it with least-privilege security best practices.

Exact Lines to Change:
Edit .github/workflows/build-and-deploy.yml:
Add the following after line 101 (or after line 104 if we want it at the same level as steps):

    permissions:
      contents: read

Alternatively, use permissions: {} or permissions: none if no permissions are needed (since the job only uses externally provided secrets and not the GITHUB_TOKEN).

---

[bturlea]

the rest of changes seem fine, but wondering why are we changing the workflow in this PR?

[bturlea]

Is this change intended on the build and deploy workflow?
Curious where this change is coming from or whether automatic?