[StepSecurity] ci: Harden GitHub Actions

[step-security-bot]

Summary

This pull request is created by StepSecurity at the request of @sgammon. Please merge the Pull Request to incorporate the requested changes. Please tag @sgammon on your message if you have any questions related to the PR.

Security Fixes

Pinned Dependencies

GitHub Action tags and Docker tags are mutable. This poses a security risk. GitHub's Security Hardening guide recommends pinning actions to full length commit.

• GitHub Security Guide
• The Open Source Security Foundation (OpenSSF) Security Guide

Feedback

For bug reports, feature requests, and general feedback; please email support@stepsecurity.io. To create such PRs, please visit https://app.stepsecurity.io/securerepo.

Signed-off-by: StepSecurity Bot bot@stepsecurity.io

Summary by CodeRabbit

• Chores
  • Updated the setup-gradle action across various GitHub workflows to enhance build and automation processes.

[coderabbitai]

Walkthrough

Walkthrough

The update primarily involves the transition of the setup-gradle action to a newer version, specifically 417ae3ccd767c252f5661f1ace9f835f9654f2b5, from its previous v3.1.0. This change is uniformly applied across a variety of GitHub workflow files, affecting operations ranging from code quality checks and build jobs to publishing artifacts, indicating a broad enhancement in the build and CI/CD processes.

Changes

Files	Change Summary
.github/workflows/checks... .github/workflows/job... .github/workflows/on... .github/workflows/publish.maven.yml	Updated setup-gradle action to 417ae3ccd767c252f5661f1ace9f835f9654f2b5 from v3.1.0

🐰✨
In the land of code and byte,
A rabbit hopped with sheer delight.
"A change, a change, it's shiny and new,
From v3.1.0 to a version true.
Across the workflows, far and wide,
With Gradle's grace, we smoothly glide."
🌟🚀

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository from git and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[coderabbitai]

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between d28e199 and 660f1db.

Files selected for processing (13)

• .github/workflows/checks.codeql.yml (1 hunks)
• .github/workflows/checks.detekt.yml (1 hunks)
• .github/workflows/checks.qodana.yml (1 hunks)
• .github/workflows/checks.sonar.yml (2 hunks)
• .github/workflows/job.bench.yml (1 hunks)
• .github/workflows/job.build.yml (1 hunks)
• .github/workflows/job.cli.yml (2 hunks)
• .github/workflows/job.containers.yml (2 hunks)
• .github/workflows/job.site.yml (1 hunks)
• .github/workflows/job.test.yml (5 hunks)
• .github/workflows/on.pr.yml (2 hunks)
• .github/workflows/on.scheduled.yml (1 hunks)
• .github/workflows/publish.maven.yml (4 hunks)

Additional comments: 22

.github/workflows/checks.detekt.yml (1)

• 94-94: The update of the setup-gradle action to use a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) instead of a version tag (v3.1.0) is a good security practice. This change mitigates the risk associated with mutable tags. Ensure that the commit SHA corresponds to the intended version of the setup-gradle action.

.github/workflows/checks.qodana.yml (1)

• 94-94: Updating the setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) enhances security by avoiding mutable tags. This is a commendable practice that aligns with recommendations for securing CI/CD workflows.

.github/workflows/checks.codeql.yml (1)

• 114-114: Switching to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) for the setup-gradle action is a positive step towards enhancing the security of the workflow. This practice helps mitigate risks associated with mutable tags.

.github/workflows/job.bench.yml (1)

• 96-96: The update to use a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) for the setup-gradle action in the benchmarking workflow is a commendable security practice. This change helps ensure the stability and security of the workflow by avoiding mutable tags.

.github/workflows/checks.sonar.yml (2)

• 112-112: The use of a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) for the setup-gradle action in the "Build: Verify Coverage" job enhances the security and reliability of the workflow. This practice helps mitigate risks associated with mutable tags.
• 127-127: Similarly, updating the setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) in the "Analysis: Sonar" job is a good security practice. It ensures the stability and security of the workflow by avoiding mutable tags.

.github/workflows/on.scheduled.yml (1)

• 163-163: Updating the setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) in the scheduled checks workflow is a positive security measure. This approach helps ensure the stability and security of the workflow by avoiding mutable tags.

.github/workflows/on.pr.yml (2)

• 116-116: The change to pin the buildless/setup action to a specific commit SHA (30e82389418c7f17046606183bc4c78b2c8913e0) enhances security by ensuring the action's version is immutable. This aligns with best practices for securing CI/CD pipelines.
• 134-134: Pinning the gradle/actions/setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) instead of using a version tag (v3.1.0) is a significant security improvement. It prevents potential risks associated with mutable tags. However, ensure that this SHA corresponds to the intended version (v3.1.0) for compatibility and functionality.

Verification successful

---

The commit SHA 417ae3ccd767c252f5661f1ace9f835f9654f2b5 corresponds to the intended version v3.1.0 of the gradle/actions/setup-gradle action, as indicated by the commit message "Prepare for v3.1.0 release". This confirms the accuracy of the review comment regarding the security improvement by pinning to a specific commit SHA.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify the commit SHA corresponds to the intended version of the setup-gradle action
gh api repos/gradle/actions/commits/417ae3ccd767c252f5661f1ace9f835f9654f2b5 --jq '.commit.message'

