[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	3a47a50

[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.

[s1ns3nz0]

Rebased on current develop and did the thinning we discussed, now that DTI has landed via #616. Both in 3a47a50.

The five-gate "Screen before execution" section is gone. handling-untrusted-code owns the procedure, so this page now points at it and at developer-machine-sandboxing for the environment, instead of running a second version of the same steps.

What stayed are the two decisions that are approvals rather than handling steps, as flagged earlier:

• Approving dependencies and tools into the allowlist, including package names proposed by AI tools, and pinning MCP servers and model revisions
• Comparing model artifacts against reviewed source before an approval records the artifact as reviewed

Reciprocal Further reading added in both directions: this page links to the DTI overview, handling-untrusted-code, and execution-paths; those first two link back here for allowlists, MCP and package approval, and exception evidence. The IDE page's link to this page moved into its Further reading section, since #616 restructured the numbered list it used to sit in.

Net effect on the page is -33/+32 lines, so it did not grow.

validate:content passes on both supply-chain (7) and developer-targeted-intrusions (3), markdownlint and cspell clean, docs:build passes.

Left the title as is for now. Happy to retitle toward the governance framing if you still think it oversells the intake side, but with the procedure section gone the page reads as governance already.

[mattaereal]

@frameworks-volunteer, review it again, and does this have an overlap with the latest inclusion on devsecops by blackbigswan/shortdoom?

[frameworks-volunteer]

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

Re-review (post-3a47a50) + blackbigswan/shortdoom overlap

Verdict: Request changes (small IA wording fixes)

Content quality is solid. The intentional split with DTI is mostly right after the thinning commit. Blocking issue is residual copy that still claims this page owns pre-execution screening/intake, which contradicts the agreed handoff to blackbigswan’s DTI pages and will re-create the overlap in the nav graph.

---

Overlap with latest DevSecOps by blackbigswan / shortdoom

What landed: Developer-Targeted Intrusions under DevSecOps (wrote: [blackbigswan], GitHub shortdoom), via #610 content merged through #616:

• /devsecops/developer-targeted-intrusions/overview
• execution-paths
• handling-untrusted-code
• IDE page expansion + confinement cross-links

Split (correct, keep it):

Concern	Owner
Threat model, execution boundaries, operator intake procedure, compromise response	DTI (blackbigswan)
Tool/vendor governance lifecycle, managed allowlists + exception evidence, MCP/package/model approval, baseline org checklist, dated incident → governance lessons	#600 (this PR, Supply Chain)
How to confine the laptop/agent	Developer Machine Confinement

After 3a47a50: the five-gate “Screen before execution” restatement is gone. The short pointer to handling-untrusted-code + the two approval decisions (allowlist/deps/tools; model-artifact comparison) is the right shape. Reciprocal Further reading on the main page and on DTI overview / handling is good.

Remaining topic adjacency (OK if ownership language is clean): Workspace Trust, install-script blocking, disposable credential-free envs, restricted egress, MCP config as executable, credential separation. DTI states these as operator procedure; this page as org-enforced baseline / approval inventory. That is complementary, not duplicate — as long as outbound blurbs do not reassign the procedure here.

No need to fold unique #600 material (lifecycle, allowlist schema, MCP/package governance, slopsquatting, model artifacts, example table) into the DTI family.

---

Must-fix: residual “owns screening/intake” claims

These still tell readers this page owns the procedure DTI owns:

1. docs/pages/ai-security/overview.mdx — “owns pre-execution screening and allowlisting…”
   Prefer: governance / allowlisting / approval of plugins, MCP, agent rules, model artifacts (link DTI for screening procedure).

2. docs/pages/dprk-it-workers/techniques-tactics-and-procedures.mdx — “owns the pre-execution intake and confinement controls…”
   Prefer: points to DTI handling + confinement for intake/isolation; this page for tool/repo approval governance if needed. Do not assign intake+confinement ownership here.

3. docs/pages/opsec/endpoint/overview.mdx — “owns the pre-execution screening boundary…”
   Prefer: governance of which repos/tools/deps/models are approved on managed endpoints; screening procedure stays on DTI handling.

4. docs/pages/supply-chain/overview.mdx — “Establish the pre-execution intake and screening boundary…”
   Prefer: govern external development inputs (tools, MCP, deps, models) at the workstation; link DTI for the operator screening procedure.

5. Page frontmatter description + key takeaway still lead on “Screen … before execution” / intake framing. After thinning, lead on governance of external development inputs; keep a one-line handoff to DTI for the screen/isolate procedure.

6. Checklist closer — “This checklist defines the intake baseline.” Prefer governance / workstation-control baseline (intake procedure lives on DTI).

Optional (non-blocking): retitle or subtitle toward governance if you still want less “workstation security = intake runbook” reading; not required once blurbs/description match the split.

---

Security review

• No secrets, tokens, or unsafe executable content.
• External links look legitimate (AWS bulletin, Snyk, GitHub advisory, USENIX, MCP/SLSA/npm/PyTorch docs).
• Incident table correctly separates PolinRider (workspace automation) from extension-publishing paths.
• Detect/respond section scopes to signals + handoff into existing Supply Chain IR / Malware playbooks — good, does not fork incident process.
• MCP and model formats treated as executable — aligned with DTI and AI Security.

QA review

• Sidebar: vocs.config.ts entry present with dev: true; supply-chain index + overview updated.
• Contributor slug s1ns3nz0 registered in contributors.json.
• Frontmatter reviewed / fact-checked still empty — expected until a human reviewer is tagged.
• RFC must/should modality on the checklist matches style guidance.
• CI green on current head.
• Cross-links to DTI paths are real on current develop (post-#616).
• Net page size stayed bounded after thinning (−33/+32 as author noted).

---

Recommendation

Keep under /supply-chain/. Do not relocate into DevSecOps/DTI. Fix the six ownership/framing items above so the nav graph matches the post-thinning architecture, then this is ready to approve from the bot side.

Happy to re-review the wording pass quickly once pushed.

[s1ns3nz0]

Closing this one for now.

The overlap question has come up twice, first against DTI and now against the newer DevSecOps material, and each round has been a patch on top of a page whose scope I hadn't settled first. Rather than keep thinning it against whatever lands next, I'd like to step back, work out what actually belongs on a workstation governance page once the DevSecOps side has stopped moving, and open a fresh PR with that scope.

The branch stays on my fork so nothing here is lost, and the reciprocal links into the DTI pages can come back with the new version.

Thanks @scode2277 and @mattaereal for the review time. Thank you for your help!