Skip to content

[StepSecurity] Apply security best practices - #16

Open
stepsecurity-app[bot] wants to merge 1 commit into
masterfrom
chore/GHA-291419-stepsecurity-remediation
Open

[StepSecurity] Apply security best practices#16
stepsecurity-app[bot] wants to merge 1 commit into
masterfrom
chore/GHA-291419-stepsecurity-remediation

Conversation

@stepsecurity-app

@stepsecurity-app stepsecurity-app Bot commented May 29, 2026

Copy link
Copy Markdown
Contributor

Summary

This pull request has been generated by StepSecurity as part of your enterprise subscription to ensure compliance with recommended security best practices. Please review and merge the pull request to apply these security enhancements.

Security Fixes

Harden Runner

Harden-Runner is an open-source security agent for the GitHub-hosted runner to prevent software supply chain attacks. It prevents exfiltration of credentials, detects tampering of source code during build, and enables running jobs without sudo access.

Pinned Dependencies

Pinning GitHub Actions to specific versions or commit SHAs ensures that your workflows remain consistent and secure.
Unpinned actions can lead to unexpected changes or vulnerabilities caused by upstream updates.

Feedback

For bug reports, feature requests, and general feedback; please create an issue in step-security/secure-repo or contact us via our website.

Summary by Sourcery

Apply security hardening to the blend-v-release GitHub Actions workflow, including runner protection and pinned action versions.

CI:

  • Add StepSecurity harden-runner to audit outbound calls in release-related jobs.
  • Pin GitHub Actions (checkout, upload-artifact, download-artifact, attest-build-provenance) to specific versions by commit SHA in the release workflow.

Signed-off-by: StepSecurity Bot <bot@stepsecurity.io>
@sourcery-ai

sourcery-ai Bot commented May 29, 2026

Copy link
Copy Markdown

Reviewer's Guide

Applies StepSecurity-recommended hardening to the blend-v-release workflow by inserting the harden-runner step on all relevant jobs and pinning all GitHub Actions dependencies to specific commit SHAs while keeping their existing major versions.

Flow diagram for updated blend-v-release job steps with harden-runner and pinned actions

flowchart TD
    A[Job start] --> B[step-security/harden-runner with egress-policy audit]
    B --> C[actions/checkout pinned to commit SHA]
    C --> D[actions/download-artifact pinned to commit SHA]
    D --> E[actions/upload-artifact pinned to commit SHA]
    E --> F[actions/attest-build-provenance pinned to commit SHA]
    F --> G[Job end]
Loading

File-Level Changes

Change Details Files
Introduce StepSecurity harden-runner to audit outbound calls in all release-related jobs.
  • Add a Harden the runner step at the start of each workflow job that previously began directly with checkout or other steps
  • Configure harden-runner with egress-policy set to audit so it only observes and logs outbound network traffic
.github/workflows/blend-v-release.yml
Pin previously version-tagged GitHub Actions to immutable commit SHAs while preserving their current versions.
  • Pin actions/checkout v6 to a specific commit SHA across all jobs that use it
  • Pin actions/upload-artifact v6 to a specific commit SHA in all upload steps
  • Pin actions/download-artifact v7 to a specific commit SHA in all download steps
  • Pin actions/attest-build-provenance v3 to a specific commit SHA in the Attest step
.github/workflows/blend-v-release.yml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue, and left some high level feedback:

  • Since harden-runner is added to multiple jobs with identical configuration, consider extracting this into a reusable workflow or composite action to reduce repetition and keep future security policy changes centralized.
  • You’re currently using egress-policy: audit; for especially sensitive jobs (e.g., release creation) you may want to evaluate switching those to egress-policy: block with an explicit allowlist once you’re comfortable with the outbound call patterns.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- Since `harden-runner` is added to multiple jobs with identical configuration, consider extracting this into a reusable workflow or composite action to reduce repetition and keep future security policy changes centralized.
- You’re currently using `egress-policy: audit`; for especially sensitive jobs (e.g., release creation) you may want to evaluate switching those to `egress-policy: block` with an explicit allowlist once you’re comfortable with the outbound call patterns.

## Individual Comments

### Comment 1
<location path=".github/workflows/blend-v-release.yml" line_range="59-61" />
<code_context>
       GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
     steps:
-      - uses: actions/checkout@v6
+      - name: Harden the runner (Audit all outbound calls)
+        uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2.19.3
+        with:
+          egress-policy: audit
+
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Consider using a stricter egress policy (e.g. `block`) for hardened runners in non-experimental workflows.

`egress-policy: audit` only logs outbound calls and doesn’t prevent unexpected network access. For release/production workflows, consider `egress-policy: block` plus an explicit allowlist of required hosts so this becomes an enforcing control and limits impact if an action or dependency is compromised. You could make the policy configurable (inputs/env) and roll out `block` gradually on a subset of jobs if you’re worried about disruption.

Suggested implementation:

```
    env:
      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      # Override to 'audit' or 'monitor' if you need to temporarily relax blocking in this workflow.
      HARDEN_EGRESS_POLICY: block
    steps:
      - name: Harden the runner (Block unexpected outbound calls)
        uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2.19.3
        with:
          # Default to 'block' for release workflows; allow override via env if needed.
          egress-policy: ${{ env.HARDEN_EGRESS_POLICY || 'block' }}
          allowed-endpoints: >
            github.com:443
            api.github.com:443
            objects.githubusercontent.com:443

```

1. If other steps in this workflow (or future additions) need to reach additional hosts (e.g., package registries, telemetry), add them to `allowed-endpoints` in this same step.
2. To roll out blocking gradually, you can override `HARDEN_EGRESS_POLICY` at the job or workflow-dispatch level (e.g., via `env` or `inputs`) to `audit` on specific jobs while keeping `block` as the default here.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +59 to +61
- name: Harden the runner (Audit all outbound calls)
uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2.19.3
with:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚨 suggestion (security): Consider using a stricter egress policy (e.g. block) for hardened runners in non-experimental workflows.

egress-policy: audit only logs outbound calls and doesn’t prevent unexpected network access. For release/production workflows, consider egress-policy: block plus an explicit allowlist of required hosts so this becomes an enforcing control and limits impact if an action or dependency is compromised. You could make the policy configurable (inputs/env) and roll out block gradually on a subset of jobs if you’re worried about disruption.

Suggested implementation:

    env:
      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      # Override to 'audit' or 'monitor' if you need to temporarily relax blocking in this workflow.
      HARDEN_EGRESS_POLICY: block
    steps:
      - name: Harden the runner (Block unexpected outbound calls)
        uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2.19.3
        with:
          # Default to 'block' for release workflows; allow override via env if needed.
          egress-policy: ${{ env.HARDEN_EGRESS_POLICY || 'block' }}
          allowed-endpoints: >
            github.com:443
            api.github.com:443
            objects.githubusercontent.com:443

  1. If other steps in this workflow (or future additions) need to reach additional hosts (e.g., package registries, telemetry), add them to allowed-endpoints in this same step.
  2. To roll out blocking gradually, you can override HARDEN_EGRESS_POLICY at the job or workflow-dispatch level (e.g., via env or inputs) to audit on specific jobs while keeping block as the default here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants