Triager
Shepherd Triager
Automated evidence collection for bug bounty submissions. Produces structured reports so your security team can accept or reject findings in minutes with the data to back up your claims.
The Problem
AI models can now generate bug bounty submissions that reference real code, construct plausible attack narratives, and frame severity convincingly. A lot of these are incorrect; but they're wrong in ways that take experienced engineers hours to identify. A submission might trace a valid call chain through three contracts, correctly identify a state transition, and still miss a single access control check that makes the entire attack path unreachable.
The bottleneck is not quantity or filtering. It's the ability to prove and take immediate action - determining whether a claimed vulnerability is actually exploitable given the full contract state, dependencies, and production configuration.
What Shepherd Triager Does
For every submission, Shepherd collects evidence across 106+ independent checks spanning code comprehension, PoC verification, state provenance, reachability analysis, safeguard discovery, intent adjudication, and attacker incentive modeling.
Every report gives you:
A structured verdict with the evidence chain behind it
Both sides of the argument - the strongest case for and against the finding
Pre-written response scripts you can copy-paste to accept or reject
Follow-up readiness with counter-evidence prepared
Open questions that only your team can answer - the actual decision points
Your team makes the final call. Shepherd makes sure you have everything you need to make it fast and defend it confidently.
What It Checks
Code Verification
Compiles the codebase and traces the full call chain from the referenced function through every contract it touches
Reads code comments across related contracts to detect architectural intent and delegation patterns
Maps which privileged functions write state that public functions read
PoC Execution
Runs the submitter's PoC against the actual codebase
Audits whether the PoC's test setup matches your real deployment or tests a configuration that doesn't exist in production
Checks whether the PoC actually proves what the submission claims - catches parameter overstatement, assertion mismatches, and claim conflation
When no PoC is provided, attempts to construct one from the submission description
Exploit Reachability
Classifies every precondition the exploit depends on: can the attacker create it, does it require a third party, or does it only exist in the test harness?
Audits every Foundry cheatcode for shortcuts that wouldn't work on a real chain
Determines if the trigger is attacker-controlled or depends on external conditions (oracle state, admin action, governance vote)
Safeguard Discovery
Checks declared safeguards from your protocol config against the actual attack path
Searches the codebase for undeclared protective mechanisms - reentrancy guards, rate limiters, circuit breakers, minimum deposits, timelocks, cross-contract validation
Identifies architectural delegation where a check exists in a different contract than the one the submission references
Intent Analysis
Searches all related contracts for code comments describing design decisions - the strongest possible evidence of intent
Checks if the protocol's own test suite asserts the behavior the submission claims is broken
Compares the submission against your declared known issues and learned rules from prior triage feedback
Impact Assessment
Calculates attacker P&L: gross extraction minus gas, fees, slippage, and capital costs
Classifies the finding's magnitude from the actual deployment context - your collateral types, chain, and oracle setup
Separates theoretical maximum damage from realistic damage given production parameters
Verdicts
CONFIRMED_EXPLOITABLE = Invariant breaks, reachable, profitable
CONFIRMED_CONDITIONAL = Real but depends on external conditions the attacker cannot control
CONFIRMED_NOT_EXPLOITABLE = Code issue exists but cannot be exploited in production
BY_DESIGN = Behavior is documented as intended in code comments and architecture
INFORMATIONAL = Valid observation (hardening, trust model, standards) but no concrete exploit
NOT_REAL = No mechanism or code pattern identified
NEEDS_MORE_INFO = Unresolved blocking issues prevent a confident determination
UNPROVEN = Plausible mechanism found but could not be proven via PoC
Protocol Onboarding
Your protocol is configured via a TOML file that declares:
- In-scope files and deployed contract addresses
- Chain and RPC endpoints for on-chain verification
- Bounty program rules (excluded classes, severity thresholds, PoC requirements)
- Known issues from prior audits (findings are checked against these)
- Roles and actor model (which addresses are privileged)
- Safeguards and timelocks
- Operational context (current protocol phase — normal, migration, shutdown)
Prior audit findings are automatically ingested as known issues so Shepherd can distinguish genuinely new findings from rediscoveries.
Feedback Loop
When your team overrides a verdict, Shepherd extracts a learned rule. Future submissions matching the same pattern are flagged with the rule and its origin. Rules older than 90 days without reconfirmation are marked stale so your triage posture stays current.
Last updated