[
https://issues.apache.org/jira/browse/AVRO-4315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlo Geenen updated AVRO-4315:
-------------------------------
Description:
h3. Problem
The OpenSSF Scorecard "Token-Permissions" check currently reports a score
of 0 for this repository because none of the GitHub Actions workflows in
.github/workflows/ declare an explicit top-level `permissions:` block.
Without an explicit `permissions:` block, the GITHUB_TOKEN used by a workflow
run falls back to the repository's default token permissions. This violates the
principle of least privilege. A live workflow run confirms the actual token
currently has broad write access across nearly every scope, and therefore
represents a real risk of a supply-chain attack if a workflow is ever
compromised (e.g. via a malicious pull request or a compromised third-party
Action).
See also the Github runners logging:
[https://github.com/apache/avro/actions/runs/29937054675/job/88981207925]
{noformat}
GITHUB_TOKEN Permissions
Actions: write
ArtifactMetadata: write
Attestations: write
Checks: write
CodeQuality: write
Contents: write
CopilotRequests: write
Deployments: write
Discussions: write
Drives: write
Issues: write
Metadata: read
Models: read
Packages: write
Pages: write
PullRequests: write
RepositoryProjects: write
SecurityEvents: write
Statuses: write
VulnerabilityAlerts: read {noformat}
h3. Affected files
All workflow files under .github/workflows/ currently lack a top-level
`permissions:` block, including:
- codeql-csharp-analysis.yml
- codeql-java-analysis.yml
- codeql-js-analysis.yml
- codeql-py-analysis.yml
- deploy-docs.yml
- java-publish-snapshot.yml
- labeler.yml (has a job-level `contents: read`, but no top-level block)
- maven4.yml
- rat.yml
- spotless.yml
- test-docker.yml
- test-lang-c++.yml
- test-lang-c.yml
- test-lang-csharp.yml
- test-lang-java.yml
- test-lang-js.yml
- test-lang-perl.yml
- test-lang-php.yml
- test-lang-py.yml
- test-lang-ruby.yml
h3. Proposed fix
1. Add a restrictive top-level permissions block to every workflow, e.g.:
permissions:
contents: read
or `permissions: {}` for workflows that don't need repository access
at all.
2. For jobs that genuinely need elevated permissions (e.g. deploy-docs.yml
writing to GitHub Pages, labeler.yml writing PR labels), scope those
extra permissions at the job level only, following least privilege.
3. This can optionally be automated/verified using StepSecurity's
"Secure Workflow" tool, which is already referenced in the Scorecard
output:
[https://app.stepsecurity.io/secureworkflow/apache/avro/]<workflow-file>/main?enable=pin
h3. References
- OpenSSF Scorecard Token-Permissions check:
[https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions]
- Current Scorecard result: score 0 (high severity)
- GitHub docs on controlling GITHUB_TOKEN permissions:
[https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token]
was:
h3. Problem
The OpenSSF Scorecard "Token-Permissions" check currently reports a score
of 0 for this repository because none of the GitHub Actions workflows in
.github/workflows/ declare an explicit top-level `permissions:` block.
Without an explicit `permissions:` block, the GITHUB_TOKEN used by a workflow
run falls back to the repository's default token permissions. This violates the
principle of least
privilege. A live workflow run confirms the actual token currently has broad
write access across nearly every scope, and therefore represents a real risk of
a supply-chain attack if a workflow is ever compromised (e.g. via a malicious
pull request or a compromised third-party Action).
See also the Github runners logging:
[https://github.com/apache/avro/actions/runs/29937054675/job/88981207925]
{noformat}
GITHUB_TOKEN Permissions
Actions: write
ArtifactMetadata: write
Attestations: write
Checks: write
CodeQuality: write
Contents: write
CopilotRequests: write
Deployments: write
Discussions: write
Drives: write
Issues: write
Metadata: read
Models: read
Packages: write
Pages: write
PullRequests: write
RepositoryProjects: write
SecurityEvents: write
Statuses: write
VulnerabilityAlerts: read {noformat}
h3. Affected files
All workflow files under .github/workflows/ currently lack a top-level
`permissions:` block, including:
- codeql-csharp-analysis.yml
- codeql-java-analysis.yml
- codeql-js-analysis.yml
- codeql-py-analysis.yml
- deploy-docs.yml
- java-publish-snapshot.yml
- labeler.yml (has a job-level `contents: read`, but no top-level block)
- maven4.yml
- rat.yml
- spotless.yml
- test-docker.yml
- test-lang-c++.yml
- test-lang-c.yml
- test-lang-csharp.yml
- test-lang-java.yml
- test-lang-js.yml
- test-lang-perl.yml
- test-lang-php.yml
- test-lang-py.yml
- test-lang-ruby.yml
h3. Proposed fix
1. Add a restrictive top-level permissions block to every workflow, e.g.:
permissions:
contents: read
or `permissions: {}` for workflows that don't need repository access
at all.
2. For jobs that genuinely need elevated permissions (e.g. deploy-docs.yml
writing to GitHub Pages, labeler.yml writing PR labels), scope those
extra permissions at the job level only, following least privilege.
3. This can optionally be automated/verified using StepSecurity's
"Secure Workflow" tool, which is already referenced in the Scorecard
output:
https://app.stepsecurity.io/secureworkflow/apache/avro/<workflow-file>/main?enable=pin
h3. References
- OpenSSF Scorecard Token-Permissions check:
[https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions]
- Current Scorecard result: score 0 (high severity)
- GitHub docs on controlling GITHUB_TOKEN permissions:
[https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token]
> Add explicit GITHUB_TOKEN permissions to GitHub Actions workflows (OpenSSF
> Scorecard: Token-Permissions)
> --------------------------------------------------------------------------------------------------------
>
> Key: AVRO-4315
> URL: https://issues.apache.org/jira/browse/AVRO-4315
> Project: Apache Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.12.1
> Reporter: Carlo Geenen
> Priority: Major
> Fix For: 1.12.2
>
>
> h3. Problem
> The OpenSSF Scorecard "Token-Permissions" check currently reports a score
> of 0 for this repository because none of the GitHub Actions workflows in
> .github/workflows/ declare an explicit top-level `permissions:` block.
> Without an explicit `permissions:` block, the GITHUB_TOKEN used by a workflow
> run falls back to the repository's default token permissions. This violates
> the principle of least privilege. A live workflow run confirms the actual
> token currently has broad write access across nearly every scope, and
> therefore represents a real risk of a supply-chain attack if a workflow is
> ever compromised (e.g. via a malicious pull request or a compromised
> third-party Action).
> See also the Github runners logging:
> [https://github.com/apache/avro/actions/runs/29937054675/job/88981207925]
> {noformat}
> GITHUB_TOKEN Permissions
> Actions: write
> ArtifactMetadata: write
> Attestations: write
> Checks: write
> CodeQuality: write
> Contents: write
> CopilotRequests: write
> Deployments: write
> Discussions: write
> Drives: write
> Issues: write
> Metadata: read
> Models: read
> Packages: write
> Pages: write
> PullRequests: write
> RepositoryProjects: write
> SecurityEvents: write
> Statuses: write
> VulnerabilityAlerts: read {noformat}
> h3. Affected files
> All workflow files under .github/workflows/ currently lack a top-level
> `permissions:` block, including:
> - codeql-csharp-analysis.yml
> - codeql-java-analysis.yml
> - codeql-js-analysis.yml
> - codeql-py-analysis.yml
> - deploy-docs.yml
> - java-publish-snapshot.yml
> - labeler.yml (has a job-level `contents: read`, but no top-level block)
> - maven4.yml
> - rat.yml
> - spotless.yml
> - test-docker.yml
> - test-lang-c++.yml
> - test-lang-c.yml
> - test-lang-csharp.yml
> - test-lang-java.yml
> - test-lang-js.yml
> - test-lang-perl.yml
> - test-lang-php.yml
> - test-lang-py.yml
> - test-lang-ruby.yml
> h3. Proposed fix
> 1. Add a restrictive top-level permissions block to every workflow, e.g.:
> permissions:
> contents: read
> or `permissions: {}` for workflows that don't need repository access
> at all.
> 2. For jobs that genuinely need elevated permissions (e.g. deploy-docs.yml
> writing to GitHub Pages, labeler.yml writing PR labels), scope those
> extra permissions at the job level only, following least privilege.
> 3. This can optionally be automated/verified using StepSecurity's
> "Secure Workflow" tool, which is already referenced in the Scorecard
> output:
>
> [https://app.stepsecurity.io/secureworkflow/apache/avro/]<workflow-file>/main?enable=pin
> h3. References
> - OpenSSF Scorecard Token-Permissions check:
>
> [https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions]
> - Current Scorecard result: score 0 (high severity)
> - GitHub docs on controlling GITHUB_TOKEN permissions:
>
> [https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
