31341 - Initial commit for pay-report - Streamlit (#2199)

[seeker25]

Issue #:
bcgov/entity#31341

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the sbc-pay license (Apache 2.0).

In general, to fix this class of issue, you explicitly declare a permissions block either at the root of the workflow (applying to all jobs without their own permissions) or on individual jobs. This constrains the GITHUB_TOKEN to the least privileges needed, instead of relying on potentially broad repository defaults.

For this specific workflow, the single best fix with minimal behavioral impact is to add a conservative permissions block at the top level, after the on: block and before jobs:. A common minimal baseline recommended by GitHub is contents: read, which allows read access to repository contents while preventing unintended write operations. The reusable workflow you call can still specify additional or different permissions inside its own definition if needed; your workflow’s top-level block just ensures you are not accidentally inheriting over-permissive defaults.

Concretely, in .github/workflows/pay-report-cd.yml, add:

permissions:
  contents: read

on new lines between the existing on: section (ending at line 26) and the jobs: section (line 27). No imports or additional definitions are required, as this is standard GitHub Actions YAML configuration.

---

In general, the fix is to explicitly declare the permissions: for the workflow or per job so that the GITHUB_TOKEN has only the minimal scopes required. This workflow only needs to read repository contents to check out code and run CI; it does not need to write to the repo or modify issues/PRs. Thus, contents: read is sufficient.

The best way to fix this without changing existing behavior is to add a single permissions: block at the root of the workflow (top level, alongside name, on, defaults, and jobs). This root-level block will apply to all jobs (setup-job, linting, testing, build-check) because none of them currently define their own permissions. Concretely, in .github/workflows/pay-report-ci.yml, insert:

permissions:
  contents: read

after the on: section (e.g., after line 10) or anywhere at the root level before jobs:. No imports or additional methods are needed, since this is a YAML configuration change only.

In general, this issue is fixed by explicitly declaring a permissions block for the workflow or for each job, restricting the GITHUB_TOKEN to the minimal scopes needed. For this CI workflow, all jobs only check out code and run local commands, so they only require contents: read. No job appears to need write access to issues, pull requests, or repository contents.

The best fix with no functional change is to add a single top‑level permissions block right after the name: line (before on:). This will apply to all jobs (setup-job, linting, testing, build-check) since none of them define their own permissions. The block should set contents: read so actions/checkout@v4 can function, while avoiding any unnecessary write permissions. No additional imports, methods, or other definitions are needed because this is a YAML configuration change only.

Concretely, in .github/workflows/pay-report-ci.yml, insert:

permissions:
  contents: read

between line 1 (name: PAY REPORT CI) and line 3 (on:).

To fix the problem, explicitly set a restrictive permissions: block so that the GITHUB_TOKEN used in this workflow has only the minimal required scopes. Since all jobs just check out code and run local commands, they only need read access to repository contents, so contents: read is sufficient.

The best way to do this without changing functionality is to add a top‑level permissions: block (at the same indentation level as on: and defaults:). This will apply to all jobs that do not define their own permissions. You do not need to modify individual jobs, because none of them need write permissions or special scopes like pull-requests: write, issues: write, etc.

Concretely:

• In .github/workflows/pay-report-ci.yml, add:

permissions:
  contents: read

between the on: section and the defaults: block (for example, after line 10). No imports, methods, or additional definitions are required, as this is pure workflow configuration.

In general, the fix is to explicitly define permissions for the GITHUB_TOKEN in this workflow, limiting it to the minimal scope required. Since all three jobs (setup-job, linting, testing, and build-check) only need to read the repository contents (via actions/checkout) and do not perform any write operations to GitHub resources, we can safely set contents: read. The best way, without changing existing functionality, is to add a top-level permissions block so that all jobs inherit it, rather than repeating it on each job.

Concretely, in .github/workflows/pay-report-ci.yml, add:

permissions:
  contents: read

near the top of the file (after name: and before on: or immediately after on:), ensuring the indentation matches YAML requirements. No additional imports, methods, or definitions are needed; this is purely a YAML configuration change within the workflow file.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
9442085	Triggered	Generic Password	e98be60	.github/workflows/pay-report-ci.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}