docs(supply-chain): add developer workstation security guidance

[s1ns3nz0]

What does this PR change?

Adds a developer-workstation security guide that treats repositories, IDE configuration, AI tools, MCP servers, dependencies, and model artifacts as software supply-chain inputs before execution.

The guide covers:

• governance of external development tools through request, risk review, approval, managed deployment, monitoring, reassessment, and removal
• managed allowlists, time-limited exceptions, and inspectable compliance evidence
• pre-execution screening and confined evaluation environments
• endpoint baselines, detection, incident response, and an interactive checklist
• dated, directly sourced examples covering repository automation, extension publishing, MCP packages, dependency compromise, and AI package hallucination

It also links the guidance from Supply Chain, AI Security, DevSecOps IDE, Endpoint Security, and DPRK IT Worker pages, and registers the author and navigation entry.

Type of change

• New content
• Edit to existing content
• Outline / structure change
• Typo or formatting fix
• Tooling / config

If applicable

• Editing existing content: tagged the current contributors from the attribution list
• Framework has a steward: asked them to review
• Outline change: updated vocs.config.ts with the dev: true parameter
• Want community feedback: shared this PR in our Discord

Verification

• pnpm exec just lint
• pnpm run docs:build
• CSpell and targeted supply-chain validation
• Interactive checklist and rendered links verified locally
• All contribution commits are signed

[github-actions]

Sidebar Configuration Reminder

This PR includes added, renamed, or removed documentation files:

• docs/pages/supply-chain/developer-workstation-security.mdx (added)

Please ensure that:

• The sidebar in vocs.config.ts has been updated to include these files
• New content has the dev: true parameter so it's marked as under development
• Sidebar links match the file paths - use the preview deployment to verify

See Contributing Guide – Sidebar & Navigation for more details.

---

_{This is an automated reminder. If this PR doesn't need sidebar changes, you can ignore this message.}

[s1ns3nz0]

Small self-review while this waits: applied RFC modality to the baseline checklist in 97f5a24, matching the normative modality rules in docs/pages/contribute/style-and-terminology.mdx.

Items required for the control to hold take must; the four with valid organizational exceptions — review cadence, install-script blocking, obfuscation detection, and endpoint management coverage — take should.

I also checked this page against the second-person feedback from #592 and it was already clean, so no changes needed there.

validate:content 7 passed / 0 failed, markdownlint and cspell clean, docs:build passes. Branch is rebased on current develop and conflict-free.

[scode2277]

Reviewing this PR right after #610, I've noted some clear overlap. Both PRs cover developer workstation security and isolation. They do split in the end, this one into governance, allowlisting, MCP servers and package hallucination while #610 into the execution mechanisms and safety model. But the intake procedures are close to parallel, and both cover install scripts, restricted egress and disposable credential-free environments.

Since #610 already adds a whole new subsection under DevSecOps, do we want to move what is unique here (the tool governance lifecycle, MCP servers,the incident examples, etc.) into that family as another page, or keep this page steering it further in the governance direction so the two stop overlapping?

@s1ns3nz0 no concerns about the work itself, purely an architecture question from two contributions landing close together.

@mattaereal @shortdoom @s1ns3nz0 @frameworks-volunteer lmk what you think about this

[frameworks-volunteer]

Model: x-ai/grok-4.5 Reasoning: high Provider: openrouter

Architecture take: keep both pages, sharpen the split, do not fold #600 into the DevSecOps DTI family.

Why keep #600 under Supply Chain

• docs(devsecops): add developer-targeted intrusion guidance #610 already defines the split well: DevSecOps / DTI owns first-contact execution boundaries and the operator procedure; Supply Chain owns dependency, vendor, and integrity governance. docs(supply-chain): add developer workstation security guidance #600's durable value is the latter — tool governance lifecycle, managed allowlists + exception evidence, MCP as an executable vendor, package hallucination / slopsquatting, model artifacts, and the dated incident table.
• That content serves a different control plane (security eng, platform, procurement, compliance) than DTI's operator-facing intake runbook. Moving it under DevSecOps collapses those audiences and duplicates docs(devsecops): add developer-targeted intrusion guidance #610's nesting rationale.

What is actually overlapping

• Intake / screen-before-execution steps
• Disposable credential-free environments, restricted egress, install-script blocking, Workspace Trust language

Those should live once. Prefer #610 handling-untrusted-code as the canonical procedure (safety model + ordered steps + compromise response). #600 should keep a short gate summary and link out, not restate the full procedure.

Recommended shape for #600

1. Keep under /supply-chain/, optionally tighten the title/framing toward governance of external development inputs (tools, MCP, deps, models) at the workstation boundary.
2. Keep and lead with: governance lifecycle, allowlist inventory fields, inspection evidence, MCP / AI-package / model controls, baseline checklist (org-enforced), detect/respond signals, incident examples.
3. Thin the parallel intake section to a short ordered list + hard link to DTI handling + Developer Machine Confinement for implementation.
4. Add reciprocal Further reading both ways once both land:
   • docs(supply-chain): add developer workstation security guidance #600 → DTI overview / handling-untrusted-code / execution-paths
   • docs(devsecops): add developer-targeted intrusion guidance #610 → this page for allowlists, MCP/package governance, and the example table
5. Do not relocate unique docs(supply-chain): add developer workstation security guidance #600 material into the DTI subsection; that would bury governance content inside a threat-model family.

Merge order

Either order works if cross-links land in a small follow-up. Prefer landing #610 first only if #600 will immediately thin its intake section against the DTI URLs; otherwise land #600 as-is under Supply Chain and open a tiny follow-up PR for dedupe + links after both merge.

No content-quality objection from this pass — question is IA only, same as @scode2277 framed it. Happy to do a full security/QA review on the current #600 diff next if wanted.

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
frameworks	✅ Ready (View Log)	Visit Preview	97f5a24

[s1ns3nz0]

Thanks both. No objection to the framing; the overlap is real and I'd rather fix it than defend it.

Agreed with the split @frameworks-volunteer described: #610 owns the intake procedure, this page owns governance of external development inputs. Comparing the two diffs, the duplicated material is almost entirely my "Screen before execution" section, five numbered gates over about 35 lines. Gates 1, 2, 3 and 5 run parallel to handling-untrusted-code's Verify before retrieval → Retrieve in isolation → Inspect before tool execution → Execute with bounded capabilities. #610 is the better home for that: it carries the safety model and the compromise-response steps, which this page does not.

Two pieces of that section I'd keep rather than fold away, because they're governance and #610 doesn't cover them:

• Gate 4, approve dependencies and tools. Resolving package names against the expected registry and publisher, including names proposed by AI tools; confirming the item against the managed allowlist; pinning MCP servers and model revisions. That's an approval decision, not an intake step.
• Model artifact comparison in gate 3, checking a packaged model against reviewed source and provenance. I grepped docs(devsecops): add developer-targeted intrusion guidance #610 and found no coverage of model artifacts, slopsquatting, or AI package hallucination.

So the shape I'd propose matches @frameworks-volunteer's recommendation: keep this page under /supply-chain/, lead with the governance lifecycle, and replace gates 1/2/3/5 with a short ordered summary that hard-links to handling-untrusted-code for the procedure and developer-machine-sandboxing for implementation.

On sequencing, I'd rather land #610 first and do the thinning here as a follow-up commit on this branch, so the cross-links point at real URLs instead of anticipated ones. If you'd prefer #600 to go first I can do it the other way, but then the links wait for a follow-up PR either way.

@scode2277 let me know which you'd like and I'll turn it around quickly. I can also retitle toward the governance framing if the current title oversells the intake side.