/attack-flow

name: attack-flow
description: Generate SITF-compliant attack flow JSON files from attack descriptions or incident reports. Use when analyzing supply chain attacks, breaches, or security incidents.
argument-hint: <attack-name> [websearch|url]
tools: Read, Grep, Glob, WebSearch, WebFetch, Write, Bash

Attack Flow Generator

Generate SITF-compliant attack flow JSON files from attack descriptions or incident reports.

Usage

/attack-flow <attack-name> [source]

• `attack-name`: Identifier for the attack (e.g., "s1ngularity", "solarwinds")
• `source`: URL, local file path (report, write-up), "websearch" for auto-research, or omit to use conversation context. A name plus a document ("X, and use this report to augment") means: research X **and** fold in the document

Arguments: $ARGUMENTS

Instructions

When this skill is invoked:

Phase 1: Research

1. If source is "websearch" or a URL, gather attack details:

• Attack timeline and phases
• Entry point and initial access method
• Lateral movement and persistence techniques
• Data exfiltration or impact
• Affected components (CI/CD, VCS, Registry, Endpoint, Production)

2. If source is omitted, use context from the current conversation.

3. If the user supplies a document (internal report, write-up), treat it as a primary source but still cross-check:

• Find the **official post-mortem** from the affected organization, plus the original disclosure (e.g. the GitHub issue)
• Add details the document lacks (exact timestamps, commit SHAs, accounts involved) and cite where each came from
• **Flag conflicts** between sources in the output, especially where a new fact weakens a recommendation in the document (e.g. "approval gate would have stopped it" vs. the approval was given by a second stolen account)
• Keep internal documents out of anything public (node evidence, PR bodies): cite public sources only

Phase 2: Technique Mapping

1. Read `techniques.json` to get the full technique library.

2. For each attack step, find the best matching technique:

• Match by **action semantics**, not surface keywords
• Example: Uploading stolen data to repos → T-V003 (Secret Exfiltration), NOT T-V008 (Malicious Hosting)
• Example: Accessing VCS with stolen creds → T-V001 must come BEFORE any VCS actions

3. If no matching technique exists:

• Check if attack step is **in-scope** for SITF (SDLC/supply-chain related)
• If in-scope: Create placeholder with `"type": "technique-gap"`
• If out-of-scope (generic cloud/infra attack): Note in output, reference MITRE ATT&CK
• Note in output that `/technique-proposal` should be run for in-scope gaps

4. **Out-of-scope initial access**: when the way in has no SITF technique (e.g. exploiting an internet-exposed app, MITRE T1190), do NOT force a mapping. Describe it in the entry point's `customLabel` and connect the entry point directly to the first in-scope technique.

5. **Contributing conditions**: a condition that enabled the attack but wasn't an attacker action (e.g. AI coding agent traffic leaking tokens into logs) can be shown as a technique node when it carries useful controls:

• Prefix its `customLabel` with "Contributing:" and say in `evidence` that it is not an attacker action
• Connect it with a **dashed** edge (see Phase 4); it is a legitimate root node with no incoming edge

6. **Attacker infrastructure** (dead-drop repos, lookalike forks, exfil domains): put it in the `evidence` of the technique that uses it, or as a single technique (e.g. T-V008) in the relevant component. Do NOT create a separate zone for it; zones are for victims.

7. **Downstream consumers** (any malicious package, image, or extension): walk every consumer type and either map it or note "not observed":

• Developer endpoints (local installs): T-E001, T-E003, C2 techniques
• CI/CD runners: T-C010, T-C005
• Production / Kubernetes / cloud: T-P011, T-P007, T-P009
• Downstream registries (worm-style republishing): T-R004
• Mark mappings inferred from payload capabilities (vs. observed victims) as `[Inference]` in `evidence`

Phase 3: Layout Calculation

Apply these layout rules:

Rule 1: Component Layout (Left-to-Right by Attack Flow)

• Order components by their **sequence in the attack chain**, not by standard SITF order
• If attack flows CI/CD → Registry → Endpoint → VCS, layout left-to-right accordingly
• Minimum horizontal gap between components: 80-100px
• Component x-positions: Use increments of ~300px starting from x=50

Rule 2: Technique Ordering (Top-to-Bottom)

• **Primary**: Order techniques by their **sequence in the attack flow**
• **Secondary**: Within same attack step, order by stage (Initial Access → Discovery → Post-Compromise)
• Vertical gap between techniques: ~130px
• First technique starts at y = component.y + 80

Rule 3: Technique-Component Centering

• Every technique node MUST be visually centered within its parent component
• **Centering formula**: `technique.x = component.x + (component.width - technique.width) / 2`
• With component.width=250 and technique.width=160: offset = (250-160)/2 = 45
• Example: component at x=50 → technique at x=95
• Example: component at x=350 → technique at x=395
• Validate technique.data.component matches parent component.data.componentId

Rule 4: Component Sizing

• Width = 250px (standard)
• Height = max(500, (technique_count × 130) + 160) — ensures adequate vertical space
• All components should have consistent height for visual alignment

Rule 5: Edge Connections

• Technique nodes only have a `top` target handle and a `bottom` source handle (`app/visualizer.html`). Entry points expose `right`/`bottom` sources, exit points `left`/`top` targets
• Use `sourceHandle: "bottom"`, `targetHandle: "top"` within a component. For cross-component edges, `right`/`left` is the convention, but on technique nodes it falls back to bottom/top. Don't design layouts that rely on side c