chore(ci): setup dependency firewall for npm

[staaldraad]

What kind of change does this PR introduce?

CI hardening.

When publishing, ensure dependencies are pulled in via the dependency firewall.

• DF_FIREWALL_TOKEN value set
• Policy in evaluation mode for teting

[coveralls]

Coverage Report for CI Build 34979087312

Coverage decreased (-0.09%) to 82.743%

Details

• Coverage decreased (-0.09%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 19 coverage regressions across 2 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

19 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
src/internal/http/agent.ts	17	32.56%
src/http/routes/s3/index.ts	2	86.09%

---

Coverage Stats

Relevant Lines:	14094
Covered Lines:	12106
Line Coverage:	85.89%
Relevant Branches:	8615
Covered Branches:	6684
Branch Coverage:	77.59%
Branches in Coverage %:	Yes
Coverage Strength:	734.66 hits per line

---

💛 - Coveralls

[claude]

LGTM — straightforward CI hardening change.

Extended reasoning...

Overview

This PR adds an opt-in npm dependency firewall (DepthFirst) to the CI node setup actions and wires the auth token secret only into the release.yml publish workflow. It touches three files: two composite actions (setup-node-dependencies, setup-node-npm) and release.yml.

Security risks

The main risk to check was whether DF_FIREWALL_TOKEN could leak to untrusted code, since it is only safe to use in workflows that never run on pull_request (per the action's own input description). I verified that ci.yml and acceptance.yml (both triggered on pull_request) call setup-node-dependencies/setup-node-npm without passing firewall-token, so it defaults to an empty string and the firewall-configuration step (if: inputs.firewall-token != '') is skipped there. Only release.yml, which triggers on push to master and workflow_dispatch, passes the secret. The token is injected via an env: var and referenced with `` inside the script rather than interpolated directly into the YAML, avoiding shell/script injection from untrusted branch content.

Level of scrutiny

This is CI-only configuration with no production code paths touched, but it does handle a secret token, so I checked its blast radius carefully (see above) rather than treating it as a pure mechanical change. The docker image publish path does not receive the firewall config, which was already flagged and ruled out by the bug hunt as out of scope for this npm-focused change.

Other factors

The change is small, additive (new optional input defaulting to a no-op), and does not alter existing behavior for any workflow that doesn't explicitly pass the token. No tests are affected since this is pure CI plumbing.

[ferhatelmas]

there is a gap for build dependencies