[p4gs]

What

Adds socket-firewall-ci (phase 2, off by default) — control 48. It is additive: socket-firewall is untouched.

socket-firewall asks whether sfw is on the developer's PATH. That is a fact about a machine, and nobody cloning the repository can check it. This control asks the repository-observable question with different evidence: do this repository's COMMITTED workflows put their package-manager installs behind Socket Firewall? Every subject is read through git show HEAD:<path>, so an index-only git add and a working-tree edit are both excluded. No tool runs; no network call is made.

⚠️ Cross-repo ordering

The site repo must register the socket-firewall-ci id before this merges — every directory scan throws otherwise. Held for that; do not merge until the site side lands.

The design

Manager tiers are the false-positive defence. Socket Firewall Free proxies exactly npm, yarn, pnpm, pip (incl. python -m pip), uv, cargo. Go/Maven/Gradle/Bundler/gem/dotnet/NuGet are Enterprise-only; bun/composer/apt/brew/rustup are proxied at no tier. Only the free tier can produce a Fail — failing a maintainer for an ecosystem the free tool cannot protect is a false positive by construction. A repository whose only installs are Enterprise-tier verifies INFO, never PASS and never FAIL.

The first-acquisition rule. The unit is (job, ecosystem), with a local composite action (uses: ./…) spliced into the calling job at the step that uses it. The first acquisition of each pair must carry the sfw prefix:

- run: sfw cargo fetch --locked        # ← the one step that has to change
- run: cargo build --release --locked  # reads the filtered cache; silent

One-step remedy per job, instead of a prefix on every matrix cargo test.

Acquiring subcommands are an allowlist. An unrecognised subcommand is not an acquisition — cargo fmt, npm run, npm test are silent. Detection fails open on purpose: a missed install is a disclosed gap, an invented one sends a maintainer to fix nothing.

Recognition reuses workflows's shell tokeniser, not string matching, so an install inside a heredoc, a comment or a quoted string is text, and sudo / env / time / FOO=1 hide neither the manager (sudo npm ci fails) nor the firewall (sudo sfw npm ci passes).

workflows's operator gates are deliberately NOT imported. sfw npm ci || true still ran the install through the firewall, which is the whole question — importing the ! / set +e / || / | / & gates would be a bug here rather than an omission. Stated in the module docs and covered by a test.

Verdicts. Pass / Fail as above; Degraded + no-inventory when workflows parsed but nothing of any tier was acquired (nothing verified is not a pass); Degraded + scan-error when HEAD cannot be read; Info when an inventory exists with no free-tier acquisition. A workflow_dispatch-only workflow, one GitHub would refuse to run, a constant-false job or step, a non-POSIX run: body, an unresolvable uses: ./…, and the second level of a composite chain are each named not examined rather than counted as clean.

No evidence. machine.rs asserts every row's artifacts == workflows::artifacts_for(id), which is empty for this control, so the proving files are named in messages instead.

Four disclosed misses

Written into docs/phase-2.md and the changelog:

1. SocketDev/action's shims: true PATH-shimming is unreleased upstream; when it ships, an unprefixed install under it will be protected and this control will read it as unprotected.
2. Indirect acquisition (npm run build whose script installs, a Makefile target) is not followed.
3. Composites are spliced depth 1 only.
4. It proves the workflow says installs go through the firewall — not that it ran, nor that sfw resolved on PATH.

Dogfood: this repo FAILS, and ships the control off

[FAIL    ] socket-firewall-ci — 6 (job, ecosystem) unit(s) acquire packages outside Socket Firewall

• ci.yml job lint — bare cargo clippy --all-targets -- -D warnings
• ci.yml job test → setup-sscsb-tools/action.yml — python3 -m pip install --quiet semgrep==…
• ci.yml job test — cargo build --release --locked
• ci.yml job coverage → setup-sscsb-tools/action.yml — the same pip install, reached again
• ci.yml job coverage — cargo llvm-cov --locked …
• release.yml job build — cargo build --release --locked --target "$TARGET"

Plus one [info] (rustup target add — unsupported at any tier) and one later cargo test --locked correctly not judged.

Deliberately NOT enabled in .sscsb/config.toml here — the gap is visible and fixable as its own change. Default-off also means the directory's in_scope excludes it, so adding this control cannot move any other repository's grade.

Two corrections while in these files

docs/phase-2.md said socket-firewall "needs a Socket account" and the bundled skill filed it under "a paid or unreleased tool". Socket Firewall Free needs neither an account nor an API key. Both controls are now off for the real reason: putting a filtering proxy in front of every install is a decision about how builds fetch, not a binary you drop in.

Tests

26 in the new module, written red-first against a stub that returned Pass — 19 of the 21 cases that existed at that point failed against it (log kept). Coverage of src/socket_firewall.rs: 95.89% lines / 100% functions; crate total (lib) 96.52% lines / 96.24% functions, above the 95/94 gate.

cargo fmt --check clean, cargo clippy --all-targets --locked -- -D warnings clean.

src/workflows.rs changes are visibility only — sixteen items promoted to pub(crate) with no behaviour change, the way Finding::new was promoted for pinning.rs.

Lock-step files touched

src/socket_firewall.rs (new), src/lib.rs, src/controls.rs (entry + dispatch + default-off assertion), src/workflows.rs (visibility), templates/compliance/map.json, tests/tool_orchestration.rs (both lists), .claude/skills/sscsb/SKILL.md + templates/skills/sscsb/SKILL.md (byte-identical: 47→48, 32 on / 16 off, phase-2 row 9→10, taxonomy), README.md, docs/phase-2.md, CHANGELOG.md.

🤖 Generated with Claude Code