Add token permissions for code-scanning/trivy.yml

[Devils-Knight]

This PR adds token permissions for code-scanning/trivy.yml. The permissions were added using https://app.stepsecurity.io/.

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • organization: Name of the organization producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.

[nickfyson]

Hi, thanks for the PR!

Could you explain what you're aiming for with these changes? It seems that the top-level permissions statement is superfluous given the more specific statement applied to the build job...?

[varunsh-coder]

Hi @nickfyson, @knqyf263 these changes are part of #1299. @Devils-Knight and others from StepSecurity are fixing token permissions across the starter workflow templates, so they are secure by default. We have also setup a website https://app.stepsecurity.io that developers can use to set token permissions for their workflows.

@nickfyson to answer your question, ossf/scorecards recommends adding workflow level permissions, so that if developers add a new job to the workflow, it inherits the read-all permissions, and is secure-by-default.

@knqyf263 to answer your question, if job level permissions are granted, then any permission not specified is not granted to the job. So, if contents: read is removed, the build job will not have contents-read permission.

CC: @laurentsimon

[nickfyson]

Ah, thanks for the context. 🙂

How come read-all though? Would it be even better to just give read to contents by default and nothing else?

[varunsh-coder]

@nickfyson yes, we got that feedback from multiple developers, and have updated the logic on https://app.stepsecurity.io/. This PR was created before that change though. @Devils-Knight can you please update this PR so that the workflow level permissions are set to contents: read?

[Devils-Knight]

@varunsh-coder Thanks for explaining the changes 😇. Have updated the workflow level permission as requested by you please check it out.

[varunsh-coder]

@varunsh-coder Thanks for explaining the changes 😇. Have updated the workflow level permission as requested by you please check it out.

LGTM

[knqyf263]

Hi, I'm a maintainer of Trivy. I'd like to know why this line is needed. Looks like read-all is granted in the top-level permissions.

[laurentsimon]

Good question. If you define permissions in the job, those you do not specify default to none, not to the ones defined at the top level. The top level permissions only serve as a fail-safe mechanism if a developer ever adds a new job and forget to set permissions explicitly... this happens :-)
See the doc in https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions If you specify the access for any of these scopes, all of those that are not specified are set to none

It was confusing to me a first as well.

[nickfyson]

Given the additional explanation I'm happy with these changes, and can appreciate the value of setting the global permissions also.

@knqyf263 As one of the tool maintainers, are you happy with these changes? If so I shall 🙂

[knqyf263]