Get started

Our method

Every test mapped.
Every finding proven.

Heist pentests your live application against a public standard. You see what was tested, not just what was found. Every finding comes with proof.

Step 01 / Map

Map every route and role

Heist logs into your application and walks it like a user. Every route, endpoint and form is recorded. Roles and tenants are mapped separately so access control can be tested between them.

Surface mapapp.example.com
  • /auth/loginpublic
  • /dashboarduser
  • /settings/teamadmin
  • /api/v2/usersapi
  • /api/v2/users/{id}/profileapi
  • /api/v2/billingapi
  • /webhooksapi

38

endpoints

4

roles

3

auth flows

Step 02 / Test

Run the full standard

Testing follows OWASP ASVS 5.0. That is around 350 requirements across 17 categories. Every endpoint gets every applicable check. The standard is public so you can read exactly what a pass means.

Test planOWASP ASVS 5.0
  1. V1Encoding and Sanitization
  2. V2Validation and Business Logic
  3. V3Web Frontend Security
  4. V4API and Web Service
  5. V5File Handling
  6. V6Authentication
  7. V7Session Management
  8. V8Authorization
  9. V9Self-contained Tokens
  10. V10OAuth and OIDC
  11. V11Cryptography
  12. V12Secure Communication
  13. V13Configuration
  14. V14Data Protection
  15. V15Secure Coding and Architecture
  16. V16Security Logging and Error Handling
  17. V17WebRTC
~350 requirementsapplied on every full run

Step 03 / Validate

No finding without proof

Heist proves findings by exploiting them without destructive actions. Every finding includes the exact request, the response and steps to reproduce. What cannot be proven is not reported.

Proof of exploitCritical
Finding
IDOR on user profile endpoint
ASVS
V8 Authorization
Target
/api/v2/users/{id}/profile
GET /api/v2/users/4812/profile
Authorization: Bearer tok_user_3291

HTTP/1.1 200 OK
# authenticated as 3291. returned profile 4812
Reproduced without destructive actionsevidence attached

Step 04 / Fix

Findings land where you work

Each finding arrives in Linear or Slack with severity, repro steps and the violated ASVS requirement. Fix it yourself or hand it to Claude over MCP. Nothing gets lost in a PDF.

DeliveryHEI-247
  • LN

    Linear issue created

    HEI-247 · IDOR on /api/v2/users/{id}/profile

  • SL

    Slack alert sent

    #security-alerts · critical · repro attached

  • MCP

    MCP handoff

    heist.get_finding("HEI-247") -> fix branch opened

Severity, repro steps and the ASVS reference travel with every finding.

Step 05 / Retest

Fixed means verified

Push a fix and trigger a retest. Heist runs the original exploit again and records the outcome. The record is timestamped from first report to confirmed fix.

Retest logHEI-247
  1. Day 0 · 09:12

    Finding reported

    IDOR on user profile endpoint

  2. Day 1 · 14:38

    Fix deployed

    ownership check added

  3. Day 1 · 14:41

    Retest passed

    finding closed

Fix confirmed, record closedretest: 3 min

Continuity

Remembers your application

Structure, roles and workflows carry forward between runs. Changes get tested first.

Evidence

Audit-ready by default

Every run is logged and every finding maps to an ASVS requirement. The trail holds up in SOC 2 and ISO 27001 audits.

Safety

Safe on production

Scoped credentials, guardrails and a kill switch. Proof without destructive actions.

Recognised by auditors, loved by engineers.

Get started

No code base access needed