# ExploitSpec roadmap ExploitSpec is building an open format and local runner for permanent security regression tests. The roadmap is outcome-based, not date-based. Items below are directions for discussion, not commitments or claims about current behavior. Only checked items are available today. ## Project commitment ExploitSpec is a public-interest open-source project: - one official edition under Apache-2.0; - all official features available without payment; - local-first execution with no required account or hosted control plane; - no product telemetry; - no “community” build designed to upsell a closed enterprise build; - public design decisions, specification, and issue tracker. Apache-2.0 permits individuals and companies to use, modify, and redistribute the software, including commercially. The official project's commitment is to keep its own implementation and development in the open. Recognition should come from technical quality, a useful standard, reproducible research, and a contributor community—not lock-in. ## Available today - [x] Strict, single-document YAML version 1 format - [x] `init`, `import curl`, `import har`, `validate`, `run`, `calibrate`, and `version` commands - [x] Bounded cURL import without shell execution, with conservative structural replacement of imported string values - [x] Recursive deterministic spec discovery - [x] Multiple actors with independent cookie sessions - [x] Ordered HTTP request workflows - [x] Environment, document-variable, and captured-variable interpolation - [x] Raw and JSON request bodies - [x] Status, body, regex, JSON-path, and response-header assertions - [x] JSON-path, response-header, and regex captures - [x] Human-readable, JSON, and JUnit reports - [x] RED/GREEN/STABLE calibration against vulnerable and fixed targets - [x] Explicit remote-host authorization and redirect validation - [x] Metadata-IP blocks, TLS defaults, timeouts, and response-size limits - [x] Deterministic pass/fail/error exit codes - [x] Local execution without accounts or telemetry The exact behavior and current limitations are documented in [docs/specification.md](docs/specification.md). ## Milestone 1 — Trust the runner Before expanding the format, make the existing core boringly reliable. - [x] Comprehensive unit and integration tests for parsing, interpolation, actors, assertions, captures, reporting, and exit codes - [x] Dedicated adversarial tests for URL parsing, redirects, host matching, response limits, and secret exposure - [ ] Dedicated verification across supported HTTP proxy configurations - [x] Supported Go-version CI matrix and cross-platform release builds - [ ] Reproducible release artifacts with cryptographic provenance - [ ] Published compatibility policy for pre-1.0 specs and reports - [x] Machine-readable JSON Schema aligned with the version 1 document shape - [x] Clear secret-redaction rules for every report format - [ ] Fuzzing for YAML loading, JSON-path parsing, templates, and URL resolution Success means maintainers can change internals confidently without weakening a documented invariant or safety boundary. ## Milestone 2 — Make authoring excellent Writing a correct spec should take minutes after a finding has been proven. - [ ] Actionable validation errors with source line and column information - [ ] `explain` output for resolved execution plans without sending requests - [ ] Opt-in dry-run request rendering with safe secret redaction - [ ] More complete but still bounded JSON selectors - [ ] Reusable request fragments without arbitrary scripting - [ ] Explicit setup and cleanup semantics with failure-safe cleanup - [ ] A public cookbook for BOLA/IDOR, tenant isolation, role boundaries, and sensitive-property leakage - [ ] Sanitized sample applications that demonstrate RED/GREEN/STABLE end to end - [ ] Editor completion and validation based on the published schema Success means a pentester can translate a confirmed HTTP proof into a readable invariant without learning a programming framework. ## Milestone 3 — Capture proven evidence Reduce transcription while keeping a human in control of the invariant. - [x] Generate a reviewable single-request starter spec from supported cURL text - [x] Import one explicitly selected HTTP message from a bounded, sanitized HAR 1.2 file without replaying traffic - [ ] Capture-assisted authoring from an intercepting proxy workflow - [ ] Interactive mapping of requests to actors - [ ] Suggested captures for dynamic IDs, CSRF tokens, and response headers - [ ] Suggested assertions that require explicit review and editing - [ ] Secret and personal-data detection before a generated spec is saved - [ ] A provenance note linking a spec to a sanitized finding identifier Import must generate ordinary reviewable YAML. It must not create a hidden recording format or silently upload traffic. Success means existing pentest evidence becomes a durable test with less manual copying, without pretending that automatic inference proves a vulnerability. ## Milestone 4 — A stable public specification - [ ] Publish the version 1 compatibility contract - [ ] Define change and deprecation rules - [ ] Publish normative fixtures shared by alternative implementations - [ ] Stabilize JSON and JUnit report contracts - [ ] Document extension namespacing before accepting vendor-specific fields - [ ] Independent runner compatibility tests - [ ] Security review of the stable format and reference runner - [ ] First stable release Success means another team can implement the format from public documentation and produce behavior consistent with the reference runner. ## Community and visibility The best distribution strategy for a free security tool is credible public work. Priorities include: - [x] A short reproducible demo: vulnerability, fix, and RED/GREEN/STABLE proof - [ ] Public benchmark cases with known vulnerable and fixed application states - [ ] Small, well-scoped `good first issue` and `help wanted` work - [ ] Contributor acknowledgements in releases - [ ] Technical write-ups about invariant design and failure modes - [ ] Conference-ready demos built entirely from public repositories - [ ] Collaboration with pentesters, AppSec teams, and vulnerable training apps - [ ] A public gallery of sanitized community specs with clear provenance No usage tracking is needed to demonstrate impact. Public dependents, stars, contributors, citations, reproducible case studies, and real integrations are better signals. ## Non-goals ExploitSpec is not currently trying to become: - a general vulnerability scanner; - an autonomous exploitation agent; - a replacement for pentesters, threat modeling, or code review; - a browser automation framework; - a full API testing language; - a SaaS dashboard or vulnerability-management platform; - a secret store or identity provider; - a mechanism for testing systems without authorization; - a marketplace, paid tier, or lead-generation funnel. A proposed feature that moves toward one of these areas needs a compelling security-invariant use case and a public design discussion. ## How priorities are chosen Work is prioritized by: 1. correctness of pass, fail, and error outcomes; 2. safety of target selection and secret handling; 3. ability to express real confirmed authorization regressions; 4. stability and reviewability of the public format; 5. ease of local use and contribution; 6. ecosystem reach without central control. Feature count is not a success metric. A small runner that teams trust is more valuable than a broad platform that produces ambiguous evidence. ## Propose a roadmap change Open an issue describing: - the confirmed workflow that cannot be expressed today; - the smallest proposed behavior; - how it remains deterministic and reviewable; - its impact on safety, privacy, compatibility, and implementation complexity; - why composition outside the core is insufficient. Roadmap discussions and contributions follow [CONTRIBUTING.md](CONTRIBUTING.md) and the [Code of Conduct](CODE_OF_CONDUCT.md).