To make the workflow more secure and comply with best practices, add a permissions block to the workflow. Since the ci.yml file mainly calls reusable workflows (via uses:), it's best to set minimal permissions at the workflow level unless specific jobs require more. For CI tasks that do not push or modify repository content, permissions: contents: read is typically sufficient. Place the block near the top of the workflow file (commonly below the name: declaration), and before the on: key. This fix does not change existing functionality and only enhances security posture.

To address the issue, add an explicit permissions: block at the workflow (top) level to ensure the GITHUB_TOKEN only receives the least privilege necessary. Since the jobs are uses-calls to reusable workflows (which may themselves require certain permissions), the most broadly safe minimal permission is contents: read. However, if documentation deployment or registry upload requires writing to the repository (for releases or PRs), you might need to extend permissions (e.g., contents: write). As a starting point—and as per best practices and recommendation—add:

permissions:
  contents: read

above the jobs: block, ideally after the on: block (line 6). This declares globally that all jobs—unless individually overridden—will have only read permission for repository contents. Reusable workflows can request higher permissions if they need them.

The best way to fix the problem is by adding an explicit permissions block, specifying only the least privileges required for the jobs within the workflow (.github/workflows/release.yml). This is typically done at the root of the workflow to cover all jobs, unless a particular job needs broader permissions, in which case job-specific blocks can be used.
For a minimal starting point, permissions: contents: read is usually safe unless jobs need to write data back to the repo or perform other actions (e.g., pull-requests: write). Since the deploy-docs and registry-upload jobs both call reusable workflows, and we don't know their exact needs from the given snippet, we can start with the minimal contents: read and those workflows can further elevate permissions if required.

You should add the following block near the top of the workflow file (directly after the name: and on: keys):

permissions:
  contents: read

No other changes are needed in the visible regions.

To fix this issue, you should explicitly specify a permissions block within the affected job (or at the workflow root if desired). In this workflow, the esp_registry job appears to only need read access to contents for actions/checkout@v4 and uses a third-party action with a provided token for uploading components. Unless the upload action requires additional write permissions (which is uncommon, as it uses a secret), the minimal permissions should be contents: read. This should be added under the job's definition, for esp_registry. The fix is to insert:

permissions:
  contents: read

directly below line 11, so the job block starts with its name, then permissions, then runs-on, etc. No other code needs to change.