everything-claude-code

Affaan Mustafa · 2026-05-18 13:41:10 -04:00

7911af4a39

test(ci): coverage for round-1 fixes (quoted write-all, dedup, lifecycle scope)

Three test changes in response to the round-1 review:

1. **Add quoted-write-all coverage** (cubic P0 follow-up).
   Two new cases assert the regex now matches the double-quoted and
   single-quoted YAML forms of `permissions: "write-all"`:
     - `rejects double-quoted permissions: "write-all"`
     - `rejects single-quoted permissions: 'write-all'`
   Both fixtures trigger only the persist-credentials gate, so they
   exercise the WRITE_ALL_PATTERN OR-clause in isolation.

2. **Add expression+ref dedup coverage** (greptile P2 follow-up).
   `emits a single violation when both expressionPattern and refPattern
   match the same step` — uses `refs/pull/${{ … head.sha }}/merge` as
   the fixture (which matches both patterns) and counts ERROR lines for
   the `pull_request_target` rule, asserting exactly one. Re-introducing
   the duplicate-push bug would re-fail this test immediately.

3. **Drop the `npm ci without --ignore-scripts under write-all` test**
   (greptile P2). That test happened to pass under the previous
   `--ignore-scripts` regex, but `UNSAFE_INSTALL_PATTERNS` (added in
   `f7035b56`) fires unconditionally for every workflow regardless of
   permissions. So the test was exercising a pre-existing code path
   that has nothing to do with WRITE_ALL_PATTERN. Reviewer flagged this
   could mislead future contributors into thinking lifecycle-script
   enforcement is gated on write permissions.

   Replaced by the surrounding `rejects checkout credential persistence
   in workflows with permissions: write-all` test (already present) and
   the new quoted-form tests above, which all exercise the actual
   persist-credentials gate that the WRITE_ALL_PATTERN clause newly
   activates.

Test count: 22 → 24 (added 3 new, dropped 1). All green; `yarn lint`
clean.

The cohort comment above the write-all block was also tightened to
explicitly note that "the lifecycle-script gate already fires
unconditionally for every workflow" so the next reader sees the
distinction up front.

Jamkris · 2026-05-17 21:19:29 -04:00

7bb3172041

fix(ci): flag refs/pull checkouts under pull_request_target

The `pull_request_target` rule's `expressionPattern` matches only
the canonical `github.event.pull_request.head.{ref,sha,repo.full_name}`
interpolations. It does not match the second canonical form of
the same exploit — fetching `refs/pull/<N>/{head,merge}` directly:

  - uses: actions/checkout@v4
    with:
      ref: refs/pull/${{ github.event.pull_request.number }}/merge

The merge-ref variant is what GitHub's own security guidance calls
out as the highest-severity privilege-escalation pattern under
`pull_request_target`: it materialises the PR's merge commit
(attacker code spliced with base), executes inside a workflow that
has full repo-scoped tokens, and gives the attacker the chance to
exfiltrate secrets or push to default branches. `refs/pull/N/head`
is functionally equivalent — same source, same trust boundary.

Reproduced on `main` before this commit:

  $ cat /tmp/bad.yml
  name: bad
  on: { pull_request_target: { types: [opened] } }
  permissions: { contents: read }
  jobs:
    do:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
          with:
            ref: refs/pull/${{ github.event.pull_request.number }}/merge
            persist-credentials: false
        - run: npm ci --ignore-scripts

  $ ECC_WORKFLOWS_DIR=/tmp node scripts/ci/validate-workflow-security.js
  Validated workflow security for 1 workflow files
  $ echo $?
  0

Expected: violation flagging the refs/pull checkout under pull_request_target.
Actual: passes silently.

Fix: add a `refPattern` to the `pull_request_target` rule:

    /^\s*ref:\s*['"]?[^'"\n]*refs\/(?:remotes\/)?pull\/[^'"\n\s]+/m

and apply it per checkout step inside the existing
event-gated loop. The pattern matches the ref VALUE so it catches
all interpolation shapes — `refs/pull/123/head`,
`refs/pull/${{ github.event.pull_request.number }}/merge`,
`${{ env.FOO }}/refs/pull/N/head` — without enumerating the
possible interpolations themselves.

Scoping: the rule is already gated on the workflow containing
`pull_request_target:`, so non-privileged `pull_request` workflows
that legitimately check out a PR ref are not affected.

After this commit the reproduction above exits 1 with:

  ERROR: bad.yml:10 - pull_request_target must not checkout an untrusted pull_request head ref/repository

