Technical feedback: what makes a proven exploit hard to encode deterministically?

[Pazificateur69]

I maintain ExploitSpec. I want its format decisions to be driven by confirmed security-testing workflows, not by a feature checklist.

ExploitSpec starts after a pentester or AppSec engineer has already proved a finding. The intended result is a small, reviewable invariant that fails on the vulnerable build, passes after the fix, and remains stable in CI.

The question

What part of a real, confirmed finding is hardest to translate into a deterministic regression test?

If you can share a sanitized example, this outline would be especially useful:

1. finding class, such as BOLA/IDOR, role-boundary bypass, or sensitive-property leakage;
2. actors and session setup required;
3. minimal request sequence that proves the issue;
4. dynamic values that must be captured and reused;
5. the invariant that should remain true after the fix;
6. anything the current version 1 format cannot express cleanly;
7. sources of flakiness or unsafe behavior that a runner must avoid.

Feedback that says a workflow should remain outside the core is useful too. The project deliberately avoids arbitrary scripting, browser automation, autonomous exploitation, and testing targets without authorization.

Please do not post credentials, customer data, private endpoints, unsanitized responses, or an undisclosed vulnerability. Synthetic request/response fragments and descriptions of already-remediated findings are enough.

I will turn recurring, well-bounded patterns into specific design issues or cookbook examples, with attribution when a contributor wants it.