$npx -y skills add wiz-sec-public/SITF --skill attack-flowGenerate SITF-compliant attack flow JSON files from attack descriptions or incident reports. Use when analyzing supply chain attacks, breaches, or security incidents.
| 1 | # Attack Flow Generator |
| 2 | |
| 3 | Generate SITF-compliant attack flow JSON files from attack descriptions or incident reports. |
| 4 | |
| 5 | ## Usage |
| 6 | |
| 7 | ``` |
| 8 | /attack-flow <attack-name> [source] |
| 9 | ``` |
| 10 | |
| 11 | - `attack-name`: Identifier for the attack (e.g., "s1ngularity", "solarwinds") |
| 12 | - `source`: URL, "websearch" for auto-research, or omit to use conversation context |
| 13 | |
| 14 | Arguments: $ARGUMENTS |
| 15 | |
| 16 | ## Instructions |
| 17 | |
| 18 | When this skill is invoked: |
| 19 | |
| 20 | ### Phase 1: Research |
| 21 | |
| 22 | 1. If source is "websearch" or a URL, gather attack details: |
| 23 | - Attack timeline and phases |
| 24 | - Entry point and initial access method |
| 25 | - Lateral movement and persistence techniques |
| 26 | - Data exfiltration or impact |
| 27 | - Affected components (CI/CD, VCS, Registry, Endpoint, Production) |
| 28 | |
| 29 | 2. If source is omitted, use context from the current conversation. |
| 30 | |
| 31 | ### Phase 2: Technique Mapping |
| 32 | |
| 33 | 1. Read `techniques.json` to get the full technique library. |
| 34 | |
| 35 | 2. For each attack step, find the best matching technique: |
| 36 | - Match by **action semantics**, not surface keywords |
| 37 | - Example: Uploading stolen data to repos → T-V003 (Secret Exfiltration), NOT T-V008 (Malicious Hosting) |
| 38 | - Example: Accessing VCS with stolen creds → T-V001 must come BEFORE any VCS actions |
| 39 | |
| 40 | 3. If no matching technique exists: |
| 41 | - Check if attack step is **in-scope** for SITF (SDLC/supply-chain related) |
| 42 | - If in-scope: Create placeholder with `"type": "technique-gap"` |
| 43 | - If out-of-scope (generic cloud/infra attack): Note in output, reference MITRE ATT&CK |
| 44 | - Note in output that `/technique-proposal` should be run for in-scope gaps |
| 45 | |
| 46 | ### Phase 3: Layout Calculation |
| 47 | |
| 48 | Apply these layout rules: |
| 49 | |
| 50 | #### Rule 1: Component Layout (Left-to-Right by Attack Flow) |
| 51 | - Order components by their **sequence in the attack chain**, not by standard SITF order |
| 52 | - If attack flows CI/CD → Registry → Endpoint → VCS, layout left-to-right accordingly |
| 53 | - Minimum horizontal gap between components: 80-100px |
| 54 | - Component x-positions: Use increments of ~300px starting from x=50 |
| 55 | |
| 56 | #### Rule 2: Technique Ordering (Top-to-Bottom) |
| 57 | - **Primary**: Order techniques by their **sequence in the attack flow** |
| 58 | - **Secondary**: Within same attack step, order by stage (Initial Access → Discovery → Post-Compromise) |
| 59 | - Vertical gap between techniques: ~130px |
| 60 | - First technique starts at y = component.y + 80 |
| 61 | |
| 62 | #### Rule 3: Technique-Component Centering |
| 63 | - Every technique node MUST be visually centered within its parent component |
| 64 | - **Centering formula**: `technique.x = component.x + (component.width - technique.width) / 2` |
| 65 | - With component.width=250 and technique.width=160: offset = (250-160)/2 = 45 |
| 66 | - Example: component at x=50 → technique at x=95 |
| 67 | - Example: component at x=350 → technique at x=395 |
| 68 | - Validate technique.data.component matches parent component.data.componentId |
| 69 | |
| 70 | #### Rule 4: Component Sizing |
| 71 | - Width = 250px (standard) |
| 72 | - Height = max(500, (technique_count × 130) + 160) — ensures adequate vertical space |
| 73 | - All components should have consistent height for visual alignment |
| 74 | |
| 75 | #### Rule 5: Edge Connections |
| 76 | - Connect source.bottom → target.top for vertical flows within component |
| 77 | - Connect source.right → target.left for cross-component flows |
| 78 | - Add labels for significant transitions ("Stolen token", "pip install", etc.) |
| 79 | - Use `"type": "smoothstep"` for all edges |
| 80 | |
| 81 | ### Phase 4: JSON Generation |
| 82 | |
| 83 | Generate the attack flow JSON with this exact structure: |
| 84 | |
| 85 | ```json |
| 86 | { |
| 87 | "metadata": { |
| 88 | "name": "Attack Name", |
| 89 | "title": "Canvas Display Title", |
| 90 | "created": "ISO-8601 timestamp", |
| 91 | "version": "1.0", |
| 92 | "framework": "SITF", |
| 93 | "description": "Brief attack description" |
| 94 | }, |
| 95 | "nodes": [], |
| 96 | "edges": [] |
| 97 | } |
| 98 | ``` |
| 99 | |
| 100 | **Metadata field guidelines:** |
| 101 | - `name`: Short identifier (e.g., "tj-actions", "circleci") |
| 102 | - `title`: Concise canvas title, max 5-7 words (e.g., "tj-actions/changed-files Compromise", "CircleCI Security Incident (2023)") |
| 103 | - `description`: One sentence summary, max 150 characters |
| 104 | - Do NOT write paragraph-length titles — save details for technique customLabels and evidence fields |
| 105 | |
| 106 | #### Node Structure - Entry Point |
| 107 | ```json |
| 108 | { |
| 109 | "id": "entryPoint-attackname-1", |
| 110 | "type": "entryPoint", |
| 111 | "position": { "x": -150, "y": 200 }, |
| 112 | "data": { |
| 113 | "label": "Entry Point Label" |
| 114 | }, |
| 115 | "zIndex": 10, |
| 116 | "width": 195, |
| 117 | "height": 46 |
| 118 | } |
| 119 | ``` |
| 120 | |
| 121 | #### Node Structure - Component |
| 122 | ```json |
| 123 | { |
| 124 | "id": "component-cicd-1", |
| 125 | "type": "component", |
| 126 | "position": { "x": 50, "y": 80 }, |
| 127 | "data": { |
| 128 | "label": "CI/CD", |
| 129 | "componentId": "cicd", |
| 130 | "techniques": [], |
| 131 | "customLabel": "Context-specific label" |
| 132 | }, |
| 133 | "zIndex": -1, |
| 134 | "width": 250, |
| 135 | "height": 500, |
| 136 | "style": { "width": 250, "height": 500 } |
| 137 | } |
| 138 | ``` |
| 139 | |
| 140 | #### Node Structure - Technique (CRITICAL: use exact field names) |
| 141 | ```json |
| 142 | { |
| 143 | "id": "technique-c0 |