Skill Security Model Conventions

July 3, 2026 · View on GitHub

Every skill that ships an executable runtime (network egress, credential handling, subprocess execution, or untrusted document/content parsing) carries a SECURITY.md STRIDE threat model next to its SKILL.md. These models mirror the repo-wide model at docs/security/security-model.md and are registered in its Skill Security Models section. The canonical exemplars are .github/skills/experimental/mural/SECURITY.md, .github/skills/jira/jira/SECURITY.md, and .github/skills/gitlab/gitlab/SECURITY.md. The fill-in template is docs/templates/skill-security-model-template.md.

Required Structure

A conformant skill SECURITY.md contains, in order:

  1. Frontmatter: title (" Skill Security Model"), description, author: microsoft/hve-core, ms.topic: reference, ms.date, keywords, and an estimated_reading_time; followed by <!-- markdownlint-disable-file --> and the H1.
  2. An intro paragraph naming the runtime files and trust-bucket decomposition, stating that each bucket enumerates all six STRIDE categories.
  3. A "See also: repo-wide STRIDE model" callout linking docs/security/security-model.md.
  4. ## Executive Summary with a ### Security Posture Overview table.
  5. ## Contents (anchored table of contents).
  6. ## System Description with a ### Components list and a ### Data Flow mermaid flowchart TD whose subgraphs are trust zones and whose edges are labeled with protocols.
  7. ## Trust Boundaries with a ### Boundary Diagram (ASCII box diagram) and a ### Boundary Descriptions table.
  8. ## Assets (A1…) and ## Adversaries (ADV-a…) tables.
  9. One ## Bucket B1…Bn section per trust bucket (there is no umbrella ## Trust Buckets heading). Each bucket enumerates all six STRIDE categories as ### headings in canonical order (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), using an explicit "Not applicable. ." where a category does not apply, and ends with a ### Risk Rating table (Threat / Likelihood / Impact / Residual Risk / Status).
  10. ## Enterprise Readiness Gaps register.
  11. ## References.

Gap Register Rules

  • Gap IDs use the form G-{TOKEN}-{N}, scoped per file (IDs may repeat across skills). Tokens are STRIDE-aligned: SPF, TAM, REP, INF, DOS, EOP, plus SUP (supply chain) and TLS (transport) specials. Do not use skill-letter or topic prefixes (for example A-, T-, SSRF, BRWS).
  • The Severity column uses a bare {Category}-{Level} token (for example InfoDisc-Med, EoP-High, SupplyChain-Med); qualifiers belong in the Gap or Status prose, not the Severity cell.
  • When a gap traces to a cross-skill audit finding, retain an (audit: <old-id>) parenthetical in the Gap prose.

Content Integrity Rules

  • Derive every diagram node, edge, asset, adversary, mitigation, and risk rating from the skill's actual runtime. Never invent threats, mitigations, or ratings.
  • Cite public links only. Never reference internal .copilot-tracking/ paths or other gitignored locations in a shipped SECURITY.md.
  • When adding or materially changing a skill's runtime surface, update the registry table and "Primary residual gaps" prose in docs/security/security-model.md#skill-security-models.
  • Treat any externally fetched content (API responses, document text, tool output) as untrusted data, consistent with the repository untrusted-content boundary.