[StepSecurity] Apply security best practices - #16
Conversation
Signed-off-by: StepSecurity Bot <bot@stepsecurity.io>
Reviewer's GuideApplies 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 actionsflowchart 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]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Since
harden-runneris 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 toegress-policy: blockwith 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>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| - name: Harden the runner (Audit all outbound calls) | ||
| uses: step-security/harden-runner@ab7a9404c0f3da075243ca237b5fac12c98deaa5 # v2.19.3 | ||
| with: |
There was a problem hiding this comment.
🚨 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
- If other steps in this workflow (or future additions) need to reach additional hosts (e.g., package registries, telemetry), add them to
allowed-endpointsin this same step. - To roll out blocking gradually, you can override
HARDEN_EGRESS_POLICYat the job or workflow-dispatch level (e.g., viaenvorinputs) toauditon specific jobs while keepingblockas the default here.
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: