Skip to content

Add Socket Firewall (free) to shared setup + test workflow#18

Open
oxyc wants to merge 2 commits into
masterfrom
feat/socket-firewall
Open

Add Socket Firewall (free) to shared setup + test workflow#18
oxyc wants to merge 2 commits into
masterfrom
feat/socket-firewall

Conversation

@oxyc
Copy link
Copy Markdown
Member

@oxyc oxyc commented May 13, 2026

Summary

Wire Socket Firewall (free edition) into the shared setup composite and test workflow so all consumers automatically get malicious-npm-package interception in CI.

  • setup/action.yml: installs the sfw binary via SocketDev/action@v1.3.2 (pinned to SHA), mode firewall-free — no token, no account needed.
  • .github/workflows/test.yml: pre-installs npm packages via sfw npm ci --ignore-scripts before composer install:development.

Why

min-release-age=7d (rolled out to project .npmrc files yesterday) protects against fresh malicious packages. But established packages can be compromised mid-life (maintainer takeover, supply-chain injection); cooldowns don't help there. Socket Firewall checks each install against Socket's known-malicious database in real time and aborts the install if a flagged package would be pulled. The free edition does this without any account or API token.

How the coverage shapes up

Most of our projects bury npm install inside a composer build script (e.g. bedrock's install:development@composer buildnpm install). sfw only intercepts commands explicitly prefixed with it.

The pattern here pre-installs via sfw npm ci first. The subsequent npm call inside the composer script then sees a populated node_modules and a matching lockfile, so it no-ops for everything that was already locked. Residual gap: if the composer-driven npm install actually adds a net-new package (rare; would need a lockfile mismatch), that single install would bypass sfw.

Per-project composer scripts can close the gap by switching their build script's npm install to sfw npm install — but most repos don't need to bother given the size of the gap.

Tradeoffs

  • Adds a network dependency on Socket's API per CI job. Outage at Socket = sfw either fails closed or open depending on its design; if it blocks builds, that's a new failure mode.
  • False positives: if Socket misflags a legitimate package, CI breaks until either Socket updates or we remove sfw. Free tier has no override mechanism — only Enterprise does.
  • Free tier limits unknown. May rate-limit per IP/job; not seeing this called out in docs.

Test plan

  • Test workflow runs on this PR; the new "Install npm packages through Socket Firewall" step appears in logs.
  • Step logs show sfw invoking npm and reporting on package scan results.
  • Subsequent composer install:development completes without re-downloading npm packages (cache hit).
  • Test runs across a few consumer repos after merge — no false-positive blocks.

Rollout

Merge → consumers using generoi/github-actions/.github/workflows/test.yml@v1 and generoi/github-actions/setup@v1 inherit the change on next CI run.

Follow-ups (not in this PR)

  • Update deploy.yml / sync-db.yml / e2e.yml in this repo to also use sfw npm ci for full coverage of non-test workflows.
  • Document the sfw npm install convention in README so per-project composer scripts can opt in.
  • Consider Socket's GitHub App separately — it's the PR-comment companion to the install-time blocking, complementary.

oxyc added 2 commits May 13, 2026 20:13
Installs the `sfw` binary in the setup composite and uses it to pre-install
npm packages in the shared test workflow. Free edition; no token required.
Blocks known-malicious npm packages at install time rather than only flagging
them after the fact.

`sfw npm ci` runs before `composer install:development`, so the subsequent
`npm install` invoked by the project's composer build script becomes a no-op
against the populated node_modules. Residual gap: any net-new package added
by that composer-driven npm install would bypass sfw. Per-project composer
scripts can close it by switching to `sfw npm install`.
PATH additions made by Node actions inside composite actions don't
reliably propagate to subsequent workflow steps — the first CI run
on this branch failed with 'sfw: command not found' after the binary
was installed inside the setup composite. Install at the workflow
level instead so sfw is available in the next step.
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.

1 participant