Ci cd security changes

[svivesaero]

dependabot updates scans npm dependencies across all packages

To fix this issue, add an explicit permissions block at the root level of .github/workflows/dev-workflow.yml to enforce minimal permissions for the workflow. The minimal sensible base is contents: read, which allows jobs to fetch code but not push changes. If any job needs more, override with a job-level permissions block. Place the following at the root (anywhere above the jobs: block is valid, typically best after name: and before on:).

No changes are needed in the jobs unless some require more permissions. As a minimal fix, only the root-level permissions block will be added.

---

To fix the problem, we should add a permissions: block at the workflow root to restrict GITHUB_TOKEN permissions as tightly as possible. This block governs all jobs unless overridden job-specifically. The "least privilege" baseline is usually contents: read (unless you need extra write capabilities, which should be scoped tightly, e.g., for version bumping or PR merging).

Since this workflow appears to primarily build and upload artifacts rather than modify repository contents directly, contents: read will likely suffice for most jobs. If a referenced composite workflow requires additional permissions (such as writing to the contents or pull-requests), you may need to expand the set accordingly. But for a minimal improvement—and as recommended in the error message—you should insert permissions: at the root above the jobs: block.

To implement the change, add the following lines just above the jobs: block in .github/workflows/dev-workflow.yml:

permissions:
  contents: read

If features like version bumping or PR merging need write permissions, adjust accordingly (e.g., add contents: write, pull-requests: write). But the “minimal starting point” remains contents: read.

---

To address the issue, add a permissions block to the workflow file (ideally at the root, affecting all jobs unless otherwise specified) and set the minimal permissions required for these jobs, following least privilege principles. Since the jobs mainly run other workflows, the minimal safe default is contents: read, unless any workflow specifically requires greater permissions (such as publishing, modifying releases, or creating pull requests/issues). If such needs arise, you can incrementally grant just those permissions on jobs that require them. For the general case, permissions: contents: read suffices. Place the block directly under the name: line or just before on:.

---

The fix involves explicitly adding a permissions block to the workflow YAML to limit the default token permissions. This can be done most efficiently at the root of the workflow (near the top), ensuring that all jobs inherit the same least-privilege policy unless otherwise overridden at the job level. Since the top-level workflow only orchestrates jobs from other composed workflows (and does not run scripts itself), contents: read is usually sufficient unless a sub-workflow requires extra rights. If any of the called workflows (which we can't see here) require e.g., pull-requests: write or some other scope, those permissions should be fine-tuned; otherwise, start with the minimal contents: read.

Edit:
Insert the following block right after the name: line and before the on: block in .github/workflows/stage-workflow.yml:

permissions:
  contents: read

---

To fix the issue, you should add an explicit permissions block near the top level of the workflow file, right after the name and before or after the on: block. Setting it at the top level ensures that all jobs, unless they override, inherit these minimized permissions. The minimal starting point is to use contents: read, which is the most common minimum; if further privileges are required for particular jobs, those can be set only in those jobs. In this specific code, since no evident job or workflow step requires write access by default, setting:

permissions:
  contents: read

ensures that the workflow GITHUB_TOKEN has only read access to repository contents, which is very limited and safe.

Edit the workflow file .github/workflows/stage-workflow.yml, and insert the permissions: block after the name line (typically best placed immediately before or after the on: block).

---