In general, the fix is to add an explicit permissions block that restricts the GITHUB_TOKEN to the minimum required scope. Since this workflow only checks out code and runs .NET tests, it needs only read access to repository contents (or possibly no token at all, but contents: read is the common secure baseline).

The best minimal fix without changing functionality is to add a top-level permissions block so it applies to all jobs (unit-test and integration-test). Place it after name: Build .NET and before the on: block to make the configuration clear and conventional. Set contents: read as recommended by CodeQL. No additional methods, imports, or definitions are needed in YAML; we only add that block.

Concretely, in .github/workflows/_build-dotnet.yml, insert:

permissions:
  contents: read

between line 5 (name: Build .NET) and line 7 (on:). This ensures both jobs run with a read-only GITHUB_TOKEN and resolves the CodeQL warning.

In general, the fix is to explicitly specify a permissions block in the workflow (either at the root so it applies to all jobs, or per-job) that grants only what is needed. This workflow appears to only need to read repository contents (for actions/checkout) and does not interact with issues, PRs, or other write APIs, so contents: read is sufficient.

The best minimal change is to add a root-level permissions block under the name (and before on:) so it applies to both unit-test and integration-test jobs. The block should set contents: read to match CodeQL’s suggested minimal starting point. No other scopes (like pull-requests or issues) are required by any shown step. No imports or other code changes are necessary since this is a YAML workflow-only change.

Concretely, edit .github/workflows/_build-dotnet.yml and insert:

permissions:
  contents: read

between the name: Build .NET line and the on: block. This will limit the GITHUB_TOKEN for all jobs in this workflow without changing existing functionality.

In general, the fix is to explicitly declare a permissions: block to restrict the default GITHUB_TOKEN permissions for this workflow/job to the minimum required. Since this workflow only checks out code and runs local Go tooling, it likely needs at most read access to repository contents, and no write permissions.

The best fix with minimal behavioural change is to add a top-level permissions: block (so it applies to all jobs in this workflow) setting contents: read. This aligns with the CodeQL recommendation and the principle of least privilege. Concretely, in .github/workflows/_build-go.yml, insert a new block after the name: Build Go line:

permissions:
  contents: read

No other changes, imports, or definitions are required, and the existing steps (checkout, Go setup, builds, tests, CodeQL CLI install) will continue to work as before.

In general, the fix is to explicitly define a minimal permissions: block so that the GITHUB_TOKEN used in this workflow is limited to the least privileges necessary. This can be done either at the workflow root (applies to all jobs) or under the specific job. Since this workflow currently has a single job, both approaches are equivalent in effect; defining it at the root is clearer and scales better if more jobs are added later.

The single best fix here is to add a root‑level permissions: block just after the on: configuration and before jobs:. The job uses actions/checkout, which requires contents: read to fetch the repository. None of the steps writes to the repo or interacts with pull requests/issues, so contents: read is sufficient. No imports or extra definitions are needed because this is YAML configuration only. Specifically, edit .github/workflows/_build-java.yml to insert:

permissions:
  contents: read

between the on: block (lines 7–34) and the jobs: block (line 35). This constrains the GITHUB_TOKEN to read‑only contents while preserving all existing functionality.