[DWS] SHA-pin GitHub Actions, and replace Snyk and Gitleaks with GitHub secret scanning - #18
Open
nickwinder wants to merge 3 commits into
Open
[DWS] SHA-pin GitHub Actions, and replace Snyk and Gitleaks with GitHub secret scanning#18nickwinder wants to merge 3 commits into
nickwinder wants to merge 3 commits into
Conversation
Tags are mutable. A maintainer, or an attacker with write access to an action's repository, can move a tag to a different commit, and the next workflow run then executes that code with our workflow token and repo secrets. A full commit SHA is immutable and closes that window. The trailing comment records the release each SHA resolves to, so the version stays readable and Dependabot can still open update PRs. snyk/actions/node moves off the `master` branch to the v1.0.0 release SHA. A branch ref is mutable for the same reason a tag is, and master is only three commits ahead of v1.0.0.
The step never ran. Its own guard, `if: env.SNYK_TOKEN != ''`, is false because no SNYK_TOKEN secret exists on the repository or the organization, and `continue-on-error: true` meant it could not fail the job even if it had run. `npm audit --production --audit-level=moderate` runs two steps earlier in the same job, against the same dependency tree, and needs no token. That is the coverage the Snyk step was supposed to add.
nickwinder
force-pushed
the
nick/dws/ci-sha-pin-secret-scanning
branch
from
August 11, 2026 08:39
fb2025a to
ee4f375
Compare
Gitleaks needs a licence key for repositories owned by an organization. No GITLEAKS_LICENSE secret exists here, so the step failed on every run, and `continue-on-error: true` hid that failure. GitHub secret scanning and push protection are now enabled on the repository. They cover the same ground from a better position: push protection rejects the commit before the secret reaches the remote, where Gitleaks could only report a key that was already published. The job keeps its own grep for the Nutrient key formats. Those are not GitHub partner patterns, so nothing else looks for them. `fetch-depth: 0` and the `security-events: write` permission went with the step. Only Gitleaks needed the full history and the SARIF upload.
nickwinder
force-pushed
the
nick/dws/ci-sha-pin-secret-scanning
branch
from
August 11, 2026 08:46
ee4f375 to
75af958
Compare
nickwinder
marked this pull request as ready for review
August 11, 2026 08:57
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #16, which was approved with a request to SHA-pin the GitHub Actions.
SHA pinning
All 20
uses:references across the four workflows now name a full commit SHA, with the release in a trailing comment so the version stays readable and Dependabot can still open update PRs.actions/checkout3d3c42e5…# v7.0.1actions/setup-node82076278…# v7.0.0actions/upload-artifact043fb46d…# v7.0.1actions/github-script3a2844b7…# v9.0.0A tag is a mutable pointer. Anyone who can move it can run their code with this repository's workflow token and secrets. A commit SHA cannot be moved.
Removing two scans that never ran
Snyk. The step was gated behind
if: env.SNYK_TOKEN != ''. NoSNYK_TOKENsecret exists on the repository or the organization, so the guard was always false.continue-on-error: truemeant it could not have failed the job even if it had run.npm audit --production --audit-level=moderatealready runs two steps earlier in the same job, against the same dependency tree, and needs no token.Gitleaks. The action requires a licence key for repositories owned by an organization. No
GITLEAKS_LICENSEsecret exists, so the step failed on every run, andcontinue-on-error: truehid that failure.What replaces them
GitHub secret scanning and push protection are now enabled on the repository. Push protection rejects a commit containing a recognised credential before it reaches the remote, where Gitleaks could only report a key that was already published. CodeQL default setup is also enabled, covering
actionsandjavascript-typescript.The workflow keeps its own check for the Nutrient key formats (
pdf_live_, its base64 form,sk_|pk_|nutr_sk_). Those are not GitHub partner patterns, so nothing else looks for them.fetch-depth: 0and thesecurity-events: writepermission went with the Gitleaks step. Only Gitleaks needed the full history and the SARIF upload.Verification
Local, on
fb2025a:Every workflow file still parses, and no unpinned reference remains:
Each pinned SHA was resolved from the GitHub API and confirmed to match the release named in its comment, for example:
The
checkout,setup-node,github-scriptandupload-artifactpins were exercised end to end by CI on #16 before the merge: 11 checks passed, including unit tests on Node 22 and 24 across ubuntu, windows and macos.Repository settings, applied and read back: