Agent skill

hawk-survey

Comprehensive security auditor that surveys entire applications or subsystems with threat modeling, OWASP coverage, infrastructure review, and formal reporting. The hawk circles above the grove, seeing everything. Use when you need a full security assessment, not just a quick check.

View SKILL.md on GitHub Repository
Stars 163
Forks 31

Install this agent skill to your Project

npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/hawk-survey

SKILL.md

Hawk Survey 🦅

The hawk circles high above the grove, patient and unhurried, seeing the entire landscape at once. Every path a wanderer might walk. Every clearing where something could be exposed. Every shadow where something might hide. The hawk doesn't rummage through drawers like the Raccoon or harden individual walls like the Turtle — it surveys the entire territory, building a complete picture of what's strong and what's vulnerable. Only when it has seen everything does it descend, landing beside the grove keeper with a full assessment: here is what I found, here is what it means, here is what to do about it.

The hawk is an independent assessor. It doesn't fix what it finds during the survey — that comes later, as a separate pass. First the diagnosis, complete and honest. Then the treatment, methodical and thorough. Two circles: one to see, one to act.

When to Activate

  • User says "full security audit" or "comprehensive security review"
  • User says "assess the security of..." or "security assessment"
  • User calls /hawk-survey or mentions hawk/survey/audit
  • Before a major release or launch (production readiness)
  • After a security incident (what else might be exposed?)
  • When onboarding a new codebase (what's the security posture?)
  • Periodic security review (quarterly, annually)
  • When the scope is bigger than a single feature — entire app, subsystem, or service
  • User says "pentest" or "threat model" or "security posture"
  • When gathering-security feels too implementation-focused and you need assessment first

IMPORTANT: The Hawk does NOT fix things during its first pass. Circle 1 is assessment only — a complete report. Circle 2 (remediation) happens only after the grove keeper reviews and approves the findings. Never mix assessment and remediation in the same pass.

Pair with: turtle-harden for remediation of hardening findings, raccoon-audit for secret rotation and cleanup, spider-weave for auth architecture fixes, beaver-build for security regression tests after remediation

The Survey

CIRCLE → DESCEND → ASSESS → REPORT → RETURN
   ↓         ↓         ↓        ↓        ↓
 Threat    Map       Audit    Write    Fix
 Model    Attack    Against   Formal   (approved
 First    Surface   Checklist Report   findings)

Phase 1: CIRCLE

The hawk rises on thermals, spiraling higher, until the entire grove spreads out below...

Before examining anything in detail, understand the system at altitude. What is this thing? What does it protect? Who threatens it? This phase produces a threat model that guides everything else.

1A. Scope Definition

Establish what's being audited:

markdown
## Audit Scope

**Target:** [Full application / Subsystem / Service name]
**Boundary:** [What's in scope, what's explicitly out]
**Environment:** [Production / Staging / Local dev]
**Tech Stack:** [SvelteKit, Cloudflare Workers, D1, R2, KV, etc.]
**Access Level:** [Code review only / Code + config / Code + config + live testing]

If the scope is a full application, identify all major subsystems:

  • Authentication & identity
  • User-facing routes and pages
  • Admin/privileged routes
  • API endpoints (internal and external)
  • Data storage (databases, KV, R2, file storage)
  • Background jobs and scheduled tasks
  • Third-party integrations
  • Infrastructure configuration (Workers, DNS, CDN)
  • Email and notification systems
  • Content moderation and safety

If the scope is a subsystem, identify its boundaries and trust relationships with adjacent systems.

1B. Threat Modeling (STRIDE)

For each major component or data flow, evaluate against STRIDE:

┌──────────────────────────────────────────────────────────────┐
│                    STRIDE THREAT MODEL                       │
├──────────────┬───────────────────────────────────────────────┤
│ Spoofing     │ Can an attacker pretend to be someone else?   │
│              │ Auth bypass, session hijacking, token forgery │
├──────────────┼───────────────────────────────────────────────┤
│ Tampering    │ Can an attacker modify data in transit/rest?  │
│              │ Parameter manipulation, DB injection, MITM    │
├──────────────┼───────────────────────────────────────────────┤
│ Repudiation  │ Can actions be performed without attribution? │
│              │ Missing audit logs, unsigned transactions     │
├──────────────┼───────────────────────────────────────────────┤
│ Info         │ Can an attacker access unauthorized data?     │
│ Disclosure   │ Error leakage, directory listing, IDOR       │
├──────────────┼───────────────────────────────────────────────┤
│ Denial of    │ Can an attacker disrupt availability?         │
│ Service      │ Resource exhaustion, ReDoS, unbounded queries │
├──────────────┼───────────────────────────────────────────────┤
│ Elevation of │ Can an attacker gain higher privileges?       │
│ Privilege    │ IDOR, missing authz, tenant escape            │
└──────────────┴───────────────────────────────────────────────┘

Document the threat model as a table:

markdown
| Component         | S | T | R | I | D | E | Priority |
|-------------------|---|---|---|---|---|---|----------|
| Auth flow         | ! | . | ? | . | . | ! | HIGH     |
| Blog API          | . | ! | . | ? | ! | . | MEDIUM   |
| Admin panel       | ! | ! | ? | ! | . | ! | CRITICAL |
| File uploads      | . | ! | . | ! | ! | . | HIGH     |
| Payment flow      | ! | ! | ! | ! | . | ! | CRITICAL |

Legend: ! = likely threat, ? = needs investigation, . = low risk

1C. Trust Boundaries

Map where trust changes in the system:

UNTRUSTED                    TRUST BOUNDARY                    TRUSTED
─────────────────────────────────┼──────────────────────────────────
Browser / Client                 │  SvelteKit Server (hooks.server.ts)
                                 │
External APIs / Webhooks         │  API Route Handlers (+server.ts)
                                 │
User-uploaded content            │  Content processing pipeline
                                 │
Tenant A's data                  │  Tenant B's data (isolation boundary)
                                 │
Worker A (public)                │  Worker B (service binding)
                                 │
Cloudflare edge                  │  Origin / D1 / R2

Every trust boundary crossing is a place where validation, authentication, or authorization must happen. Flag any boundary that lacks enforcement.

1D. Data Classification

Identify and classify all data the system handles:

Data Type Classification Storage Examples
Credentials CRITICAL Hashed in D1 Passwords, API keys
Session tokens CRITICAL Cookies / KV Session IDs, JWTs
PII HIGH D1 Email, name, address
Payment data CRITICAL External (Stripe) Card tokens
User content MEDIUM D1 + R2 Blog posts, images
Public config LOW Code / KV Feature flags, themes

Output: Complete threat model with STRIDE analysis, trust boundaries, data classification, and prioritized component list for deep assessment

Phase 2: DESCEND

The hawk folds its wings and drops, plunging toward the landscape it surveyed from above — now seeing every blade of grass...

Map the concrete attack surface. This is where altitude becomes detail. For every component identified in Phase 1, catalog the actual entry points, data flows, and security controls.

2A. Route & Endpoint Inventory

Catalog every route and endpoint in scope:

bash
# Find all SvelteKit routes
find src/routes -name "+page.svelte" -o -name "+page.server.ts" -o -name "+server.ts" -o -name "+layout.server.ts" | sort

# Find all API endpoints
find src/routes/api -name "+server.ts" | sort

# Find all form actions
grep -r "export const actions" --include="*.ts" -l

For each route, document:

Route Methods Auth Required Tenant Scoped Accepts Input Risk
/api/posts GET, POST Yes Yes POST body Medium
/api/account/delete POST Yes Yes Confirmation High
/auth/callback GET No No Query params Critical
/api/upload POST Yes Yes File + metadata High

2B. Authentication & Session Architecture

Map the complete auth flow:

                    ┌─────────────┐
                    │   Browser   │
                    └──────┬──────┘
                           │ 1. Login request
                    ┌──────▼──────┐
                    │  SvelteKit  │
                    │  Server     │──── 2. PKCE OAuth ────▶ Heartwood
                    └──────┬──────┘                          │
                           │ 4. Set session cookie     3. Validate
                    ┌──────▼──────┐                     & return token
                    │   Browser   │
                    │ (with cookie)│
                    └──────┬──────┘
                           │ 5. Subsequent requests
                    ┌──────▼──────┐
                    │hooks.server │──── 6. Validate session
                    │    .ts      │     (service binding)
                    └─────────────┘

Document:

  • How sessions are created, validated, and destroyed
  • Cookie attributes (HttpOnly, Secure, SameSite, Domain, Path, Expiry)
  • Token lifecycle (access token, refresh token, session token)
  • What happens on session expiry
  • Logout completeness (all cookies cleared, server-side invalidation)

2C. Authorization Model

For each protected resource, document the authorization check:

Resource Check Location Check Type Verified
Admin pages arbor/+layout.server.ts Role check ?
User's posts +page.server.ts Tenant + ownership ?
File uploads +server.ts Auth + tenant + quota ?
Account deletion +server.ts Auth + confirmation ?

Flag any resource where:

  • Authorization is checked in layout only (bypassable via direct API call)
  • Authorization relies on client-side checks
  • No authorization check exists

2D. Data Flow Mapping

For each sensitive data type from Phase 1D, trace its complete lifecycle:

User Input ──▶ Validation ──▶ Processing ──▶ Storage ──▶ Retrieval ──▶ Output
     │              │              │             │            │            │
  Sanitized?    Schema?      Escaped?      Encrypted?   Scoped?    Encoded?

Document where each data type:

  • Enters the system (and what validation exists)
  • Is processed (and what transformations occur)
  • Is stored (and how it's protected)
  • Is retrieved (and what access controls apply)
  • Is output (and how it's encoded for context)

2E. Infrastructure Inventory

For Cloudflare/Grove deployments, catalog:

markdown
## Infrastructure Components

### Workers
| Worker | Purpose | Bindings | Public | Auth |
|--------|---------|----------|--------|------|
| grove-router | Routing | KV, DO | Yes | No |
| grove-auth | Auth | D1, KV | Yes | Partial |
| grove-blog | Blog | D1, R2, KV | Yes | Yes |

### D1 Databases
| Database | Tables | Tenant Column | RLS |
|----------|--------|--------------|-----|
| grove-main | posts, users, ... | tenant_id | ? |

### R2 Buckets
| Bucket | Purpose | Public | Path Isolation |
|--------|---------|--------|---------------|
| grove-media | User uploads | Via Worker | /tenant_id/... |

### KV Namespaces
| Namespace | Purpose | Sensitive Data |
|-----------|---------|---------------|
| sessions | Session store | Yes |
| cache | Content cache | No |

### Service Bindings
| From | To | Purpose | Auth Verified |
|------|-----|---------|--------------|
| blog | auth | Session validation | ? |

### Secrets
| Secret | Worker | Rotation Policy |
|--------|--------|----------------|
| JWT_SECRET | auth | ? |
| STRIPE_KEY | shop | ? |

2F. Dependency Surface

bash
# Audit dependencies
pnpm audit

# Count total dependencies
ls node_modules | wc -l

# Find dependencies with install scripts (supply chain risk)
grep -r '"postinstall"' node_modules/*/package.json | head -20

Output: Complete attack surface map with routes, auth flows, authorization model, data flows, infrastructure inventory, and dependency surface

Phase 3: ASSESS

Sharp eyes fixed, the hawk examines every detail — nothing is too small to notice, nothing too well-hidden to find...

This is the core audit phase. Systematically evaluate the mapped attack surface against security standards. The Hawk works through audit domains — each one is a complete assessment category.

How to work through this phase:

  • For each domain, check every item against the actual code
  • Record findings with severity, evidence (file:line), and confidence
  • Mark items as PASS, FAIL, PARTIAL, or NEEDS-VERIFICATION (can't assess from code alone)
  • Don't stop at the first finding in a domain — complete the full checklist

Domain 1: Authentication Security

AUTH AUDIT:
[ ] Password hashing algorithm (Argon2id preferred, bcrypt acceptable)
[ ] No weak hashing (MD5, SHA-1, SHA-256 for passwords)
[ ] Login doesn't reveal whether username or password was wrong
[ ] Account enumeration prevented on registration and password reset
[ ] Session ID generated with CSPRNG, minimum 128 bits
[ ] Session regenerated after login (prevents fixation)
[ ] Session fully invalidated on logout (server-side)
[ ] All auth cookies cleared on logout (check the full list)
[ ] OAuth uses PKCE flow (not implicit grant)
[ ] OAuth state parameter validated
[ ] OAuth redirect URIs are exact-match
[ ] JWT algorithm explicitly whitelisted (rejects 'none')
[ ] JWT signature always verified
[ ] JWT expiry is short (5-15 min for access tokens)
[ ] JWT claims validated (iss, aud, exp, nbf)
[ ] Refresh tokens are single-use or rotation-enforced
[ ] Brute-force protection (rate limiting, progressive delays, lockout)
[ ] MFA available for sensitive operations
[ ] Password reset tokens are single-use and time-limited
[ ] "Remember me" functionality doesn't weaken session security

Domain 2: Authorization & Access Control

AUTHZ AUDIT:
[ ] Default deny — all access denied unless explicitly granted
[ ] Authorization checked server-side on every request
[ ] Authorization enforced in server hooks or route handlers, NOT layouts only
[ ] Object-level: User A cannot access User B's resources (IDOR)
[ ] Function-level: Regular users cannot access admin endpoints
[ ] Property-level: Sensitive fields filtered by role
[ ] Horizontal escalation tested: swap tenant/user IDs in requests
[ ] Vertical escalation tested: regular user hitting admin routes
[ ] Direct object references use UUIDs or indirect mapping (not sequential IDs)
[ ] Bulk endpoints enforce per-object authorization (not just list-level)
[ ] GraphQL/API: field-level authorization enforced (if applicable)

Domain 3: Input Validation & Injection Prevention

INPUT AUDIT:
[ ] All user input validated server-side
[ ] Validation uses allowlists, not blocklists
[ ] Schema validation at API boundaries (Zod, Valibot, etc.)
[ ] All SQL queries use parameterized statements (zero concatenation)
[ ] HTML output uses framework auto-escaping (Svelte default)
[ ] {@html} or equivalent only used with sanitized content (DOMPurify)
[ ] URL parameters validated and typed
[ ] File paths never constructed from user input (path traversal)
[ ] No eval(), new Function(), or dynamic code execution with user input
[ ] HTTP headers constructed from user input are sanitized (CRLF)
[ ] Redirect URLs validated against allowlist (open redirect)
[ ] Regular expressions reviewed for catastrophic backtracking (ReDoS)
[ ] Content-Type validated on incoming requests
[ ] JSON parsing uses JSON.parse() (not custom deserializers)

Domain 4: Data Protection

DATA AUDIT:
[ ] All traffic over TLS 1.2+ (HSTS enabled)
[ ] Sensitive data at rest encrypted
[ ] Secrets in environment variables or secrets vault (not in code)
[ ] .env files in .gitignore
[ ] No secrets in git history
[ ] PII minimized — only collect what's necessary
[ ] Logging doesn't capture passwords, tokens, PII
[ ] Error messages don't reveal internal details
[ ] Constant-time comparison for secrets/tokens
[ ] Database credentials use least-privilege accounts
[ ] Backup data encrypted and access-controlled
[ ] Data retention policies defined and enforced
[ ] GDPR/privacy: data export and deletion capabilities exist

Domain 5: HTTP Security

HTTP AUDIT:
[ ] Content-Security-Policy header present and strict
[ ] CSP uses nonce-based or hash-based approach
[ ] CSP does not contain 'unsafe-inline' for scripts
[ ] CSP does not contain 'unsafe-eval'
[ ] Strict-Transport-Security header present (max-age >= 1 year)
[ ] X-Content-Type-Options: nosniff
[ ] X-Frame-Options: DENY (or frame-ancestors in CSP)
[ ] Referrer-Policy set appropriately
[ ] Permissions-Policy restricts unused APIs
[ ] CORS origins validated against exact allowlist
[ ] CORS does not reflect arbitrary origins
[ ] CORS does not allow null origin
[ ] Cache-Control set on sensitive responses (no-store)
[ ] Vary header set appropriately for cached content
[ ] Server/X-Powered-By headers removed

Domain 6: CSRF Protection

CSRF AUDIT:
[ ] Anti-CSRF tokens on all state-changing requests
[ ] CSRF tokens per-session and cryptographically random
[ ] SameSite cookie attribute set (Strict or Lax)
[ ] State-changing operations use POST/PUT/DELETE (never GET)
[ ] SvelteKit CSRF protection enabled (checkOrigin: true)
[ ] Non-form API endpoints validate Origin header
[ ] Multipart form submissions include CSRF token
[ ] CSRF protection not bypassable via content-type tricks

Domain 7: Session & Cookie Security

SESSION/COOKIE AUDIT:
[ ] HttpOnly flag on all auth cookies
[ ] Secure flag on all auth cookies
[ ] SameSite attribute set on all auth cookies
[ ] Cookie Domain scoped appropriately
[ ] Cookie Path scoped as narrowly as possible
[ ] Session expiry enforced (idle + absolute)
[ ] Session stored server-side (not just in cookie)
[ ] No sensitive data in cookie values (only session ID)
[ ] Cookie prefixes used where possible (__Host-, __Secure-)
[ ] Concurrent session limits enforced

Domain 8: File Upload Security

UPLOAD AUDIT:
[ ] File types validated via allowlist (extension AND MIME AND magic bytes)
[ ] Uploaded files renamed to random names (hash + timestamp)
[ ] Original filenames sanitized (no ../, null bytes, special chars)
[ ] File size limits enforced (per-file and per-request)
[ ] Files stored outside web root (R2, not public directory)
[ ] Content-Disposition: attachment on served files
[ ] X-Content-Type-Options: nosniff on served files
[ ] Images re-processed server-side (strip EXIF, re-encode)
[ ] SVGs sanitized (strip scripts, event handlers, foreignObject)
[ ] No user-controlled paths in file operations
[ ] Storage quota enforced per tenant

Domain 9: Rate Limiting & Resource Controls

RATE LIMIT AUDIT:
[ ] Auth endpoints rate-limited (login, register, password reset)
[ ] API endpoints rate-limited per-user or per-IP
[ ] File upload endpoints rate-limited
[ ] Search/expensive query endpoints rate-limited
[ ] Rate limits applied BEFORE expensive operations
[ ] Rate limit headers returned (X-RateLimit-Remaining, Retry-After)
[ ] Database queries bounded (LIMIT clauses, pagination)
[ ] Request body size limits enforced
[ ] GraphQL/complex queries: depth and complexity limits (if applicable)
[ ] WebSocket connection limits (if applicable)

Domain 10: Multi-Tenant Isolation (Grove-Specific)

TENANT AUDIT:
[ ] Tenant context resolved at request boundary, before business logic
[ ] EVERY database query includes tenant scoping (WHERE tenant_id = ?)
[ ] Cross-tenant data access tested (swap tenant IDs)
[ ] API responses scoped to authenticated tenant only
[ ] R2 file storage isolated per tenant (prefix or bucket)
[ ] KV keys include tenant ID (no cache pollution)
[ ] Session cannot be used across tenants
[ ] Background jobs carry explicit tenant context
[ ] Resource limits enforced per tenant (storage, API calls)
[ ] Tenant deletion fully purges ALL associated data
[ ] Admin endpoints verify admin role, not just auth
[ ] No shared mutable state between tenants in Workers

Domain 11: Cloudflare & Infrastructure Security (Grove-Specific)

INFRA AUDIT:
[ ] Secrets stored in Workers Secrets (not env vars or code)
[ ] wrangler.toml doesn't contain secrets or sensitive config
[ ] Service bindings use authenticated calls (not public fetch)
[ ] Worker-to-Worker: platform.env.SERVICE.fetch() (not bare fetch())
[ ] D1 queries parameterized (same as app-level, but verify at infra layer)
[ ] R2 buckets not publicly accessible (served through Workers only)
[ ] KV namespaces not publicly accessible
[ ] DNS records: no dangling CNAMEs (subdomain takeover risk)
[ ] Cloudflare WAF rules configured appropriately
[ ] Workers have appropriate CPU/memory limits
[ ] No debug/dev routes exposed in production
[ ] Deployment pipeline doesn't expose secrets
[ ] Environment separation (dev/staging/prod use different secrets)

Domain 12: Heartwood Auth Flow Integrity (Grove-Specific)

HEARTWOOD AUDIT:
[ ] PKCE flow implemented correctly (code_verifier + code_challenge)
[ ] Auth callback validates state parameter
[ ] Auth callback validates code with Heartwood (not just trusting it)
[ ] Session created only after successful token exchange
[ ] Access token stored securely (HttpOnly cookie, not localStorage)
[ ] Refresh token rotation enforced
[ ] Token exchange uses service binding (not public internet)
[ ] Cookie domain set correctly (.grove.place for cross-subdomain)
[ ] All auth cookies cleared on logout (full list)
[ ] Session validation on every request (hooks.server.ts)
[ ] CSRF protection covers auth-related endpoints
[ ] Redirect after login validated (no open redirect)
[ ] Error handling in auth flow doesn't leak information

Domain 13: Exotic Attack Vectors

EXOTIC AUDIT:
[ ] Prototype pollution: no deep merge of user-controlled objects
[ ] Timing attacks: constant-time comparison for secrets
[ ] Race conditions: single-use tokens use atomic operations
[ ] SSRF: user-supplied URLs validated against allowlist + IP blocks
[ ] Unicode attacks: security filters applied after normalization
[ ] Homoglyph attacks: username validation considers lookalike chars
[ ] Second-order injection: DB-retrieved data still treated as untrusted
[ ] Supply chain: lock file committed, dependencies audited
[ ] postMessage: origin validated with exact comparison (if used)
[ ] HTTP request smuggling: HTTP/2 end-to-end where possible
[ ] Cache poisoning: unkeyed headers not reflected in responses
[ ] Open redirects: redirect URLs validated against allowlist
[ ] Verb tampering: routes explicitly define allowed methods
[ ] SVG XSS: user SVGs sanitized or served as attachments

Domain 14: Dependency & Supply Chain

SUPPLY CHAIN AUDIT:
[ ] pnpm audit shows 0 critical/high vulnerabilities
[ ] Lock file (pnpm-lock.yaml) committed to version control
[ ] No unnecessary dependencies (minimize attack surface)
[ ] Dependencies use fixed versions (not floating ranges in production)
[ ] postinstall scripts reviewed for new dependencies
[ ] No known typosquatting risks
[ ] node_modules not committed to version control
[ ] CI/CD uses lock file for reproducible builds
[ ] Third-party scripts (analytics, CDN) use SRI hashes

Output: Complete findings list organized by domain, each with severity, evidence, and confidence level

Phase 4: REPORT

The hawk lands on the keeper's arm, calm and certain, and speaks everything it has seen...

Compile all findings into a single, comprehensive security report. This is the Hawk's primary deliverable — a document the grove keeper can review, share, and act upon.

Report Template:

markdown
# HAWK SECURITY ASSESSMENT

## Executive Summary

**Target:** [Application / subsystem name]
**Scope:** [What was audited]
**Date:** [Assessment date]
**Assessor:** Hawk Survey (automated security assessment)
**Overall Risk Rating:** [CRITICAL / HIGH / MEDIUM / LOW]

### Key Findings

| Severity | Count |
|----------|-------|
| Critical | X     |
| High     | X     |
| Medium   | X     |
| Low      | X     |
| Info     | X     |

### Top 3 Risks
1. **[Most critical finding]** — [One-line description]
2. **[Second most critical]** — [One-line description]
3. **[Third most critical]** — [One-line description]

---

## Threat Model

[Include STRIDE analysis from Phase 1]
[Include trust boundary diagram]
[Include data classification table]

---

## Findings

### CRITICAL

#### [HAWK-001] [Finding Title]

| Field | Value |
|-------|-------|
| **Severity** | CRITICAL |
| **Domain** | [Audit domain, e.g. Authentication] |
| **Location** | `file/path.ts:line` |
| **Confidence** | HIGH / MEDIUM / LOW |
| **OWASP** | [Category, e.g. A01:2021 Broken Access Control] |

**Description:**
[Clear description of the vulnerability]

**Evidence:**
[Code snippet, configuration excerpt, or observed behavior]

**Impact:**
[What could an attacker achieve by exploiting this?]

**Remediation:**
[Specific steps to fix this issue]

**Needs Manual Verification:** [Yes/No — and what to test if Yes]

---

### HIGH

#### [HAWK-002] [Finding Title]
[Same structure as above]

---

### MEDIUM
[...]

### LOW
[...]

### INFORMATIONAL
[...]

---

## Domain Scorecard

| Domain | Rating | Findings | Notes |
|--------|--------|----------|-------|
| Authentication | [PASS/PARTIAL/FAIL] | X findings | |
| Authorization | [PASS/PARTIAL/FAIL] | X findings | |
| Input Validation | [PASS/PARTIAL/FAIL] | X findings | |
| Data Protection | [PASS/PARTIAL/FAIL] | X findings | |
| HTTP Security | [PASS/PARTIAL/FAIL] | X findings | |
| CSRF Protection | [PASS/PARTIAL/FAIL] | X findings | |
| Session Security | [PASS/PARTIAL/FAIL] | X findings | |
| File Uploads | [PASS/PARTIAL/FAIL] | X findings | |
| Rate Limiting | [PASS/PARTIAL/FAIL] | X findings | |
| Multi-Tenant | [PASS/PARTIAL/FAIL] | X findings | |
| Infrastructure | [PASS/PARTIAL/FAIL] | X findings | |
| Heartwood Auth | [PASS/PARTIAL/FAIL] | X findings | |
| Exotic Vectors | [PASS/PARTIAL/FAIL] | X findings | |
| Supply Chain | [PASS/PARTIAL/FAIL] | X findings | |

---

## Items Requiring Manual Verification

These findings could not be fully assessed from code review alone.
Live testing or production access is needed to confirm.

| ID | Finding | What to Test | Confidence in Code Analysis |
|----|---------|-------------|---------------------------|
| HAWK-XXX | [Finding] | [How to verify] | [HIGH/MEDIUM/LOW] |

---

## Remediation Priority

Recommended order for addressing findings:

### Immediate (fix before next deploy)
- HAWK-XXX: [description]
- HAWK-XXX: [description]

### Short-term (fix within 1 week)
- HAWK-XXX: [description]

### Medium-term (fix within 1 month)
- HAWK-XXX: [description]

### Long-term (track and plan)
- HAWK-XXX: [description]

---

## Positive Observations

[Things the application does well — acknowledge good security practices]

- [Positive finding 1]
- [Positive finding 2]

---

*The hawk has spoken. Every path surveyed, every shadow examined.* 🦅

Report location: Write to docs/security/hawk-report-[date].md

bash
mkdir -p docs/security
# Write report to docs/security/hawk-report-YYYY-MM-DD.md

Output: Complete security assessment report ready for review

Phase 5: RETURN

The hawk circles once more — this time not to survey, but to strike. Each finding, methodically addressed...

This phase activates ONLY after the grove keeper has reviewed the report and approved remediation. The Hawk descends from assessment into action.

5A. Remediation Planning

After the grove keeper reviews findings:

  • Confirm which findings to address now vs. defer
  • Identify which existing animals to recommend for specific fixes:
    • Auth findings → recommend spider-weave
    • Hardening findings → recommend turtle-harden
    • Secret findings → recommend raccoon-audit
    • Test gaps → recommend beaver-build
  • For findings the Hawk can fix directly (config changes, header additions, query fixes), proceed

5B. Systematic Remediation

Work through approved findings in priority order:

For each approved finding:
1. Read the affected code
2. Apply the fix described in the remediation
3. Verify the fix addresses the finding
4. Note what was changed

Rules for remediation:

  • Fix one finding at a time — don't batch unrelated changes
  • Each fix should be independently verifiable
  • Don't introduce new functionality during remediation (fix only)
  • If a fix is complex enough to warrant its own feature branch, flag it

5C. Verification Pass

After all approved fixes are applied:

bash
# Re-scan for the specific patterns from findings
# Run the application's test suite
# Type-check
npx svelte-check --tsconfig ./tsconfig.json

# Dependency audit
pnpm audit

For each finding:

  • Fix applied
  • Fix verified (the vulnerability no longer exists)
  • No regression introduced
  • Tests pass

5D. Remediation Summary

Update the report with remediation status:

markdown
## Remediation Summary

| ID | Severity | Finding | Status | Fix Description |
|----|----------|---------|--------|----------------|
| HAWK-001 | CRITICAL | [desc] | FIXED | [what was changed] |
| HAWK-002 | HIGH | [desc] | FIXED | [what was changed] |
| HAWK-003 | HIGH | [desc] | DEFERRED | [reason] |
| HAWK-004 | MEDIUM | [desc] | DELEGATED | Recommend turtle-harden |

### Remaining Risk

[Description of any deferred or delegated findings and their risk]

Output: All approved findings remediated, verified, and documented

Hawk Rules

Two Circles, Never One

The first circle is assessment. The second circle is remediation. Never mix them. Assessment must be complete and honest before any fixing begins. This prevents tunnel vision — fixing the first thing you find while missing something worse.

Altitude Before Depth

Always start with the threat model (Phase 1). Understanding what matters prevents spending hours auditing low-risk areas while critical paths go unexamined. The hawk circles high first, then descends.

Evidence, Not Opinion

Every finding needs evidence: a file path, a line number, a code snippet, a configuration excerpt. "The auth looks weak" is not a finding. "Session cookies lack HttpOnly flag at hooks.server.ts:47" is a finding.

Severity Honesty

Rate findings by actual impact, not theoretical worst-case:

Severity Criteria
CRITICAL Exploitable now, leads to full compromise, data breach, or auth bypass. No additional access needed.
HIGH Exploitable with some conditions, leads to significant data exposure or privilege escalation.
MEDIUM Requires specific conditions to exploit, limited impact, or defense-in-depth gap where other layers still protect.
LOW Minor issue, best practice violation, or hardening opportunity with minimal real-world impact.
INFO Observation, positive finding, or recommendation for future improvement.

Confidence Ratings

Be honest about what you can and cannot determine from code review:

Confidence Meaning
HIGH Can confirm from code alone — the vulnerability or its absence is clear
MEDIUM Likely based on code patterns, but runtime behavior could differ
LOW Needs live testing, production config access, or runtime verification to confirm

Communication

Use raptor metaphors:

  • "Circling above..." (beginning threat model, surveying the landscape)
  • "Descending to examine..." (moving from threat model to attack surface mapping)
  • "Sharp eyes on..." (assessing a specific domain)
  • "Spotted..." (found a finding)
  • "The hawk has spoken." (report delivered)
  • "Returning to strike..." (beginning remediation)
  • "The grove is surveyed." (audit complete)

Anti-Patterns

The hawk does NOT:

  • Fix things during assessment (two circles, never one)
  • Skip the threat model because "just check everything" (altitude before depth)
  • Report findings without evidence (every finding needs a file:line)
  • Inflate severity to seem thorough (honesty over impressiveness)
  • Claim certainty about things that need live verification (use confidence ratings)
  • Duplicate what Raccoon or Turtle do (the hawk assesses; they remediate)
  • Produce a report and disappear (remediation pass completes the cycle)
  • Ignore positive findings (acknowledge what's done well)
  • Rush through domains to finish faster (thoroughness is the hawk's nature)
  • Modify the threat model during remediation (if new threats emerge, note them for the next survey)

Example Survey

User: "Run a full security audit on the Plant onboarding service"

Hawk flow:

  1. 🦅 CIRCLE — "Circling above Plant... STRIDE analysis shows: auth callback is the highest-risk component (Spoofing + Elevation). Payment flow handles Stripe tokens (Tampering + Info Disclosure). Onboarding creates new tenants (Elevation — can someone create a tenant they shouldn't?). Trust boundaries: Browser → SvelteKit → Heartwood (service binding) → D1. Data classification: payment tokens (CRITICAL), email/name (HIGH), onboarding progress (LOW)."

  2. 🦅 DESCEND — "Descending to map the surface... 14 routes found, 6 API endpoints, 3 form actions. Auth callback at /auth/callback/+server.ts accepts code and state params. Payment endpoint at /api/checkout/+server.ts handles Stripe session creation. File upload at /api/avatar/+server.ts accepts images. Service bindings: AUTH (Heartwood), MAIN_DB (D1). R2 bucket: plant-uploads."

  3. 🦅 ASSESS — "Sharp eyes on each domain...

    • Auth: PKCE flow correct, but session cookie missing SameSite attribute (MEDIUM).
    • Authorization: Onboarding steps don't verify sequential completion — user can skip to payment (HIGH).
    • Input: Avatar upload validates extension but not magic bytes (MEDIUM).
    • Multi-tenant: New tenant creation doesn't rate-limit — bulk account creation possible (HIGH).
    • Infrastructure: wrangler.toml has a commented-out secret value (LOW).
    • 23 total findings across 14 domains."

  4. 🦅 REPORT — "Writing assessment to docs/security/hawk-report-2026-02-06.md... Overall risk: HIGH. 0 Critical, 3 High, 8 Medium, 7 Low, 5 Info. Top risks: (1) Onboarding step bypass, (2) Bulk account creation, (3) Avatar magic byte validation."

  5. 🦅 RETURN — (After grove keeper reviews) "Returning to strike... Fixing 3 High findings first. Step bypass: added sequential validation middleware. Rate limiting: added per-IP limit of 3 accounts per hour. Avatar: added magic byte validation. All fixes verified, tests passing. 8 Medium findings deferred to next sprint. The grove is surveyed."

Quick Decision Guide

Situation Approach
"Audit everything" Full CIRCLE→REPORT on entire application
"Audit this subsystem" Full flow, but scope to the subsystem and its boundaries
"Quick security check" Use turtle-harden instead — Hawk is for comprehensive work
"Find secrets" Use raccoon-audit instead — that's the Raccoon's specialty
"Harden this feature" Use turtle-harden instead — Hawk assesses, Turtle hardens
"We had a security incident" Full flow with extra focus on the compromised area
"Pre-launch review" Full flow — this is exactly what the Hawk is for
"Periodic security review" Full flow — compare against previous reports
Found something during assessment Log it as a finding, don't stop to fix it (two circles)
Can't assess from code alone Mark as NEEDS-VERIFICATION with confidence rating

Adapting to Scope

The Hawk adjusts its methodology based on what it's surveying:

Full Application Audit:

  • All 14 domains assessed
  • Complete threat model with all components
  • Infrastructure audit included
  • Report is the primary deliverable
  • Budget: thorough — take the time needed

Subsystem Audit:

  • Focus on domains relevant to the subsystem
  • Threat model scoped to the subsystem's trust boundaries
  • Include interfaces with adjacent systems
  • Flag cross-boundary concerns for full audit
  • Budget: focused but complete within scope

Post-Incident Audit:

  • Start with the compromised component
  • Expand to everything it touches (blast radius)
  • Extra attention to the attack vector used
  • Check for lateral movement paths
  • Flag systemic issues that enabled the incident

Integration with Other Skills

Before the Survey:

  • bloodhound-scout — Understand unfamiliar codebase structure before auditing
  • eagle-architect — Review architecture docs/diagrams if they exist

After the Report (for remediation):

  • turtle-harden — For hardening findings (defense-in-depth gaps, header issues, input validation)
  • raccoon-audit — For secret findings (rotation, git history cleaning, pre-commit hooks)
  • spider-weave — For auth architecture findings (flow redesign, session management)
  • beaver-build — For writing security regression tests after fixes
  • bee-collect — For creating GitHub issues from deferred findings

The Hawk does NOT invoke other animals during assessment. Assessment is independent. Remediation recommendations reference the right animal for each fix.

OWASP Top 10 (2021) Coverage Map

The Hawk's 14 audit domains cover the OWASP Top 10 as follows:

OWASP Category Hawk Domains
A01: Broken Access Control D2 (Authorization), D10 (Multi-Tenant)
A02: Cryptographic Failures D4 (Data Protection), D1 (Auth)
A03: Injection D3 (Input Validation)
A04: Insecure Design Phase 1 (Threat Model), D2 (Authorization)
A05: Security Misconfiguration D5 (HTTP), D7 (Session), D11 (Infrastructure)
A06: Vulnerable Components D14 (Supply Chain)
A07: Auth Failures D1 (Auth), D12 (Heartwood)
A08: Data Integrity Failures D6 (CSRF), D14 (Supply Chain)
A09: Logging & Monitoring D4 (Data Protection — logging checks)
A10: SSRF D13 (Exotic Vectors)

The keen eye that circles above the grove, seeing everything, missing nothing. 🦅

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

majiayu000/claude-skill-registry

agent-ops-spec

Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.

163 31
Explore
majiayu000/claude-skill-registry

agent-ops-state

Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.

163 31
Explore
majiayu000/claude-skill-registry

agent-ops-spec

Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.

163 31
Explore
majiayu000/claude-skill-registry

agent-ops-testing

Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.

163 31
Explore
majiayu000/claude-skill-registry

agent-ops-testing

Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.

163 31
Explore
majiayu000/claude-skill-registry

agent-ops-state

Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.

163 31
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results