
Building a Modular Bug Bounty Pipeline with Kiro Skills
Modular AI pipeline for automated code security audits. 25+ skills, 5 phases, and open-source. found critical bugs in <35m. check out the kiro skills approach!
Introduction
Manual source code review of a 20,000-line TypeScript application takes 2–5 days. Static analysis tools (Semgrep, CodeQL) catch pattern-based issues but miss business logic flaws, authorization gaps, and architectural weaknesses.
AI can bridge this gap — but only with structured methodology. A vague "find vulnerabilities" prompt produces inconsistent results. The real challenge is orchestration: guiding the AI through a systematic workflow that ensures thoroughness, eliminates false positives, and produces actionable reports.
This is where Kiro Skills come in. Each skill is a focused instruction set (a markdown file) that guides Kiro through one phase of a security audit, with defined inputs, processes, and outputs that chain together into a complete bug bounty workflow.
Repositories:
- Target application: https://github.com/n4igme/relearning
- Skill definitions: https://github.com/n4igme/randscript/tree/main/llm/skills/scode
Architecture: The 5-Phase Pipeline

Each phase reads the previous phase's output and produces a structured markdown document — creating an auditable evidence chain from final report back to source file and line number.
Phase 1: Reconnaissance
Maps the target codebase comprehensively:
- Technology stack, entry points (with file:line references), authentication model
- Data flows from user input source to sink
- Business features and sensitive assets (payment logic, PII, admin functionality)
Output: a ~250–300 line structured markdown "map" for all subsequent phases.
Phase 2: Threat Modelling
Applies STRIDE analysis to each entry point, constructs attack trees for high-value targets, and produces a prioritized target list that determines which sub-scanners to run.
This prioritization is key — in our case study, it eliminated 14 irrelevant scanners (no smart contracts, no C/C++ code, no SSRF surface), reducing Phase 3 from 23 sub-scanners to 9.
Phase 3: Vulnerability Scanning
The orchestrator dispatches to focused sub-scanners:
| Category | Sub-Scanner | Focus |
|---|---|---|
| Injection | vuln-injection | SQL, command, SSTI, XSS, NoSQL |
| Access Control | vuln-access-control | IDOR, missing authz, privilege escalation |
| Data Exposure | vuln-data-exposure | Secrets, verbose errors, PII in logs |
| Configuration | vuln-misconfig | CORS, CSP, debug mode, default creds |
| Business Logic | vuln-logic | Race conditions, workflow bypass |
| Auth/Session | vuln-authn-session | Broken auth, JWT flaws |
| API | vuln-api | Mass assignment, rate limiting |
| DoS | vuln-dos | ReDoS, algorithmic complexity |
| + 15 more | ... | Crypto, file handling, client-side, Web3, dependencies |
All scanners share a consistent severity rubric (Critical → Low) with modifiers for unauthenticated/automatable attacks.
Phase 4: Validation (The Key Differentiator)
For each finding, the validator:
- Re-reads the actual source file (±50 lines of context)
- Traces the complete data flow from input to dangerous sink
- Checks for compensating controls (middleware, framework protections, database-level security)
- Confirms exploitability — can an attacker actually reach this path?
- Deduplicates findings reported by multiple scanners
Each finding is classified as: Confirmed, Downgraded, False Positive (with reasoning), or Needs Dynamic Testing.
Phase 5: Report
Produces a professional bug bounty report with executive summary, CVSS scores, CWE references, proof-of-concept code, remediation snippets, and a prioritized roadmap.
Setting Up the Skills
Skills live in
~/.kiro/skills/<skill-name>/SKILL.md. Each file has YAML frontmatter and a markdown body:1
2
3
4
5
6
name: vuln-access-control
description: "Scan for access control vulnerabilities (IDOR, missing authz, privilege escalation)"
allowed-tools: Read Write Bash(grep *) Bash(find *)
argument-hint: <path to threat-model.md>
The markdown body contains: input specification, step-by-step process, vulnerability patterns to look for, output format, and constraints.
Install the full skill set:
1
2
git clone https://github.com/n4igme/randscript.git
cp -r randscript/llm/skills/scode/* ~/.kiro/skills/Run the pipeline:
1
2
3
4
5
6
# Phase 1–5 in sequence
kiro "Run sc1-recon on this project"
kiro "Run sc2-threat-model using recon.md"
kiro "Run sc3-vuln-scan using threat-model.md"
kiro "Run sc4-validate using vulnerabilities.md"
kiro "Run sc5-report using validated-vulnerabilities.md"Extending the Pipeline
To add a new scanner:
- Create
~/.kiro/skills/vuln-newclass/SKILL.md - Define vulnerability patterns and dangerous sinks
- Specify confirmed finding vs. false positive criteria
- Add to the orchestrator's dispatch table
It automatically integrates with validation and reporting since all scanners share the same output format.
Case Study: e-Learning Platform
Target: A Next.js 15 e-learning platform with TypeScript, Supabase (PostgreSQL + Auth), Stripe, 50+ server action endpoints.
Timeline
| Phase | Duration | Output |
|---|---|---|
| Reconnaissance | ~5 min | 278-line report, 50+ entry points |
| Threat Modelling | ~5 min | STRIDE analysis, 4 attack trees |
| Vulnerability Scanning | ~10 min | 27 initial findings |
| Validation | ~10 min | 17 validated, 5 FP eliminated |
| Report | ~5 min | Professional report with remediation |
Total: ~35 minutes vs. 2–3 days manually.
Critical Findings
Payment Bypass — The enrollment function accepted a
skipPaymentCheck parameter controllable by any authenticated user:1
2
3
4
5
6
7
8
9
10
// lib/actions/courses.ts:14
export async function enrollInCourse(
studentId: string,
courseId: string,
skipPaymentCheck = false // ← Any caller can set this to true
) {
if (!skipPaymentCheck && course.price > 0) {
// Payment verification entirely skipped
}
}Admin Privilege Escalation — Admin server actions used a service role key (bypasses all RLS) without verifying the caller's role:
1
2
3
4
5
6
7
8
// app/admin/users/page.tsx
async function approveUser(formData: FormData) {
'use server'
const adminClient = createAdminClient() // Full DB access, no RLS
const userId = formData.get('userId') as string
// NO CHECK: is the caller actually an admin?
await adminClient.from('profiles').update({ is_approved: true }).eq('id', userId)
}Quiz Answer Exposure — A mentor-facing function returned correct answers without ownership verification, accessible by any authenticated user.
False Positives Eliminated
| Theoretical Attack | Why It's a False Positive |
|---|---|
| Submit answers as another student | RLS: student_id = auth.uid() |
| Award arbitrary points | RLS: admin role required for writes |
| View other students' payments | RLS: zero policies = deny all |
| See unpublished courses | RLS: is_published = true OR instructor_id = auth.uid() |
| Reflected XSS via URL params | React JSX auto-escaping |
Without validation, these 5 findings would have produced a 30% false positive rate.
Remediation
The same Kiro session applied all fixes: removed
skipPaymentCheck, added role verification to admin actions, added ownership checks, implemented rate limiting, added security headers (CSP, HSTS), input validation with Zod, and audit logging. Post-fix: 9 security tests pass, build compiles successfully.Design Principles
- Separation of concerns — Each skill does one thing well, preventing cognitive overload and ensuring thoroughness
- Conservative validation — Assumes findings are false positives until proven otherwise
- Consistent severity — All 23 scanners share a single rubric with explicit modifiers
- Actionable output — Every finding includes a code-level fix, not just a description
- Reproducibility — Skill files are version-controlled and improvable over time
Limitations
- White-box only — requires source code access
- No runtime testing — can't confirm timing attacks or actual rate limit behavior
- Context window limits — very large codebases (100K+ lines) need chunking
- Non-deterministic — slightly different results on repeated runs
- Known patterns only — relies on vulnerability patterns defined in skill files
When to Use This vs. Traditional Pentesting
| Use This For | Complement With |
|---|---|
| Initial security review of new codebases | Dynamic testing (Burp Suite, ZAP) |
| PR review gates | Infrastructure scanning |
| Pre-launch audits | Manual expert review for critical systems |
| Continuous monitoring (weekly runs) | Red team exercises |
| Developer security training | Bug bounty programs |
Conclusion
The key insight: methodology matters more than model capability. A well-structured pipeline with focused skills, consistent severity ratings, and built-in validation produces better results than a more powerful model given a vague instruction.
Kiro Skills transform an AI agent from a general-purpose chatbot into a structured security analyst that follows methodology, maintains evidence chains, and produces professional deliverables. The complete skill set is open-source and extensible — each audit teaches you what patterns to add, building a codified version of your team's security expertise.
Resources
- Target application: https://github.com/n4igme/relearning
- Skill definitions (25 files): https://github.com/n4igme/randscript/tree/main/llm/skills/scode
- Kiro CLI: AI agent with skill-based task execution
- OWASP Testing Guide: Framework for vulnerability categories
- STRIDE: Microsoft's threat modelling framework
All vulnerabilities were identified in a controlled environment on code owned by the author and remediated before publication.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article