Three new regression tests in `tests/ci/validate-workflow-security.test.js`:
  - rejects pull_request_target + refs/pull/<N>/merge
  - rejects pull_request_target + hardcoded refs/pull/<N>/head
  - allows pull_request_target with no `with.ref:` (base-ref checkout —
    the safe pattern from GitHub's own guidance)

Test count: 17 → 20 in this file; full `yarn test` still green.

Together with the previous commit, this closes the two
independent `validate-workflow-security.js` bypasses I found.

Jamkris · 2026-05-17 21:19:29 -04:00

cdbc925d89

fix(ci): treat 'permissions: write-all' as a write-permission gate

`WRITE_PERMISSION_PATTERN` in `validate-workflow-security.js`
enumerates named GitHub Actions scopes (`contents: write`,
`issues: write`, etc.) to decide whether a workflow needs to:
  - disable `persist-credentials` on `actions/checkout`
  - pass `--ignore-scripts` to `npm ci`

The pattern misses the top-level shorthand `permissions:
write-all`, which is the strictly broader form — it grants every
named scope write access in a single line. As a result, a
workflow that opts into write-all currently slips both gates.

Reproduced on `main` before this commit:

  $ cat /tmp/bad.yml
  name: bad
  on: [push]
  permissions: write-all
  jobs:
    do:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - run: npm ci

  $ ECC_WORKFLOWS_DIR=/tmp node scripts/ci/validate-workflow-security.js
  Validated workflow security for 1 workflow files
  $ echo $?
  0

Expected: at least two violations (missing `persist-credentials:
false`, missing `--ignore-scripts`).
Actual: passes silently.

Fix: add a sibling pattern `WRITE_ALL_PATTERN` that matches
`^\s*permissions:\s*write-all\b` and OR it with
`WRITE_PERMISSION_PATTERN` at the single gate. Both top-level
and job-level `permissions:` blocks satisfy the `^\s*` prefix.

After this commit the reproduction above exits 1 with:

  ERROR: bad.yml:8 - workflows with write permissions must disable checkout credential persistence
  ERROR: bad.yml:9 - workflows with write permissions must install npm dependencies with --ignore-scripts

Three new regression tests in `tests/ci/validate-workflow-security.test.js`:
  - rejects write-all + credential-persisting checkout
  - rejects write-all + `npm ci` without `--ignore-scripts`
  - allows write-all when both gates are satisfied (no over-block)

Test count: 14 → 17 in this file; full `yarn test` still green.

A separate `refs/pull/N/merge` bypass under `pull_request_target`
exists in the same validator and is fixed in the next commit.

Jamkris · 2026-05-17 21:19:29 -04:00

7f971b7e6f

Harden CI installs against supply-chain lifecycle hooks

Affaan Mustafa · 2026-05-15 17:29:03 -04:00

f7035b5644

ci: disable checkout credential persistence in privileged workflows (#1851 )

Affaan Mustafa · 2026-05-13 01:15:49 -04:00

209abd403b

docs: add supply-chain incident response playbook

Add a repo-level supply-chain incident response playbook for npm/GitHub Actions package-registry incidents, anchored on the May 2026 TanStack compromise and prior Shai-Hulud-style npm incidents.

- add `docs/security/supply-chain-incident-response.md` with exposure checks, immediate response steps, workflow rules, publication rules, and escalation triggers
- link the playbook from `SECURITY.md`
- reject `pull_request_target` workflows that restore or save shared dependency caches
- add a regression test for the new `pull_request_target + actions/cache` guardrail

Validation:
- node tests/ci/validate-workflow-security.test.js (12 passed, 0 failed)
- node scripts/ci/validate-workflow-security.js (validated 7 workflow files)
- npx markdownlint-cli 'SECURITY.md' 'docs/security/supply-chain-incident-response.md'
- npx markdownlint-cli '**/*.md' --ignore node_modules
- git diff --check
- node tests/run-all.js (2377 passed, 0 failed)
- GitHub CI for #1848 green across Ubuntu, Windows, and macOS

No release, tag, npm publish, plugin tag, marketplace submission, or announcement was performed.

Affaan Mustafa · 2026-05-13 00:22:28 -04:00

cbecf5689d

ci: require npm audit signature checks

Require npm registry signature verification wherever workflow npm audit checks run.

- add npm audit signatures to CI Security Scan and maintenance security audit jobs
- teach the workflow security validator to reject npm audit without signature verification
- keep the repair and Copilot prompt tests portable across Windows path/case and CRLF frontmatter behavior

Validation:
- node tests/run-all.js (2376 passed, 0 failed)
- CI current-head matrix green on #1846

Affaan Mustafa · 2026-05-12 23:48:56 -04:00

797f283036

ci: harden workflow install boundaries

- run non-test workflow installs with npm ci --ignore-scripts where lifecycle scripts are not needed\n- reject plain npm ci in workflows with write permissions\n- reject actions/cache in id-token: write workflows to reduce OIDC publish cache-poisoning risk

Affaan Mustafa · 2026-05-12 21:55:36 -04:00

daf0355531

fix: harden CI validators

Ports personal-path validator hardening and quoted checkout detection onto current main.

Affaan Mustafa · 2026-05-11 03:08:43 -04:00

e674a7dbd7

fix: block unsafe privileged workflow checkouts

Affaan Mustafa · 2026-04-12 23:23:01 -07:00

3792b69a38

11 Commits