Where it fits
Your workflow does not change. Only who does the retest.
Same tracker, same steps to reproduce, same deliverable. RiftX takes the finding as your pentester wrote it, retests it against the live target wherever that target sits, and hands back a sealed verdict you can put straight into the report.
Jira
Push the finished retest back as an issue on the ticket it came from.
Client environments are the hard part, so start there
Most retest targets are not on the public internet. Four things decide whether this works for you at all.
Behind a VPN
Attach a VPN profile to a retest and its traffic tunnels through it. Profiles belong to your tenant and are never shared.
On an intranet
Route a retest through your own upstream proxy. Internal addresses are valid targets here, not blocked ones.
Behind MFA
Credentials go in with the steps. A code request mid-run pauses the retest and asks you for it, then it picks up where it stopped. Unanswered for two minutes, the retest stops without a verdict.
On internal DNS
A hostname that exists only inside your network resolves on your side of the tunnel, not ours. The agent's command-line tools go through the tunnel too, so sqlmap reaches an intranet host.
Execution is isolated per retest. How the data itself is handled and held is on Privacy.
One call submits a retest. There is no taxonomy to map.
You send the target and the reporter’s steps as prose. RiftX works the rest out from what your pentester already wrote, so there is no type field to map and nothing to re-sync when your finding taxonomy changes.
Every field is one you already have.
- target_url
- Straight off the finding.
- reporter_notes
- The steps as your pentester already wrote them, in prose.
- engagement_tag
- Your grouping, in your own words.
- finding_ref
- Your own reference, kept on the job.
- No field for
- A vulnerability type. A payload. A severity. A scan profile.
One call sends it. Three bring it back.
The submit returns a job id. Everything after it is a GET.
- GET/jobs/9f3a2b1c{ "status":"completed","classification":"TRUE_POSITIVE","confidence_score":0.96,"triage_reason":"The q parameter still reflects unencoded" }
- GET/jobs/9f3a2b1c/evidence{ "total_steps":12,"has_video":true,"har_available":true,"expires_in":3600 }
- GET/jobs/9f3a2b1c/evidence/seal{ "seal_status":"INTACT","files_checked":14,"files_passed":14,"merkle_root_match":true,"hmac_valid":true }
The verdict arrives with the evidence to check it.
- /jobs/{id}
- Which way the retest went, how sure it is, and the reason in the engine's own words.
- /jobs/{id}/evidence
- Every step it took, the screen recording, and the network trace behind them.
- /jobs/{id}/evidence/seal
- Every file re-downloaded and re-hashed. INTACT means nothing moved since the worker sealed it.
- On the wire
- TRUE_POSITIVE is Not Fixed, FALSE_POSITIVE is Fixed, REVIEW_REQUIRED is Needs Review.
Want the full endpoint reference before you commit an afternoon to this? Ask us for it.
The verdict goes where the finding already lives
A finished retest is structured data behind one API key. These are the four places a verdict lands in a practice, and wiring it into any of them is a few lines against those same endpoints.
Issue trackers
- Jira
- Linear
- GitHub
- GitLab
The issue opens on the ticket the finding came from, with the verdict and the evidence links on it.
Reporting platforms
- PlexTrac
- AttackForge
- Dradis
- Ghostwriter
The verdict is written onto the finding of record, so the deliverable is assembled from the row your pentester already filed rather than from a copy.
Chat
- Slack
- Microsoft Teams
- Mattermost
A message in the channel the moment a verdict lands, so whoever owns the retest reads the result without opening a dashboard or a ticket.
Your own code
- The REST API
Submit a whole engagement at once, read the verdicts back off the jobs as they finish, and pull each manifest and its seal into whatever assembles your deliverable.
Not listed? The four groups above are examples, not the boundary. Tell us where your findings live and we will wire the route to it.
See it run
Watch it retest a finding you already know the answer to.
Reaching a client environment is the part that decides whether any of this is usable in your practice. Bring the hardest one you have, behind a VPN or a login or both, and we will show you the route in rather than describe it.