Generated banner for Security Planning
Generated logo for Security Planning

Security Planning

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Security
  • MIT
  • Medium risk
  • Has scripts

From the author

Security planning and plan-drift analysis for STRIDE, standards, controls, backlog handoff, current findings, and TM7 generation.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Security Planning provides a structured framework for managing application security throughout the development lifecycle. It includes methodologies for STRIDE threat analysis, NIST control mapping, and data classification. The skill supports plan-drift analysis to correlate security baselines with current findings, and provides robust workflows for generating and validating Microsoft Threat Modeling Tool (TM7) files, including an optional Windows-native feedback loop for visual model validation.

What it does

  • Classifies application components into operational security buckets.
  • Performs STRIDE-based threat analysis with support for AI-specific extensions.
  • Maps security findings to industry standards and NIST control families.
  • Generates security-focused backlog items for implementation handoff.
  • Analyzes plan-drift by comparing security baselines against current repository findings.
  • Automates the generation of TM7 threat models and associated markdown reports.

When to use it

  • When performing initial security planning or threat modeling for an application.
  • When you need to reconcile an existing security plan with current audit or code review findings.
  • When preparing security-related work items for a development backlog.
  • When generating or updating TM7 threat model files for compliance or audit workflows.

Advantages

  • Provides a consistent, repeatable methodology for security planning and threat modeling.
  • Reduces manual effort in mapping security findings to regulatory standards.
  • Enables automated detection of drift between planned security controls and actual implementation.
  • Supports both portable markdown reporting and native integration with the Microsoft Threat Modeling Tool.

Usage examples

“Analyze my application components and generate a security backlog based on the current STRIDE findings.”
The agent will classify the components into operational buckets, perform a STRIDE analysis, and output a prioritized list of security work items formatted for your backlog.
“Compare my existing security baseline with these new code review findings to identify control drift.”
The agent will correlate the findings, filter out excluded paths, and produce a report detailing validated controls, residual risks, and any identified control drift.
“Generate a TM7 threat model file from my current YAML threat-model specification.”
The agent will process the specification and output a .tm7 file compatible with the Microsoft Threat Modeling Tool, along with a corresponding markdown report.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/security-planning/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip security-planning.zip -d .agents/skills

Documentation by Microsoft

Security Planning

This skill packages durable security-planning and plan-drift analysis used by Security Planner, Security Reviewer, and Code Review: operational bucket guidance, STRIDE analysis patterns, standards cross-references, NIST control-family references, security-specific backlog formats, and correlation of a Security Planner baseline with current security findings.

When to use

Use this skill when you need to:

  • Classify application components into the operational security buckets used during planning.

  • Evaluate threats with STRIDE-based analysis, including AI-specific extensions when raiEnabled is true.

  • Map bucket findings to standards references and control families without re-embedding long standard tables.

  • Derive security-specific backlog priorities and RAI work item categories for Phase 5 handoff.

  • Correlate a Security Planner baseline with caller-supplied current findings to identify validated controls, control drift, residual planned risks, newly introduced threats, and obsolete plan items.

  • Generate a dual-output TM7 model plus markdown report from a YAML/JSON threat-model spec for human-reviewed audit workflows.

Security plan drift analysis

Use the drift capability when a Security Planner baseline and current-state security findings already exist. It correlates supplied evidence only: it does not scan, profile, select security skills, verify findings, re-rate severity, invoke another agent, or modify source, plan, reviewer, backlog, or state artifacts.

  1. Resolve and extract the baseline through drift-input-contracts.md.

  2. Normalize caller-supplied audit, diff, or Code Review findings without treating plan-mode evidence as repository state.

  3. Filter default exclusions, then classify only conclusions supported by drift-comparison-model.md.

  4. Render the direct, Security Reviewer, Security Planner, or Code Review adaptation from drift-report-contract.md.

  5. Use drift-worked-examples.md for deterministic behavior scenarios and expected category suppression.

Before full conversational or durable drift output, display the Security Planning CAUTION block in this skill verbatim. Report the default exclusions below in the canonical body's Current repository evidence section. A bounded Code Review section may point to these blocks because its containing review already carries the Code-Review disclaimer.

