sekolah76/syadagentic/exploitability-analyzer

Exploitability Analyzer

Mission

Bridge the gap between “the defect exists” and “an attacker can exploit it.” Evaluate reachability, controllability, prerequisites, mitigations, reliability, economics, timing, victim interaction, deployment relevance, and impact realization.

This skill must actively search for blockers and must not reward optimistic assumptions.

Required inputs

• Verified primitive and evidence.
• Root-cause analysis.
• Target scope and threat model.
• Deployment/configuration profile.
• Claimed impact and proposed attack path.

Exploitability dimensions

1. Attacker position

Classify the least-privileged realistic attacker:

• remote unauthenticated;
• authenticated ordinary user;
• cross-tenant user;
• malicious contract/token/peer;
• relayer/oracle/validator subset;
• local user;
• administrator/insider;
• compromised host or victim malware.

2. Reachability

Confirm the production path from attacker input to primitive. Account for upstream proxies, gateways, middleware, feature flags, network topology, compile profile, and default configuration.

3. Controllability

Determine exactly which values, ordering, timing, state, identities, signatures, balances, or messages the attacker controls. Partial control must not be treated as arbitrary control.

4. Preconditions

List every prerequisite and classify:

• attacker-provided;
• naturally occurring;
• victim-dependent;
• privileged;
• rare/race-dependent;
• out-of-scope compromise;
• economically acquired.

5. Mitigations and blockers

Search for:

• validation at another layer;
• rate limits and quotas;
• authentication/authorization binding;
• sandboxing and process isolation;
• supervisor restart and redundancy;
• transaction reversion and atomicity;
• slippage, liquidity, fees, finality, and MEV competition;
• quorum, honest-majority, replay protection, and deterministic checks;
• monitoring, circuit breakers, caps, timelocks, pause controls;
• user warnings or explicit confirmations.

6. Reliability

Measure or bound:

• success rate;
• attempts required;
• timing window;
• race reproducibility;
• environmental sensitivity;
• persistence;
• ability to repeat or scale;
• detectability and interruption risk.

Do not use “reliable” without repeated evidence.

7. Impact realization

Separate primitive from final impact:

verified primitive → intermediate capability → boundary crossed → measurable impact

Examples:

• worker panic is not automatically service-wide DoS;
• token disclosure is not automatically account takeover;
• arbitrary external call is not automatically fund loss;
• local state mismatch is not automatically consensus divergence;
• temporary oracle deviation is not automatically extractable profit.

8. Economic and operational feasibility

For Web3 record capital, liquidity, slippage, fees, gas, unwind, net value, transaction ordering, oracle windows, and recoverability.

For Web2 record infrastructure scale, victim interaction, request volume, access durability, cloud permissions, and operational blast radius.

Confidence caps

Apply these maximum confidence values unless stronger evidence exists:

• path not proven: 45;
• attacker control inferred only: 55;
• production configuration unknown: 60;
• primitive reproduced but final impact not demonstrated: 70;
• relies on rare race without statistics: 65;
• requires excluded compromise or malware: classify threat-model mismatch;
• economic profitability not modeled: 70 for financial impact;
• consensus/network-wide effect not reproduced or formally established: 75.

Verdicts

• PRACTICALLY_EXPLOITABLE
• CONDITIONALLY_EXPLOITABLE
• THEORETICAL_ONLY
• BLOCKED_BY_MITIGATION
• THREAT_MODEL_MISMATCH
• INSUFFICIENT_EVIDENCE

Output

Use templates/exploitability-analysis.yaml. Required next tests must be minimal, safe, and specific.