Length of output: 126

.github/workflows/publish.maven.yml (2)

• 194-194: The update to pin the gradle/actions/setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) for the "Publish: Conventions" step is a good practice for enhancing security. Ensure this SHA accurately represents the intended version (v3.1.0) of the action.

Verification successful

---

The verification confirms that the commit SHA 417ae3ccd767c252f5661f1ace9f835f9654f2b5 accurately represents the intended version (v3.1.0) of the gradle/actions/setup-gradle action, as indicated by the commit message "Prepare for v3.1.0 release". This aligns with the best practices for enhancing security by pinning actions to a specific commit SHA.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify the commit SHA corresponds to the intended version of the setup-gradle action for the "Publish: Conventions" step
gh api repos/gradle/actions/commits/417ae3ccd767c252f5661f1ace9f835f9654f2b5 --jq '.commit.message'

Length of output: 126

* 211-211: Similar to the previous comment, pinning the `gradle/actions/setup-gradle` action to a specific commit SHA (`417ae3ccd767c252f5661f1ace9f835f9654f2b5`) for the "Publish: Substrate" step is a commendable security practice. Verify the SHA corresponds to the intended action version.

Verification successful

---

The commit SHA 417ae3ccd767c252f5661f1ace9f835f9654f2b5 indeed corresponds to the intended action version v3.1.0 for the "Publish: Substrate" step, as confirmed by the commit message "Prepare for v3.1.0 release".

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify the commit SHA corresponds to the intended version of the setup-gradle action for the "Publish: Substrate" step
gh api repos/gradle/actions/commits/417ae3ccd767c252f5661f1ace9f835f9654f2b5 --jq '.commit.message'

Length of output: 126

.github/workflows/job.site.yml (1)

• 82-82: Updating the gradle/actions/setup-gradle action to use a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) for the "Build: Site" step is in line with security best practices. It's important to verify that this SHA matches the intended version (v3.1.0) of the action for compatibility purposes.

Verification successful

---

The commit SHA 417ae3ccd767c252f5661f1ace9f835f9654f2b5 is confirmed to be associated with the preparation for the v3.1.0 release of the gradle/actions/setup-gradle action. This verifies the accuracy of the review comment regarding the update for security best practices.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify the commit SHA corresponds to the intended version of the setup-gradle action for the "Build: Site" step
gh api repos/gradle/actions/commits/417ae3ccd767c252f5661f1ace9f835f9654f2b5 --jq '.commit.message'

Length of output: 126

.github/workflows/job.build.yml (1)

• 249-249: The update of the gradle/actions/setup-gradle action to use a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) instead of a version tag (v3.1.0) is a good practice for enhancing security by ensuring immutability of the action version. This change aligns with the best practices recommended by GitHub and the OpenSSF for securing GitHub Actions workflows.

.github/workflows/job.containers.yml (2)

• 241-241: The update of the gradle/actions/setup-gradle action to use a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) instead of a version tag (v3.1.0) in the Docker JVM job is a positive change for security, ensuring the immutability of the action version used. This practice is recommended for securing GitHub Actions workflows.
• 363-363: Similarly, for the Docker Native job, updating the gradle/actions/setup-gradle action to use a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) enhances the security by preventing potential risks associated with mutable dependencies. This aligns with security best practices.

.github/workflows/job.cli.yml (2)

• 210-210: The update of the setup-gradle action to use a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) instead of a mutable version tag (v3.1.0) in the "Build: CLI (Native/Debug)" job is a positive security enhancement. This change aligns with best practices for dependency management by ensuring the action version is immutable, reducing the risk of supply chain attacks.
• 383-383: Similarly, for the "Build: CLI (Native/Release)" job, pinning the setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) enhances the security posture of the workflow. This approach mitigates potential risks associated with mutable tags and ensures a consistent build environment.

.github/workflows/job.test.yml (5)

• 236-236: Updating the setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) in the "Testsuite" job is a commendable security practice. This change ensures the use of an immutable reference, which is crucial for maintaining a secure and predictable build environment.
• 280-280: For the "Analysis: Sonar" job, pinning the setup-gradle action to a specific commit SHA (417ae3ccd767c252f5661f1ace9f835f9654f2b5) is a proactive security measure. It effectively addresses the risks associated with mutable dependencies and aligns with the recommended practices for secure software development.
• 322-322: Repeating the security enhancement in another instance of the "Analysis: Sonar" job by using a specific commit SHA for the setup-gradle action reinforces the project's commitment to security. This consistency across workflow jobs is crucial for ensuring all parts of the CI/CD pipeline are protected against mutable dependency risks.
• 365-365: The use of a specific commit SHA for the setup-gradle action in the "Runtime Self-tests (JVM)" job further exemplifies the thorough application of security best practices throughout the workflow configurations. This consistent approach across different jobs enhances the overall security posture of the project.
• 535-535: Finally, in the "Run Tests (Native)" job, updating the setup-gradle action to use a specific commit SHA is a prudent security measure. It ensures that the native tests also benefit from the enhanced security of using immutable references for GitHub Actions, contributing to a secure and stable CI/CD environment.