Kjell Tore Guttormsen f418a8fe08 feat(llm-security-copilot): port llm-security v5.1.0 to GitHub Copilot CLI

Full port of llm-security plugin for internal use on Windows with GitHub
Copilot CLI. Protocol translation layer (copilot-hook-runner.mjs)
normalizes Copilot camelCase I/O to Claude Code snake_case format — all
original hook scripts run unmodified.

- 8 hooks with protocol translation (stdin/stdout/exit code)
- 18 SKILL.md skills (Agent Skills Open Standard)
- 6 .agent.md agent definitions
- 20 scanners + 14 scanner lib modules (unchanged)
- 14 knowledge files (unchanged)
- 39 test files including copilot-port-verify.mjs (17 tests)
- Windows-ready: node:path, os.tmpdir(), process.execPath, no bash

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-04-09 21:56:10 +02:00

3 KiB

Raw Blame History

name	description
security-threat-model	Interactive threat modeling using STRIDE and MAESTRO frameworks — guides architecture analysis and generates threat model document

Threat Model

Interactive STRIDE/MAESTRO threat modeling session. 15-30 minutes → complete threat model document.

Principles

Ask one question at a time
Not a rubber stamp — challenge assumptions
Cite OWASP IDs (LLM01-LLM10, ASI01-ASI10)
Distinguish theoretical threats from actively exploited ones
Advisory output only — no file modifications

Phase 1: Architecture Discovery

Read knowledge files:

<plugin-root>/knowledge/skill-threat-patterns.md
<plugin-root>/knowledge/mcp-threat-patterns.md
<plugin-root>/knowledge/mitigation-matrix.md

Ask the user these questions (one at a time):

What type of system is this? (plugin, MCP server, standalone agent, API service)
What tools/MCP servers does the agent have access to? (file system, network, databases, external APIs)
What data does the system handle? (credentials, PII, source code, business data)
Who are the users and what's the trust model? (single developer, team, external users)
How is it deployed? (local CLI, VS Code extension, cloud agent, CI/CD)

Phase 2: Component Mapping

Map identified components to MAESTRO 7-Layer Model:

L1 Foundation Models — Base LLM capabilities
L2 Data Operations — RAG, embeddings, knowledge bases
L3 Agent Frameworks — Orchestration, tool routing
L4 Tool Ecosystem — MCP servers, API integrations
L5 Deployment — Runtime environment, containers
L6 Interaction — User interfaces, chat, CLI
L7 Ecosystem — Plugin marketplace, supply chain

Present the mapping for user confirmation.

Phase 3: Threat Identification

Apply STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to each relevant MAESTRO layer.

For each threat: state actor, method, asset at risk, impact, OWASP ID, whether it's known to be exploited in the wild.

Phase 4: Risk Assessment

Rate each threat: Likelihood (1-5) x Impact (1-5) = Risk Score.

20-25: Critical — Immediate action required
12-19: High — Address within current sprint
6-11: Medium — Plan remediation
1-5: Low — Accept or monitor

Present the risk matrix for user validation.

Phase 5: Mitigation Mapping

Read <plugin-root>/knowledge/mitigation-matrix.md. For each threat, classify the control status:

Already mitigated (existing hooks, settings)
Can be mitigated (configuration change or code fix)
Partially mitigated
Accepted risk (documented rationale)
External dependency

Output: Threat Model Document

Produce an 8-section document:

System Description
Architecture Overview
MAESTRO Layer Mapping
Threat Catalog (per layer, with STRIDE/OWASP/likelihood/impact/scenario/control/recommendation)
Risk Matrix
Mitigation Plan (Critical+High actions, Already Mitigated, Accepted Risks)
Residual Risk Summary
Assumptions and Limitations

3 KiB Raw Blame History