/technique-proposal

name: technique-proposal
description: Generate a PR-ready technique proposal when an attack step doesn't map to existing SITF techniques. Use after /attack-flow identifies technique gaps.
argument-hint: "<description>" [component]
tools: Read, Grep, Glob

Technique Proposal Generator

Generate a PR-ready technique proposal when an attack step doesn't map to existing SITF techniques.

Usage

/technique-proposal <description> [component]

• `description`: Description of the attack step or gap
• `component`: Target component (endpoint, vcs, cicd, registry, production) - optional, will be inferred if omitted

Arguments: $ARGUMENTS

Instructions

When this skill is invoked:

Phase 1: Gap Analysis

1. Read `techniques.json` to understand existing techniques.

2. Confirm the gap:

• Search for semantically similar techniques
• Verify no existing technique covers this attack step
• If a match exists, report it and exit

3. **Verify the attack step is within SITF scope** (see Scope Boundaries below)

4. Identify the correct component:

• endpoint: Developer workstations, IDEs, local tools
• vcs: Version control systems (GitHub, GitLab, etc.)
• cicd: CI/CD pipelines, runners, workflows
• registry: Package registries, container registries
• production: Production infrastructure **as it relates to supply chain attacks**

5. Determine the attack stage:

• Initial Access: First foothold in the component
• Discovery and Lateral Movement: Enumeration, pivoting, credential theft
• Post-Compromise: Data exfiltration, destruction, persistence

Scope Boundaries

**SITF covers SDLC infrastructure and software supply chain attacks specifically.** Not all attack steps in an incident warrant new SITF techniques.

In Scope (propose technique)

• Attacks on developer workstations, IDEs, and local development tools
• Attacks on version control systems and source code
• Attacks on CI/CD pipelines, runners, and build systems
• Attacks on package/container registries
• Production techniques that are **supply-chain-specific**:
• Backdooring deployed artifacts to compromise downstream consumers
• Stealing code signing keys or certificates
• Modifying release pipelines or deployment configurations
• Accessing production to pivot back into SDLC systems

Out of Scope (do NOT propose technique)

• Generic cloud infrastructure attacks (IAM privilege escalation, cloud misconfigurations)
• Generic container/Kubernetes attacks (pod escape, RBAC abuse, kubelet exploits)
• Generic network attacks (lateral movement via SSH, RDP exploitation)
• Post-exploitation techniques that don't relate to software supply chain

**Example:** If an attacker uses CI/CD as initial access, then pivots to cloud production and uses a Kubernetes privilege escalation technique, the K8s privesc is **out of scope** for SITF. Instead:

1. For attack flows: Mark the step with `"type": "out-of-scope"` and reference the appropriate framework (e.g., "MITRE ATT&CK: Escape to Host - T1611") 2. For technique proposals: Report that the attack step is outside SITF's domain and does not warrant a new technique

**Rationale:** These generic infrastructure techniques are already well-documented in:

• MITRE ATT&CK for Enterprise (Cloud, Containers matrices)
• MITRE ATT&CK for ICS
• Cloud-specific frameworks (AWS Security Maturity Model, Azure Security Benchmark)

SITF adds value by covering the **unique attack surface of SDLC infrastructure** that these frameworks don't address comprehensively.

Phase 2: Technique ID Assignment

1. Find the highest existing ID for the target component:

• Endpoint: T-E###
• VCS: T-V###
• CI/CD: T-C###
• Registry: T-R###
• Production: T-P###

2. Assign the next sequential number.

Phase 3: Technique Definition

Generate the technique entry following these conventions:

Name

• Action-oriented verb phrase
• Match style of existing techniques in same component
• Avoid vendor-specific terms unless unavoidable
• Examples: "Abuse Local AI Tools", "Harvest Local Secrets", "Turn Private Repos Public"

Description

• Single sentence describing the attack action
• Focus on what the attacker does, not the impact
• Start with "Attacker..." for consistency

Risks

• Focus on **why** this attack is possible (enabling conditions)
• Describe misconfigurations, missing controls, insecure defaults
• Keep each risk as a concise phrase, not a full sentence
• Reference similar risks from related techniques for consistency

Controls (Protective vs Detective)

Controls MUST be split into two categories:

**Protective Controls** - Configuration-based measures that prevent attacks:

• Settings, policies, permissions that block attacks before they happen
• Static configurations that don't require active monitoring
• Examples: MFA enforcement, branch protection, network segmentation, sandboxing

**Detective Controls** - Monitoring and detection capabilities:

• Requires active observation and alerting
• Identifies attacks in progress or after the fact
• Examples: EDR, audit log monitoring, secret scanning, runtime agents

For each control, include:

• `name`: Control name (action-oriented)
• `description`: Optional detailed description
• `frameworks`: Array of OWASP SPVS categories (see Framework Mappings)

For detective controls, optionally include:

• `detectionRules`: Array of detection rule references (Sigma, etc.)

Framework Mappings

Map each control to the appropriate OWASP SPVS category:

| Category | Description | Typical Controls | |----------|-------------|------------------| | **V1.1** | Identity and Access Management | MFA, SSO, OIDC, PAT policies | | **V1.2** | Hardening User Machines | IDE sandboxing, app whitelisting, credential storage | | **V1.3** | Security Requirements | Policies, security awareness training | | **V1.4** | Developer Tool Operation | AI tool policies, WebRTC restrictions | | **V1.5** | Source Code Management