[DSD-4199]

[JanardhanBS-SyncByte]

No description provided.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (1)

• develop

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Generally, the fix is to explicitly define a permissions block that scopes the GITHUB_TOKEN to the minimum needed. This can be done at the workflow root (applies to all jobs without their own permissions) or per job. Since this workflow has a single job that calls a reusable workflow which likely needs to read repository contents and possibly write to gh-pages and read workflow metadata, we should set only those permissions that are clearly required.

Without modifying the functionality, we should:

• Add a root‑level permissions block after the on: section (lines 3–42).
• Grant contents: write to allow publishing Helm charts (push to gh-pages), and id-token: write only if needed for OIDC (we will omit it since there is no indication it’s used).
• Optionally grant actions: read if the reusable workflow needs to query workflow runs; since we do not see such usage here, we’ll keep it minimal.

Concretely, in .github/workflows/chart-lint-publish.yml, insert:

permissions:
  contents: write

between the on: block (ending at line 42) and the jobs: block (line 44). This limits GITHUB_TOKEN to repository contents write access only, which is the minimum obviously required for linting/publishing charts.

In general, to fix this issue you should explicitly declare a permissions: block either at the workflow root (to cover all jobs) or on individual jobs, granting only the scopes they actually need. For typical Maven build, publish, and Sonar analysis workflows that don’t push code or manage releases, this can usually be limited to read access on contents and, if needed, checks or statuses write access for reporting.

The single best, least‑intrusive fix here is to add a workflow‑level permissions block right after the name: (and before on:) so that all jobs, including sonar_analysis_mock_abis, run with a restricted GITHUB_TOKEN. Because these jobs mainly build, publish to external Nexus/Sonar using explicit secrets, and don’t appear to push code or releases back into GitHub, we can safely set contents: read as a minimal default. If you know that any called reusable workflow needs to update commit statuses or checks, you could additionally allow checks: write or statuses: write, but since that’s not visible in this snippet, we’ll keep the change minimal and read‑only.

Concretely, in .github/workflows/push-trigger.yml, insert:

permissions:
  contents: read

right after line 1 (name: Maven Package upon a push) and before the on: section. No imports or other code changes are needed; this is pure workflow configuration.

Generally, to fix this issue you should add a permissions: block that explicitly scopes the GITHUB_TOKEN to the minimum rights needed, either at the workflow root (applies to all jobs) or individually per job. The safest and simplest approach here—without altering existing behavior—is to add a root-level permissions: with read-only access to repository contents, which is sufficient for typical build/test/analysis jobs that use external secrets for writes to third-party services.

Concretely, in .github/workflows/push-trigger.yml, just below the name: Maven Package upon a push line and before the on: block, add:

permissions:
  contents: read

This sets the default for all jobs, including sonar_analysis_mock_mv and the other reusable-workflow jobs. Since none of the shown jobs obviously require write access to the repository itself (publishing and notifications are handled via OSSRH_*, SONAR_TOKEN, SLACK_WEBHOOK_URL, etc.), this should not break existing functionality while satisfying the CodeQL rule and enforcing least privilege.

To fix this, we should explicitly scope down the GITHUB_TOKEN permissions for the workflow. The simplest and safest approach is to add a root-level permissions: block (just under the name: or on: section) so all jobs, including sonar_analysis_mock_mds, inherit minimal permissions unless overridden. Since the shown jobs call Maven build/publish and Sonar analysis via reusable workflows and do not need repository write access, we can set permissions: contents: read as a conservative default that allows checking out code but not pushing or modifying repository resources. If later some job needs more, it can override permissions locally.

Concretely, in .github/workflows/push-trigger.yml, add:

permissions:
  contents: read

near the top of the file, at the workflow level. No additional imports or definitions are required. This single change will satisfy CodeQL’s requirement that the workflow limit GITHUB_TOKEN permissions and will apply to all jobs that don’t define their own permissions, including the one CodeQL flagged.