docs(devsecops): add developer-targeted intrusion guidance

[mattaereal]

What does this PR change?

Adds a dev-only Developer-Targeted Intrusions section under DevSecOps, based on the source guide Developer-Targeted
Intrusions: The Execution You Didn't Know You Triggered.

The source is approximately 4,862 words across 13 major sections. The repository content model recommends splitting
pages with more than five or six top-level sections, so this PR converts it into a focused three-page family:

1. Overview — social lures, four execution boundaries, explicit versus passive-looking operations, and mutable trust.
2. Execution Paths in Untrusted Code — source hooks, Git behavior, IDE automation, containers, Terraform,
   smart-contract toolchains, and AI coding agents.
3. Handling Untrusted Code — intake, isolated retrieval, inspection, constrained first execution, update
   revalidation, and suspected-compromise response.

It also expands the existing IDE page, adds a reciprocal link from Developer Machine Confinement, updates the DevSecOps
page map, and registers the new pages in the sidebar with dev: true.

Related to #48.

Placement decision

This belongs under DevSecOps, not as a new top-level framework and not under /guides.

• The threat enters through developer workflow boundaries: repository intake, Git, IDEs, build tools, containers,
  infrastructure tooling, and AI coding agents. DevSecOps owns those controls.
• /guides is primarily for product or platform hardening. This contribution combines a cross-tool threat model with
  an operational procedure.
• A separate top-level framework would duplicate existing DevSecOps, Supply Chain Security, AI Security, OpSec, DPRK IT
  Workers, and Incident Management material.
• The nested overview provides a stable landing page if the section grows later without prematurely creating another
  top-level framework.

How it complements existing frameworks

Existing framework or page	Existing ownership	Contribution from this PR
Supply Chain Security	Dependency, build, release, and vendor integrity	Initial developer-targeted delivery and first-contact execution boundaries
Integrated Development Environments	Editor-specific security	Workspace Trust, folder-open tasks, executable tool paths, VSIX handling, extensions, and previews
Developer Machine Confinement	Agent and dev-container confinement	The intake decision and threat model that determine when confinement is required
AI Security	General prompt injection and agent policy	Repository-borne instructions and agent tool use during external-code intake
DPRK IT Workers	Fraudulent worker identity and organizational access	Code-lure outreach without reducing the threat to one actor or recruiting scenario
Incident Management	Organization-wide response and recovery	Developer-endpoint triggers and immediate escalation into existing playbooks

Technical accuracy changes from the source draft

• Plain clone, pull, checkout, and folder-open operations are not described as universally executing repository code.
  The text identifies the vulnerability, recursive submodule, configured filter or hook, trusted workspace automation,
  framework loader, extension, or agent tool call that crosses the boundary.
• CVE-2024-32002 is scoped to recursive clones under specific filesystem conditions and links to the Git advisory.
• .gitattributes is described as selecting a filter whose executable clean or smudge command lives in Git
  configuration.
• Ordinary clones are not described as copying repository files into .git/hooks.
• terraform init is described as downloading and installing providers; provider execution is distinguished from later
  validation, planning, refresh, and apply operations.
• VS Code folderOpen tasks are qualified by Workspace Trust and automatic-task permission.
• AI-agent risk is tied to instruction handling and tool invocation rather than claiming that repository text executes
  by itself.
• Containers are described as confinement, with privileged mode, sockets, forwarded agents, and host mounts called out
  as boundary failures.

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

Attribution

• New DTI pages: wrote: [blackbigswan], reviewed: [mattaereal]
• IDE rewrite: prior writers retained (mattaereal, fredriksvantes, ElliotFriedman) plus blackbigswan; reviewed: [mattaereal]
• DevSecOps overview map update: wrote: [], reviewed: [mattaereal] (map-only edit; no new author)
• Contributor slug confirmed in docs/pages/config/contributors.json (blackbigswan → GitHub shortdoom)

Validation

• Local validation commands (pnpm/just/cspell/markdownlint/validate:content/build) were intentionally
  skipped per operator instruction for this handoff run
• git diff --check: passed
• Authored pages and sidebar registration were applied from the handoff package; generated indexes were written to the
  expected build output because the build step was not run
• Title suffix within the DTI family aligned to | SEAL

Reviewer focus

• Whether the DevSecOps nesting and three-page split are the right long-term information architecture
• Technical wording around Git filters and hooks, Terraform provider installation versus execution, Workspace Trust,
  and agent tool boundaries
• Whether the response checklist should remain here or link more aggressively into Incident Management
• Whether any campaign-specific examples from the source should be restored after independent fact-checking

[github-actions]

Sidebar Configuration Reminder

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

• docs/pages/devsecops/developer-targeted-intrusions/execution-paths.mdx (added)
• docs/pages/devsecops/developer-targeted-intrusions/handling-untrusted-code.mdx (added)
• docs/pages/devsecops/developer-targeted-intrusions/index.mdx (added)
• docs/pages/devsecops/developer-targeted-intrusions/overview.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.}

[cloudflare-workers-and-pages]

Deploying frameworks with    Cloudflare Pages

Latest commit:	36e767b
Status:	✅  Deploy successful!
Preview URL:	https://3813cb7c.frameworks-573.pages.dev
Branch Preview URL:	https://content-developer-targeted-i.frameworks-573.pages.dev

View logs

[frameworks-volunteer]

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

Security

