Tracking pull request to merge release-0.5.0 to main

[kuanfandevops]

No description provided.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

To fix the problem, you should add a permissions block to the workflow YAML file. The best practice is to add it at the top level of the workflow, so it applies to all jobs unless overridden. The minimal starting point is to set contents: read, which allows jobs to read repository contents but not write. If any job requires additional permissions (such as writing to issues or pull requests), you can add those as needed. In this case, based on the provided jobs, it appears that only read access to repository contents is required, so contents: read is sufficient. The change should be made near the top of the file, after the name: and before the on: block.

To fix the problem, add a permissions block to the workflow file. The most secure approach is to set the permissions at the workflow level (top-level), which applies to all jobs unless overridden. Since the jobs in this workflow do not appear to require any write access to the repository (no steps push code, create PRs, etc.—the only commented-out section that would require write access is currently disabled), the minimal permission required is contents: read. This will ensure the GITHUB_TOKEN can only read repository contents, not write or perform other privileged actions. The permissions block should be added after the name field and before on:.

---

To fix the problem, add a permissions block to the workflow YAML file. The block should be placed at the top level (before jobs:) to apply to all jobs, unless a job needs more specific permissions. Since the workflow only checks out code and does not push changes (the push step is commented out), the minimal required permission is contents: read. If in the future the commented-out git push step is enabled, you may need to add contents: write or pull-requests: write, but for now, contents: read is sufficient. The change should be made near the top of the file, after the name: and before on:.

In general, the fix is to add an explicit permissions block that limits the GITHUB_TOKEN to the least privileges required. Since this workflow only interacts with Artifactory and Docker Hub using secrets and does not modify the repository, it does not need any write-level GitHub permissions and probably does not even need read access beyond the default minimal scopes. A conservative and clear configuration is to set contents: read at the top level of the workflow, which will apply to the single job.

Concretely, in .github/workflows/push-dependencies-to-artifactory.yaml, add a permissions section near the top of the file (for example, after name: and before on:). Set it to contents: read, which is a common minimal baseline allowing the workflow to read repository contents if ever needed, while avoiding write permissions. No other code, steps, imports, or secrets handling need to change, and existing functionality will stay the same except for reduced token capabilities.