technique-proposal

Name: technique-proposal
Author: wiz-sec-public

172stars17forks

How to install technique-proposal?

wiz-sec-public/sitf/technique-proposal

$npx -y skills add wiz-sec-public/SITF --skill technique-proposal

Installs into the current project.

Summary

Generate a PR-ready technique proposal when an attack step doesn't map to existing SITF techniques. Use after /attack-flow identifies technique gaps.

Files · 1

View on GitHub

SKILL.md

1	# Technique Proposal Generator
2
3	Generate a PR-ready technique proposal when an attack step doesn't map to existing SITF techniques.
4
5	## Usage
6
7	```
8	/technique-proposal <description> [component]
9	```
10
11	- `description`: Description of the attack step or gap
12	- `component`: Target component (endpoint, vcs, cicd, registry, production) - optional, will be inferred if omitted
13
14	Arguments: $ARGUMENTS
15
16	## Instructions
17
18	When this skill is invoked:
19
20	### Phase 1: Gap Analysis
21
22	1. Read `techniques.json` to understand existing techniques.
23
24	2. Confirm the gap:
25	- Search for semantically similar techniques
26	- Verify no existing technique covers this attack step
27	- If a match exists, report it and exit
28
29	3. Verify the attack step is within SITF scope (see Scope Boundaries below)
30
31	4. Identify the correct component:
32	- endpoint: Developer workstations, IDEs, local tools
33	- vcs: Version control systems (GitHub, GitLab, etc.)
34	- cicd: CI/CD pipelines, runners, workflows
35	- registry: Package registries, container registries
36	- production: Production infrastructure as it relates to supply chain attacks
37
38	5. Determine the attack stage:
39	- Initial Access: First foothold in the component
40	- Discovery and Lateral Movement: Enumeration, pivoting, credential theft
41	- Post-Compromise: Data exfiltration, destruction, persistence
42
43	### Scope Boundaries
44
45	SITF covers SDLC infrastructure and software supply chain attacks specifically. Not all attack steps in an incident warrant new SITF techniques.
46
47	#### In Scope (propose technique)
48	- Attacks on developer workstations, IDEs, and local development tools
49	- Attacks on version control systems and source code
50	- Attacks on CI/CD pipelines, runners, and build systems
51	- Attacks on package/container registries
52	- Production techniques that are supply-chain-specific:
53	- Backdooring deployed artifacts to compromise downstream consumers
54	- Stealing code signing keys or certificates
55	- Modifying release pipelines or deployment configurations
56	- Accessing production to pivot back into SDLC systems
57
58	#### Out of Scope (do NOT propose technique)
59	- Generic cloud infrastructure attacks (IAM privilege escalation, cloud misconfigurations)
60	- Generic container/Kubernetes attacks (pod escape, RBAC abuse, kubelet exploits)
61	- Generic network attacks (lateral movement via SSH, RDP exploitation)
62	- Post-exploitation techniques that don't relate to software supply chain
63
64	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:
65
66	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")
67	2. For technique proposals: Report that the attack step is outside SITF's domain and does not warrant a new technique
68
69	Rationale: These generic infrastructure techniques are already well-documented in:
70	- MITRE ATT&CK for Enterprise (Cloud, Containers matrices)
71	- MITRE ATT&CK for ICS
72	- Cloud-specific frameworks (AWS Security Maturity Model, Azure Security Benchmark)
73
74	SITF adds value by covering the unique attack surface of SDLC infrastructure that these frameworks don't address comprehensively.
75
76	### Phase 2: Technique ID Assignment
77
78	1. Find the highest existing ID for the target component:
79	- Endpoint: T-E###
80	- VCS: T-V###
81	- CI/CD: T-C###
82	- Registry: T-R###
83	- Production: T-P###
84
85	2. Assign the next sequential number.
86
87	### Phase 3: Technique Definition
88
89	Generate the technique entry following these conventions:
90
91	#### Name
92	- Action-oriented verb phrase
93	- Match style of existing techniques in same component
94	- Avoid vendor-specific terms unless unavoidable
95	- Examples: "Abuse Local AI Tools", "Harvest Local Secrets", "Turn Private Repos Public"
96
97	#### Description
98	- Single sentence describing the attack action
99	- Focus on what the attacker does, not the impact
100	- Start with "Attacker..." for consistency
101
102	#### Risks
103	- Focus on why this attack is possible (enabling conditions)
104	- Describe misconfigurations, missing controls, insecure defaults
105	- Keep each risk as a concise phrase, not a full sentence
106	- Reference similar risks from related techniques for consistency
107
108	#### Controls (Protective vs Detective)
109
110	Controls MUST be split into two categories:
111
112	Protective Controls - Configuration-based measures that prevent attacks:
113	- Settings, policies, permissions that block attacks before they happen
114	- Static configurations that don't require active monitoring
115	- Examples: MFA enforcement, branch protection, network segmentation, sandboxing
116
117	Detective Controls - Monitoring and detection capabilities:
118	- Requi

People who liked this also viewed

6 picks

Type

