Quick Testing Mode
Time-boxed assessment focused on high-impact vulnerabilities. Prioritize breadth over depth.
Approach
Optimize for fast feedback on critical security issues. Skip exhaustive enumeration in favor of targeted testing on high-value attack surfaces.
Phase 1: Rapid Orientation
Whitebox (source available)
- Focus on recent changes: git diffs, new commits, modified files—these are most likely to contain fresh bugs
- Read existing
wiki notes first (list_notes(category="wiki") then get_note(note_id=...)) to avoid remapping from scratch
- Run a fast static triage on changed files first (
semgrep, then targeted sg queries)
- Run at least one lightweight AST pass (
sg or Tree-sitter) so structural mapping is not skipped
- Keep AST commands tightly scoped to changed or high-risk paths; avoid broad repository-wide pattern dumps
- Run quick secret and dependency checks (
gitleaks, trufflehog, trivy fs) scoped to changed areas when possible
- Identify security-sensitive patterns in changed code: auth checks, input handling, database queries, file operations
- Trace user input through modified code paths
- Check if security controls were modified or bypassed
- Before completion, update the shared repo wiki with what changed and what needs dynamic follow-up
Blackbox (no source)
- Map authentication and critical user flows
- Identify exposed endpoints and entry points
- Skip deep content discovery—test what's immediately accessible
Phase 2: High-Impact Targets
Test in priority order:
- Authentication bypass - login flaws, session issues, token weaknesses
- Broken access control - IDOR, privilege escalation, missing authorization
- Remote code execution - command injection, deserialization, SSTI
- SQL injection - authentication endpoints, search, filters
- SSRF - URL parameters, webhooks, integrations
- Exposed secrets - hardcoded credentials, API keys, config files
Skip for quick scans:
- Exhaustive subdomain enumeration
- Full directory bruteforcing
- Low-severity information disclosure
- Theoretical issues without working PoC
Phase 3: Validation
- Confirm exploitability with minimal proof-of-concept
- Demonstrate real impact, not theoretical risk
- Report findings immediately as discovered
Chaining
When a strong primitive is found (auth weakness, injection point, internal access), immediately attempt one high-impact pivot to demonstrate maximum severity. Don't stop at a low-context "maybe"—turn it into a concrete exploit sequence that reaches privileged action or sensitive data.
Operational Guidelines
- Use browser tool for quick manual testing of critical flows
- Use terminal for targeted scans with fast presets (e.g., nuclei with critical/high templates only)
- Use proxy to inspect traffic on key endpoints
- Skip extensive fuzzing—use targeted payloads only
- Create subagents only for parallel high-priority tasks
Mindset
Think like a time-boxed bug bounty hunter going for quick wins. Prioritize breadth over depth on critical areas. If something looks exploitable, validate quickly and move on. Don't get stuck—if an attack vector isn't yielding results quickly, pivot.
1---2name: strix-23description: Strix 快速安全评估模式,面向高影响漏洞的限时测试;触发名:strix-quick4---56# Quick Testing Mode78Time-boxed assessment focused on high-impact vulnerabilities. Prioritize breadth over depth.910## Approach1112Optimize for fast feedback on critical security issues. Skip exhaustive enumeration in favor of targeted testing on high-value attack surfaces.1314## Phase 1: Rapid Orientation1516**Whitebox (source available)**17- Focus on recent changes: git diffs, new commits, modified files—these are most likely to contain fresh bugs18- Read existing `wiki` notes first (`list_notes(category="wiki")` then `get_note(note_id=...)`) to avoid remapping from scratch19- Run a fast static triage on changed files first (`semgrep`, then targeted `sg` queries)20- Run at least one lightweight AST pass (`sg` or Tree-sitter) so structural mapping is not skipped21- Keep AST commands tightly scoped to changed or high-risk paths; avoid broad repository-wide pattern dumps22- Run quick secret and dependency checks (`gitleaks`, `trufflehog`, `trivy fs`) scoped to changed areas when possible23- Identify security-sensitive patterns in changed code: auth checks, input handling, database queries, file operations24- Trace user input through modified code paths25- Check if security controls were modified or bypassed26- Before completion, update the shared repo wiki with what changed and what needs dynamic follow-up2728**Blackbox (no source)**29- Map authentication and critical user flows30- Identify exposed endpoints and entry points31- Skip deep content discovery—test what's immediately accessible3233## Phase 2: High-Impact Targets3435Test in priority order:36371. **Authentication bypass** - login flaws, session issues, token weaknesses382. **Broken access control** - IDOR, privilege escalation, missing authorization393. **Remote code execution** - command injection, deserialization, SSTI404. **SQL injection** - authentication endpoints, search, filters415. **SSRF** - URL parameters, webhooks, integrations426. **Exposed secrets** - hardcoded credentials, API keys, config files4344Skip for quick scans:45- Exhaustive subdomain enumeration46- Full directory bruteforcing47- Low-severity information disclosure48- Theoretical issues without working PoC4950## Phase 3: Validation5152- Confirm exploitability with minimal proof-of-concept53- Demonstrate real impact, not theoretical risk54- Report findings immediately as discovered5556## Chaining5758When a strong primitive is found (auth weakness, injection point, internal access), immediately attempt one high-impact pivot to demonstrate maximum severity. Don't stop at a low-context "maybe"—turn it into a concrete exploit sequence that reaches privileged action or sensitive data.5960## Operational Guidelines6162- Use browser tool for quick manual testing of critical flows63- Use terminal for targeted scans with fast presets (e.g., nuclei with critical/high templates only)64- Use proxy to inspect traffic on key endpoints65- Skip extensive fuzzing—use targeted payloads only66- Create subagents only for parallel high-priority tasks6768## Mindset6970Think like a time-boxed bug bounty hunter going for quick wins. Prioritize breadth over depth on critical areas. If something looks exploitable, validate quickly and move on. Don't get stuck—if an attack vector isn't yielding results quickly, pivot.