Default exclusions in effect. Planning and agent-customization artifacts are excluded from drift findings:

  • Paths: .copilot-tracking/**, docs/planning/**, docs/adrs/**, .github/agents/**, .github/prompts/**, .github/instructions/**, .github/skills/**

  • File globs: *.prompt.md, *.agent.md, *.instructions.md, SKILL.md

To override, pass scope= explicitly. Overlapping user scope wins and is reported as a warning.

A write-capable direct caller may create one sequence-safe report under .copilot-tracking/security-audits/<project-slug>/. Security Reviewer and Security Planner render in conversation. Code Review renders a bounded section and optional security_plan_drift field. Every destination keeps inputs read-only and recommends follow-up without dispatch.

Stop the affected conclusion when a baseline is incomplete, a required fact is unresolved, evidence scope does not cover the claim, or input format drift prevents exclusions. Report suppressed categories as insufficient evidence rather than zero findings. Stop the entire correlation when no baseline resolves or no finding location is available to enforce exclusions.

TM7 generation workflow

When the user asks for a TM7 threat model, the runtime can generate a .tm7 file and a matching markdown report from the same spec. The generator supports the pre-populated-comprehensive and diagram-only-defer-to-tmt modes and can update an existing model with --update. Use the generate_tm7.py and generate_markdown.py entry points with --template to select a profile.

The .tm7 output mirrors the Microsoft Threat Modeling Tool's real SerializableModelData DataContract and deserializes cleanly under the tool's own DataContractSerializer. Fidelity is validated against the tool's own assemblies by scripts/Deserialize-Tm7.ps1, which the pytest suite runs when the tool is installed and skips cleanly otherwise. See references/tm7-generation.md for the verified contract.

Native TM7 visual feedback workflow

The skill also supports an opt-in, Windows-local feedback loop for the native Microsoft Threat Modeling Tool UI. The feature is off by default. The generator and standard validator keep their existing portable behavior when the feedback flags are absent. Native feedback is enabled only when validate_tm7_with_tmt.py is run with --feedback-loop, --spec, and --overlay-output; optional --overlay-input, --max-iterations, and --require-feedback-evidence refine the execution contract.

The workflow requires Microsoft Threat Modeling Tool 7.3.51110.1, a Windows desktop session, and UI Automation access. The loop is bounded to a baseline run plus at most three refinement iterations, and defaults to a baseline plus one. A single run holds the mouse and keyboard continuously across the baseline and every refinement iteration; control returns only at the release notice. Replaying a corrected overlay is a new run and a new takeover. Exit codes, stop reasons, and the discovery-failure rules are defined in the generation reference.

The harness controls TMT windows and may open, close, and reopen the app for save/reopen validation. It emits a start notice before automation begins, progress updates for the baseline and each refinement candidate, and a release notice when the loop completes or aborts so the operator knows when control is returned. These are notices only; the harness does not block on operator acknowledgment. The agent-facing lockout and release obligations that surround a run are owned by references/tm7-generation-workflow.md.

The loop records one evidence bundle per run under the requested evidence directory, with per-iteration screenshots, UI Automation snapshots, summaries, and candidate models. A run that captured at least one surface and either passed the automated gates or stopped for layout exhaustion also emits agent-review-request.json at the bundle root. The overlay payload remains in approval_state: pending, and no runtime path or flag auto-promotes it to approved or rewrites the canonical baseline.

Scoring keeps deterministic geometry gates separate from advisory screenshot heuristics. Screenshot heuristics are not a semantic approval signal.

A Windows-native example uses the skill's locked Windows dependency group:

uv run --project "<security-planning-skill-root>" --group windows \
  python "<security-planning-skill-root>/scripts/validate_tm7_with_tmt.py" model.tm7 \
  --evidence-dir ./artifacts/feedback \
  --feedback-loop \
  --spec ./specs/model.yaml \
  --overlay-output ./artifacts/feedback/overlay.json \
  --max-iterations 3 \
  --require-feedback-evidence

Resolve <security-planning-skill-root> from the loaded skill location before running the command.

The overlay contract is versioned and deterministic. It carries layout intent in named rule collections and is invalidated unless its full fingerprint block matches, so a stale overlay is rejected rather than replayed onto a changed model.

See references/tm7-generation.md for the full CLI surface, exit codes, stop reasons, geometry thresholds, the evidence-bundle layout, the overlay fingerprint contract, and the operator runbook covering prerequisites, abort, recovery, and rollback.

Agent-assisted visual review

Some layout defects never reach a metric. TM7 persists no connector label geometry and UI Automation exposes no label element, so label collisions, unreadable label text, and visual crowding are invisible to the deterministic gates. An agent that reads the rendered screenshots can see them and author corrections into the overlay the harness publishes.

This review is a default step of every feedback-loop run, not an opt-in extra. A run that captured at least one surface and either passed the automated gates or stopped for layout exhaustion emits agent-review-request.json at the evidence root, carrying per surface the screenshot and UI Automation paths, the node and zone rectangles, the connector handle points, and the predicted label rectangles in model coordinates, plus the coordinate-translation constants and the port convention. The agent reviews from that payload rather than hand-parsing UI Automation trees. automated-ready-pending-human means the automated gates passed and the result awaits review; it is not an approval. The remedy remains documented rather than proven: it has not yet been demonstrated end to end on a real defect.

On the success path the published overlay addresses every captured surface, so a correction can be authored for any of them. When the run found no automated correction, that overlay is the seed shape, carrying an overlay-seed- identifier and empty rule collections. A layout-exhaustion stop publishes the same seed shape; a correctness or environment stop publishes nothing at all.

See references/tm7-generation.md for the protocol, the request payload, the accepted rule fields, the coordinate translation, and the constraints that bound an agent-authored overlay.

[!CAUTION] Disclaimer: This agent is an assistive tool only. It does not provide legal, regulatory, or compliance advice and does not replace professional security review boards, penetration testing teams, compliance auditors, legal counsel, or other qualified human reviewers. The output consists of suggested actions and considerations to support a user's own internal security review and decision‑making. All security plans, threat models, security models, and mitigation recommendations generated by this tool must be independently reviewed and validated by appropriate security and compliance reviewers before use. Outputs from this tool do not constitute security approval, compliance certification, or regulatory sign‑off.

The human-in-the-loop contract governing authorship confirmation, native feedback-loop operator safety, and layout overlay promotion is owned by references/tm7-generation-workflow.md. This skill owns the mechanics only.

Skill layout

Load the reference file that matches the phase or topic you need.

ReferenceTopic
references/00-index.mdNavigation catalog and consolidated attribution
references/operational-buckets.mdOperational bucket definitions, GS overlay, and classification guidance
references/stride-model.mdSTRIDE methodology, AI extensions, risk matrix, and data-flow analysis
references/standards-cross-reference.mdBucket-to-standards mapping table and component mapping output format
references/nist-control-families.mdNIST 800-53 priority tiers and NIST AI RMF subcategory mappings
references/backlog-formats.mdSecurity-specific prioritization and RAI work item categories
references/data-classification.mdPublic-safe data-classification taxonomy, tiers/categories/retention, and schema mapping
references/threat-model-review.mdThreat-model completeness checklist, PASS/INCOMPLETE verdict, and gap list
references/drift-input-contracts.mdSecurity Planner baseline extraction, normalized current-finding forms, evidence scope, and drift handling
references/drift-comparison-model.mdExclusions, evidence preconditions, five plan-drift categories, matching order, and recommendation-only handoffs
references/drift-report-contract.mdCanonical body and direct, Security Reviewer, Security Planner, and Code Review destination adaptations
references/drift-worked-examples.mdSynthetic complete, incomplete, malformed, diff-scoped, exclusion, and caller-regression behavior scenarios
references/tm7-generation-workflow.mdHuman-in-the-loop contract for TM7 generation: authorship confirmation, native feedback-loop operator safety, and layout overlay promotion
references/tm7-generation.mdTM7 input schema, dual-output generation contract, profile mapping, emission contract, native feedback loop, overlay and fingerprint contract, and operator runbook

Bundled executable and data resources:

ResourceUse
scripts/generate_tm7.pyRun to build a .tm7 from a threat-model spec
scripts/generate_markdown.pyRun to render the same spec as a markdown report
scripts/generate_tb7.pyRun to emit a template file
scripts/validate_tm7_with_tmt.pyRun for native Windows TMT validation and the opt-in feedback loop
scripts/Deserialize-Tm7.ps1Run to check round-trip fidelity against the tool's own assemblies
assets/schemas/tm7-layout-overlay.schema.jsonRead as the layout overlay schema
assets/schemas/tm7-agent-review-request.schema.jsonRead as the agent visual-review request schema
assets/schemas/tm7-visual-feedback-manifest.schema.jsonRead as the evidence manifest schema
templates/threat-model-spec-example.yamlCopy as the starting point for a new spec

The skill ships public defaults for the taxonomy and the completeness checklist. Organization-specific internal details such as internal data-type taxonomies, internal auth service names, and internal review-gate steps are supplied through a private config overlay referenced by state.overlayConfigPath and are never embedded in the public skill.

Attribution

The durable reference content in this skill is organized by reference file and summarized in references/00-index.md. See that index for the consolidated attribution and delegation notes.

Files

scripts/Deserialize-Tm7.ps1

#!/usr/bin/env pwsh
# Copyright (c) 2026 Microsoft Corporation. All rights reserved.
# SPDX-License-Identifier: MIT
# No #Requires -Version directive: the TMT assemblies are 32-bit and load only
# under the SysWOW64 Windows PowerShell 5.1 host, which this script re-launches
# itself into. A 7.4 floor would make that required child invocation fail.
<#
.SYNOPSIS
    Deserialize a generated .tm7 file with the Microsoft Threat Modeling Tool's
    own DataContract serializer to prove format fidelity.

.DESCRIPTION
    Locates the installed ThreatModeling assemblies, obtains the exact
    DataContractSerializer via SerializableModelData.GetSerializer(), and calls
    ReadObject on the target file. Every assembly is verified as a validly
    signed Microsoft-published binary before it is loaded, because the
    ClickOnce payload root is writable by the current user. The TMT assemblies
    are 32-bit, so this script re-launches itself under the 32-bit Windows
    PowerShell host when started from a 64-bit process.

    Exit codes:
      0  Deserialization succeeded (prints DESERIALIZE_OK).
      1  Deserialization failed    (prints DESERIALIZE_FAIL: <message>).
      3  TMT assemblies not found  (prints TMT_ASSEMBLIES_NOT_FOUND); callers
         should treat this as "skip" rather than "fail".

.PARAMETER Path
    Path to the .tm7 file to deserialize.

.EXAMPLE
    ./Deserialize-Tm7.ps1 -Path ./model.tm7

.NOTES
    Ships with the security-planning skill so an installed consumer can run
    the documented fidelity check.
#>
[CmdletBinding()]
param(
    [Parameter(Mandatory)]
    [ValidateNotNullOrEmpty()]
    [string]$Path
)

$ErrorActionPreference = 'Stop'

#region Functions

function Test-TrustedAssembly {
    <#
    .SYNOPSIS
        Return $true only for a validly signed Microsoft-published assembly.
    .DESCRIPTION
        The ClickOnce payload root is writable by the current user, so an
        assembly is verified before it is loaded rather than trusted because
        of its location or name.
    .PARAMETER LiteralPath
        Assembly file to verify.
    .OUTPUTS
        [bool] True when the assembly carries a valid Microsoft signature.
    #>
    [CmdletBinding()]
    [OutputType([bool])]
    param(
        [Parameter(Mandatory)]
        [ValidateNotNullOrEmpty()]
        [string]$LiteralPath
    )

    $signature = Get-AuthenticodeSignature -LiteralPath $LiteralPath
    if ($signature.Status -ne 'Valid') { return $false }
    $subject = $signature.SignerCertificate.Subject
    if (-not $subject) { return $false }
    $commonNames = $subject -split ',' |
        ForEach-Object { $_.Trim() } |
        Where-Object { $_ -like 'CN=*' } |
        ForEach-Object { ($_ -replace '^CN=', '').Trim() }
    return $commonNames -contains 'Microsoft Corporation'
}

function Get-CandidateAssemblyDirectory {
    <#
    .SYNOPSIS
        Return TMT assembly directories in a deterministic order.
    .DESCRIPTION
        Roots must be absolute so an unset environment variable cannot produce
        a relative path that lets a directory beside the working directory
        contribute assemblies. Directories are ordered by path rather than by
        write time, because newest modification is not a trust signal.
    .OUTPUTS
        [string[]] Absolute directory paths.
    #>
    [CmdletBinding()]
    [OutputType([string[]])]
    param()

    $roots = @(
        (Join-Path $env:LOCALAPPDATA 'Apps\2.0'),
        (Join-Path ${env:ProgramFiles(x86)} 'Microsoft Threat Modeling Tool'),
        (Join-Path $env:ProgramFiles 'Microsoft Threat Modeling Tool')
    ) | Where-Object {
        $_ -and [System.IO.Path]::IsPathRooted($_) -and (Test-Path $_)
    }
    $directories = @()
    foreach ($root in $roots) {
        $found = Get-ChildItem -Recurse -Path $root `
            -Filter 'ThreatModeling.ExternalStorage.Local.dll' -ErrorAction SilentlyContinue |
            Sort-Object FullName
        foreach ($dll in $found) { $directories += $dll.Directory.FullName }
    }
    return $directories
}

#endregion Functions

#region Main Execution

# The TMT assemblies are x86. Re-launch under the 32-bit PowerShell host when
# this process is 64-bit so the assemblies can be loaded. Windows PowerShell
# defaults to Restricted, so a policy flag is required for the child to load
# this file at all. RemoteSigned is the narrowest policy that works: it still
# enforces signature checks on files carrying mark-of-the-web, unlike Bypass.
if ([Environment]::Is64BitProcess) {
    $wow = Join-Path $env:SystemRoot 'SysWOW64\WindowsPowerShell\v1.0\powershell.exe'
    if (Test-Path $wow) {
        & $wow -NoProfile -ExecutionPolicy RemoteSigned -File $PSCommandPath -Path $Path
        exit $LASTEXITCODE
    }
}

$candidateDirectories = Get-CandidateAssemblyDirectory
if (-not $candidateDirectories) {
    Write-Output 'TMT_ASSEMBLIES_NOT_FOUND'
    exit 3
}

# A directory is selected because it actually resolves the required type, not
# because it sorted first. One ClickOnce payload directory carries only the
# local-storage assembly, so choosing by order alone picks a directory that
# cannot deserialize anything.
$serializableModelData = $null
foreach ($candidate in $candidateDirectories) {
    $resolved = [System.IO.Path]::GetFullPath($candidate)
    $script:assemblyDirectory = $resolved
    foreach ($assemblyFile in Get-ChildItem $resolved -Filter 'ThreatModeling*.dll') {
        if (-not (Test-TrustedAssembly -LiteralPath $assemblyFile.FullName)) { continue }
        try { $assembly = [Reflection.Assembly]::LoadFrom($assemblyFile.FullName) } catch { continue }
        try { $types = $assembly.GetTypes() }
        catch [System.Reflection.ReflectionTypeLoadException] { $types = $_.Exception.Types | Where-Object { $_ } }
        $hit = $types | Where-Object {
            $_ -and $_.FullName -eq 'ThreatModeling.ExternalStorage.OM.SerializableModelData'
        } | Select-Object -First 1
        if ($hit) { $serializableModelData = $hit; break }
    }
    if ($serializableModelData) { break }
}

if (-not $serializableModelData) {
    Write-Output 'TMT_ASSEMBLIES_NOT_FOUND'
    exit 3
}

# Resolution is confined to the selected installation directory. The requested
# assembly name is reduced to its file name and the resolved candidate is
# re-checked against the directory, so a name carrying path separators or
# traversal cannot escape to load an assembly from elsewhere. The resolved
# assembly is verified before it is loaded.
[AppDomain]::CurrentDomain.add_AssemblyResolve({
        param($resolveSender, $resolveArgs)
        $name = ($resolveArgs.Name -split ',')[0]
        if ([string]::IsNullOrWhiteSpace($name)) { return $null }
        $leaf = [System.IO.Path]::GetFileName($name)
        if ($leaf -ne $name) { return $null }
        $base = $script:assemblyDirectory
        $candidate = [System.IO.Path]::GetFullPath((Join-Path $base ($leaf + '.dll')))
        if (-not $candidate.StartsWith($base, [StringComparison]::OrdinalIgnoreCase)) {
            return $null
        }
        if (Test-Path -LiteralPath $candidate -PathType Leaf) {
            if (-not (Test-TrustedAssembly -LiteralPath $candidate)) { return $null }
            [Reflection.Assembly]::LoadFrom($candidate)
        }
        else { $null }
    })
Add-Type -AssemblyName System.Runtime.Serialization

$bindingFlags = [Reflection.BindingFlags]'Public,NonPublic,Static'
$getSerializer = $serializableModelData.GetMethod(
    'GetSerializer', $bindingFlags, $null, [Type]::EmptyTypes, $null)
$serializer = $getSerializer.Invoke($null, @())

$stream = $null
try {
    $stream = [System.IO.File]::OpenRead($Path)
    $null = $serializer.ReadObject($stream)
    $stream.Close()
    Write-Output 'DESERIALIZE_OK'
    exit 0
}
catch {
    if ($stream) { $stream.Close() }
    $inner = $_.Exception
    while ($inner.InnerException) { $inner = $inner.InnerException }
    Write-Output ("DESERIALIZE_FAIL: {0}" -f $inner.Message)
    exit 1
}

#endregion Main Execution

Requirements and compatibility

Written for: GitHub Copilot, Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter, Needs Python, Needs Node.js

The author says: Generation requires Python 3.11+ and uv. The native TM7 feedback loop additionally requires Windows with an interactive desktop session and the pinned Microsoft Threat Modeling Tool 7.3.51110.1.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/hve-core · .github/skills/project-planning/security-planning · commit f425e94
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download security-planning.zip