5.2.0 – 5.2.14
MinorAIPTx 5.2.x: Business Logic Testing & SAST Rules
Twenty-nine abuse patterns make business logic testing a first-class scan phase across web app flows, alongside a substantially expanded set of SAST rules, then a run of patch releases hardening that phase and the reporting behind it.
Fifteen versions were published on 12 February 2026 during release automation. The changes are listed once here rather than split across fifteen near-identical entries. Every version in the range has its own anchor, so a specific one can still be linked.
pip install aiptx==5.2.14New features7
29 business logic abuse patterns
Race conditions, IDOR, price and quantity manipulation, workflow step bypass, refund and coupon replay, and horizontal privilege drift, each modelled as an abuse case with a reproduction sequence.
Workflow state modelling
Multi-step flows are modelled as state machines so steps can be skipped, replayed or reordered under test rather than being exercised endpoint by endpoint.
90+ SAST rules across Python, JavaScript, Java and Go
Cross-file taint tracking, framework awareness for Django, Flask, FastAPI, Express and Spring, and fix guidance emitted in the target language.
Incremental SAST caching
Per-file results are cached and invalidated by content hash, bringing repeat runs over unchanged code down to seconds.
JSON report schema versioning
JSON output carries a `schemaVersion` field so downstream consumers can detect format changes instead of failing on an unexpected key.
Findings filtered by severity at output
`--min-severity` limits what reaches the report and the exit code without changing what is tested, which lets a pipeline gate on criticals while still recording everything.
Per-pattern timeouts
Each business logic pattern can be given its own timeout, so a slow race-condition probe no longer consumes the budget for the twenty-eight patterns behind it.
Improvements8
Non-destructive defaults on every logic pattern
Patterns stop at observable proof; destructive variants require explicit opt-in per target.
Evidence includes ordered request sequences
Logic findings record the request order, the timing and the state observed before and after.
Scan profiles support per-phase configuration
Rate limits, concurrency and timeouts can be set per phase instead of globally for the assessment.
Deterministic finding identifiers
Finding IDs are derived from the location and the vulnerability class rather than from scan order, so the same issue keeps its identity across runs and diffs cleanly.
Reduced log noise at default verbosity
Per-request logging moved behind `-v`; the default output is phase-level.
Lower memory use on large assessments
Evidence is streamed to disk as it is captured instead of being held for the duration of the run, which removes the memory ceiling on assessments above roughly 50,000 requests.
Clearer scan phase progress
The CLI reports the current phase, the pattern in flight and the elapsed time per phase rather than a single undifferentiated progress bar.
Faster HTML report generation
Report rendering is roughly 3x faster on assessments with more than 500 findings.
Bug fixes9
Authenticated crawl lost session on 302 to a different host
Cross-host redirects during authenticated crawls dropped the session rather than re-authenticating.
Secret detector flagged example keys in documentation
Provider format checks now verify liveness before raising a finding on strings inside documentation paths.
Duplicate findings across SAST and DAST
An injection flaw detected statically and confirmed dynamically was reported twice instead of being merged with both pieces of evidence.
HTML report broke on findings containing raw HTML evidence
Captured response bodies containing markup were not escaped in the evidence pane.
GraphQL introspection retry loop
When introspection was disabled mid-scan, the scanner retried indefinitely instead of falling back to schema inference.
Race condition results occasionally double counted
Concurrent probes that resolved at the same moment could each record the same observed state, producing two findings for one flaw.
SARIF output rejected by strict validators
The `originalUriBaseIds` block was omitted when scanning from a relative path, which some SARIF consumers treat as invalid rather than optional.
Session refresh failed on rotating refresh tokens
Long-running authenticated scans against SPAs that rotate the refresh token on every use dropped to unauthenticated partway through the run.
Exit code 0 on partial scan failure
A phase that failed after other phases had succeeded returned a success exit code, which allowed pipelines to pass on an incomplete assessment.