entra-app-registrationGuides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration. USE FOR: create app registration, register Azure AD app, configure OAuth, set up authentication, add API perSkillsJul 2026471k1.3k
azure-complianceRun Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: SkillsJul 2026470k1.3k
azure-rbacOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026466k1.3k
better-auth-best-practicesAgent skill from better-auth/skillsSkillsJul 202678k203
firebase-security-rules-auditorA skill to evaluate how secure Firestore security rules are. Use this when Firestore security rules are updated to ensure that the generated rules are extremely secure and robust.SkillsJul 202676k386
audit-websiteAudit a website with the squirrelscan CLI and fix the findings in code. Runs SEO, performance, security, technical, content, accessibility, and 15 other rule categories (260+ rules), returns an LLM-opSkillsJul 202665k85

technique-proposal

172stars17forks

View on GitHub

How to install technique-proposal?

wiz-sec-public/sitf/technique-proposal

$npx -y skills add wiz-sec-public/SITF --skill technique-proposal

Installs into the current project.

Summary

Generate a PR-ready technique proposal when an attack step doesn't map to existing SITF techniques. Use after /attack-flow identifies technique gaps.

Files · 1

View on GitHub

SKILL.md

1	# Technique Proposal Generator
2
3	Generate a PR-ready technique proposal when an attack step doesn't map to existing SITF techniques.
4
5	## Usage
6
7	```
8	/technique-proposal <description> [component]
9	```
10
11	- `description`: Description of the attack step or gap
12	- `component`: Target component (endpoint, vcs, cicd, registry, production) - optional, will be inferred if omitted
13
14	Arguments: $ARGUMENTS
15
16	## Instructions
17
18	When this skill is invoked:
19
20	### Phase 1: Gap Analysis
21
22	1. Read `techniques.json` to understand existing techniques.
23
24	2. Confirm the gap:
25	- Search for semantically similar techniques
26	- Verify no existing technique covers this attack step
27	- If a match exists, report it and exit
28
29	3. Verify the attack step is within SITF scope (see Scope Boundaries below)
30
31	4. Identify the correct component:
32	- endpoint: Developer workstations, IDEs, local tools
33	- vcs: Version control systems (GitHub, GitLab, etc.)
34	- cicd: CI/CD pipelines, runners, workflows
35	- registry: Package registries, container registries
36	- production: Production infrastructure as it relates to supply chain attacks
37
38	5. Determine the attack stage:
39	- Initial Access: First foothold in the component
40	- Discovery and Lateral Movement: Enumeration, pivoting, credential theft
41	- Post-Compromise: Data exfiltration, destruction, persistence
42
43	### Scope Boundaries
44
45	SITF covers SDLC infrastructure and software supply chain attacks specifically. Not all attack steps in an incident warrant new SITF techniques.
46
47	#### In Scope (propose technique)
48	- Attacks on developer workstations, IDEs, and local development tools
49	- Attacks on version control systems and source code
50	- Attacks on CI/CD pipelines, runners, and build systems
51	- Attacks on package/container registries
52	- Production techniques that are supply-chain-specific:
53	- Backdooring deployed artifacts to compromise downstream consumers
54	- Stealing code signing keys or certificates
55	- Modifying release pipelines or deployment configurations
56	- Accessing production to pivot back into SDLC systems
57
58	#### Out of Scope (do NOT propose technique)
59	- Generic cloud infrastructure attacks (IAM privilege escalation, cloud misconfigurations)
60	- Generic container/Kubernetes attacks (pod escape, RBAC abuse, kubelet exploits)
61	- Generic network attacks (lateral movement via SSH, RDP exploitation)
62	- Post-exploitation techniques that don't relate to software supply chain
63
64	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:
65
66	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")
67	2. For technique proposals: Report that the attack step is outside SITF's domain and does not warrant a new technique
68
69	Rationale: These generic infrastructure techniques are already well-documented in:
70	- MITRE ATT&CK for Enterprise (Cloud, Containers matrices)
71	- MITRE ATT&CK for ICS
72	- Cloud-specific frameworks (AWS Security Maturity Model, Azure Security Benchmark)
73
74	SITF adds value by covering the unique attack surface of SDLC infrastructure that these frameworks don't address comprehensively.
75
76	### Phase 2: Technique ID Assignment
77
78	1. Find the highest existing ID for the target component:
79	- Endpoint: T-E###
80	- VCS: T-V###
81	- CI/CD: T-C###
82	- Registry: T-R###
83	- Production: T-P###
84
85	2. Assign the next sequential number.
86
87	### Phase 3: Technique Definition
88
89	Generate the technique entry following these conventions:
90
91	#### Name
92	- Action-oriented verb phrase
93	- Match style of existing techniques in same component
94	- Avoid vendor-specific terms unless unavoidable
95	- Examples: "Abuse Local AI Tools", "Harvest Local Secrets", "Turn Private Repos Public"
96
97	#### Description
98	- Single sentence describing the attack action
99	- Focus on what the attacker does, not the impact
100	- Start with "Attacker..." for consistency
101
102	#### Risks
103	- Focus on why this attack is possible (enabling conditions)
104	- Describe misconfigurations, missing controls, insecure defaults
105	- Keep each risk as a concise phrase, not a full sentence
106	- Reference similar risks from related techniques for consistency
107
108	#### Controls (Protective vs Detective)
109
110	Controls MUST be split into two categories:
111
112	Protective Controls - Configuration-based measures that prevent attacks:
113	- Settings, policies, permissions that block attacks before they happen
114	- Static configurations that don't require active monitoring
115	- Examples: MFA enforcement, branch protection, network segmentation, sandboxing
116
117	Detective Controls - Monitoring and detection capabilities:
118	- Requi

People who liked this also viewed

6 picks

Type