No issues. Docs-only PR; no secrets, injection vectors, or unsafe tooling. Technical boundaries are carefully scoped (plain clone/checkout not universal execution; CVE-2024-32002 recursive-clone conditions; .gitattributes selects filter name, executable lives in Git config; terraform init install vs later provider execution; Workspace Trust + automatic tasks; containers as confinement with mount/socket callouts; agent risk via tool invocation). Credential-free retrieval and disposable isolation guidance are sound.

QA

• Placement under DevSecOps + three-page split matches the stated content model and complements Supply Chain, IDE, confinement, AI Security, DPRK IT Workers, and Incident Management without duplicating them.
• Frontmatter, contributors (blackbigswan wrote / mattaereal reviewed; IDE prior authors retained), and blackbigswan registry entry look correct.
• Internal links resolve; vocs.config.ts registers the section with dev: true; reciprocal links from IDE and Developer Machine Confinement are present.
• CI green (4 checks). No TODOs/placeholders. Procedure modality (must/should/may) and ordered checklists are clear and actionable.
• Compromise response appropriately escalates into Incident Management rather than inventing a parallel IR framework.

Nits (non-blocking)

1. Title suffix inconsistency in the new family: handling-untrusted-code.mdx uses | Security Alliance while overview.mdx and execution-paths.mdx use | SEAL. Both patterns exist in the repo; pick one within this section for polish.
2. Auto-generated index title: index.mdx is Developer Targeted Intrusions (no hyphen) vs hyphenated elsewhere — expected if generated from the folder name; fine unless you want the folder renamed.
3. Overview map attribution: DevSecOps overview map edit attributes wrote: [blackbigswan] on a page that previously had empty writers. Intentional per PR body; just flagging in case maintainers prefer additive reviewed only for map-only edits.

Verdict

Approve. Strong threat model, accurate trigger wording, and a usable intake procedure. Nits above are cosmetic only.

[scode2277]

Lgtm. Just changed a sentence in execution-paths that referred to the list above as questions, but the items are statements.

gtg for me @mattaereal!

[AllyPry]

Looks really great nothing to add from my side. Maybe just one small suggestion regarding the compromise response section.

[ElliotFriedman]

Thematically, this is really solid!

If there were razors, or smaller distillations that could help someone follow these rules that condensed the checklist, it would probably go a long way to increasing compliance.

Three themes mentioned are time pressure, verification through separate channels and code and environment isolation. If this could be condensed and added into the overview, saying these are the core principles that if followed greatly reduce your risk, it would likely help reduce cognitive overhead and thus compliance for these rules.

If a developer is under time pressure to install a new piece of software, this should be a flag in and of itself where they stop.

If verification attempts from the requester doesn't pass through multiple channels, this should also be a flag and they should attempt to call the contact that requested the install if within their organization.

Isolation is crucial for running untrusted code, do not run anything on your computer from an untrusted source unless it's in a docker container with its egress restricted and ports closed.

[frameworks-volunteer]

Model: glm-5.2 Reasoning: medium Provider: openrouter

Addressed the review feedback in PR #616:

1. Core principles in overview (@ElliotFriedman's suggestion): added a three-point quick-reference — treat time pressure as a warning sign, verify through multiple channels, isolate untrusted code. Positioned as the minimum bar when there's no time for the full procedure, with a link from handling-untrusted-code so it's visible where the checklist lives.

2. Private key / seed phrase coverage (@AllyPry's suggestion): expanded the compromise response checklist item to explicitly call out wallet private keys and seed phrases — if the endpoint had access, migrate assets to a new wallet from a clean device since revoking the session alone may not prevent theft.

PR #616 targets develop with the same base as this PR. Happy to rebase onto this branch instead if that's preferred for merging.

[mattaereal]

@frameworks-volunteer please review your PR 616, based on this thread's suggestions/discussion, and apply any clarifications/changes you'd add to that one directly sharing a summary here.

[frameworks-volunteer]

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

Self-review of PR #616 (from #610 thread)

Re-read #610 suggestions from @ElliotFriedman and @AllyPry against the #616 feedback commit, then pushed one clarification commit on the #616 head (61fdc12).

Already correct (no change needed)

• Core principles section in overview matches Elliot's three razors: time pressure, multi-channel verification, isolation.
• Under-pressure callout near the top of handling-untrusted-code links to #core-principles.
• Private key / seed phrase exposure is covered in compromise response (AllyPry).
• CI was green on the prior tip; docs-only, no security issues.

Clarifications applied on #616

1. Isolation principle tightened (Elliot): principle 3 now explicitly requires restricted egress, no unnecessary open ports, and no inherited credentials — closer to the docker-with-egress-restricted-and-ports-closed razor.
2. Under-pressure callout mirrored those isolation specifics so the digestible path does not drop them.
3. Seed-phrase migration split into its own checklist item (AllyPry): rotation stays one bullet; key/seed migration is a separate checkbox so it cannot hide inside a long rotation sentence under stress.

Left alone on purpose

• Did not invent org "policy on work computers" text beyond the existing "teams must provide a sanctioned disposable environment" requirement — that already answers the policy/availability half of Elliot's digestibility note without scope-creeping into IAM/platform pages.
• Did not rebase docs(devsecops): address DTI review feedback (core principles, key exposure) #616 onto docs(devsecops): add developer-targeted intrusion guidance #610; both still target develop. Prefer merge order docs(devsecops): add developer-targeted intrusion guidance #610 then docs(devsecops): address DTI review feedback (core principles, key exposure) #616, or squash if you want a single history.

Verdict on #616

Approve the feedback delta. Thread suggestions are reflected; clarifications above are polish only.

Details also posted as a review on #616.

[mattaereal]

Closing this one as this has alreavy been merged on an updated PR