ci: vendor supply-chain workflows so they run on this public repo

[stackbilt-admin]

The Supply Chain workflow has failed with "workflow file issue" in ~0s on every run since at least 2026-08-24, so no SBOM or dependency review has run on this repo. It called reusable workflows hosted in a private org repo whose Actions access is "none"; a public repo cannot call reusable workflows from a private one, so GitHub rejected each run before any job started.

This inlines both jobs:

• Generate SBOM: @cyclonedx/cdxgen reads pnpm-lock.yaml and writes a CycloneDX JSON sbom.json covering the whole workspace (all packages/* are recorded under metadata.component.components). A verify step fails the job if the file is missing or not valid JSON, has fewer than 50 components, records no workspace packages, or lacks @modelcontextprotocol/sdk. It prints the component count. The SHA-256 is printed and the SBOM is uploaded as an artifact (90 days).
• Dependency Review (PRs only): actions/dependency-review-action v5.0.0 (a1d282b3…, verified against the tag; fail-on-severity is unchanged in v5), fail-on-severity: high.

Generator pin: cdxgen 12.8.5 (released 2026-09-29) is installed with npm ci --ignore-scripts --omit=optional from a committed lockfile at .github/sbom/package-lock.json. That pins it and every transitive dependency with integrity hashes, all resolved from registry.npmjs.org. It installs under $RUNNER_TEMP, and .github/** is excluded from the scan, so the generator's own dependencies stay out of the SBOM. The tool's package.json overrides undici to the patched 7.29.1, because cdxgen 12.8.5 pins 7.28.0, which has three high-severity advisories (GHSA-4cwx-7wf7-3272, GHSA-w293-vg96-wgc3, GHSA-rfgv-xxqx-mfg5). npm audit on the tool lockfile reports 0 vulnerabilities. .gitignore gets one exception so that lockfile can be committed. I chose this over the official GHCR image pinned by digest because every cdxgen image variant is 3.4–4.7 GB compressed for amd64, too heavy to pull on every PR. The npm install is about 48 MB. (cdxgen 13.x ships only as images, not on npm.) Locally against this tree, the SBOM has 181 components and 13 workspace packages. The earlier cyclonedx-npm failed with npm ls ELSPROBLEMS on pnpm's layout; this generator replaces it.

Pins: checkout, pnpm/action-setup and setup-node are the same as ci.yml, upload-artifact is the same as governance.yml, and dependency-review-action is pinned here. Permissions are contents: read throughout (pull-requests: write dropped, as the action doesn't comment by default).

Publication review: before inlining, every line of the source was checked for secrets, internal hosts, private repo names and internal references. The upstream's internal SBOM receipt-reporting steps were intentionally omitted. No secrets are used. The operator approved publishing on that basis.

Validated with actionlint 1.7.7, a local cdxgen run plus the verify script (including a negative test on an empty SBOM), and this PR's CI.

🤖 Generated with Claude Code

[stackbilt-admin]

Adversarial review: CHANGES_REQUESTED (posted as a comment)

Verified against PR head 7ea1f84, this PR's CI run 38987911586, the other workflows in the repo, and the GitHub API.

Findings

1. [CRITICAL] .github/workflows/supply-chain.yml:34 — the SBOM job fails on this PR, so the workflow is still red. In run 38987911586 the Generate SBOM job fails at the Generate CycloneDX SBOM step with npm error code ELSPROBLEMS and then Error: npm-ls exited with errors: 1 noSignal / exit code 254. The log has hundreds of missing:/invalid: lines, for example missing: @stackbilt/adf@file:.../packages/adf, required by charter@0.11.0 and invalid: @stackbilt/adf@1.9.3 .../packages/cli/node_modules/@stackbilt/adf. The root package.json declares npm workspaces, and pnpm's symlinked node_modules layout doesn't match what npm ls expects. The PR description calls this a "known risk" and says it would be "inherited from the upstream". It isn't a risk: it already happens on this PR, so the PR doesn't do what its title says. Before the change, Supply Chain failed in 0s with no jobs. After it, Supply Chain fails in about 20s with one red job, on every PR and every push to main. No SBOM is produced and no artifact is uploaded. Changing generators (for example cdxgen) or passing --ignore-npm-errors (which risks an incomplete SBOM, so check the output) belongs in this PR, not a follow-up.

2. [NON-CRITICAL] .github/workflows/supply-chain.yml:22-23 — outputs.sbom-sha256 is dead. No downstream job uses it, and the receipt steps that consumed it upstream were deliberately removed. Remove it, or say what is meant to use it.

3. [NON-CRITICAL] .github/workflows/supply-chain.yml:59 — dependency-review-action v4.9.0 is out of date and runs on deprecated Node 20. The pin is correct: v4.9.0 resolves to 2031cfc0.... But v5.0.0 came out on 2026-05-08, and the run logs Node.js 20 is deprecated ... being forced to run on Node.js 24: actions/dependency-review-action@2031cfc....

4. [NON-CRITICAL] .github/workflows/supply-chain.yml:4-5 — the comment "Action pins follow ci.yml" is only partly true. ci.yml has checkout, pnpm/action-setup and setup-node. The upload-artifact pin comes from governance.yml:112. dependency-review-action is pinned nowhere else, so it is a new pin, not a copied one.

5. [NON-CRITICAL] .github/workflows/supply-chain.yml:34 — npx --yes @cyclonedx/cyclonedx-npm@4.2.1 pins only the top-level package. Its transitive dependencies resolve fresh on every run, with no lockfile and no integrity check. The run shows deprecation warnings for tar@6.2.1, glob@10.5.0 and prebuild-install@7.1.3. That is a weak spot for a supply-chain job. If you keep this tool, consider installing it as a locked devDependency.

Claims verified as true

• The 0s "workflow file issue" failures are real. The main push run 38982493104 has jobs: [] and started and finished at the same timestamp, and failures go back to at least 2026-08-24T17:15Z. The stackbilt_llc repo is private.
• Every action SHA matches the tag it claims: checkout v7.0.1 = 3d3c42e5, pnpm/action-setup v6.0.10 = 0977fd99, setup-node v7.0.0 = 82076278, upload-artifact v7.0.1 = 043fb46d, dependency-review-action v4.9.0 = 2031cfc0.
• Dependency review runs and passes (8s), so the dependency graph is enabled. Dropping pull-requests: write is fine because comment-summary-in-pr defaults to never.
• Permissions are contents: read at the workflow level and on each job. No secrets are used.
• pnpm resolves to v9.15.9 through packageManager, and pnpm install --frozen-lockfile --ignore-scripts succeeds.
• Nothing sensitive is newly exposed. The private repo name was already public in the old file, which this PR removes.

Local tests

On the base commit, which differs from the PR only in this workflow file: 1415 passed and 3 failed. All 3 failures assert path separators ('.ai\context.adf' vs '.ai/context.adf') and fail only on a Windows host. They are pre-existing and unrelated to this PR. CI build-and-test passes.

Scores

Category	Score	Notes
Security	3	Pins verified, permissions minimal, no secrets
Correctness	1	SBOM job fails on this PR
Error handling	2	No fallback or diagnostics for the npm-ls failure
Test coverage	1	The PR's own CI shows the change doesn't work
Style	2	Dead output, comment overstates where pins came from

Verdict: NEEDS FIX