v0.188.0

• Who controls the input. Haskell taint findings now carry a trustBoundary verdict. Flows whose only origin is the operator's own command line, environment or configuration, and thin process wrappers, are lowered to info (original severity kept), never dropped. Origins are now tracked through derivations, calls and returns. Unreachable-looking functions caused by ambiguous platform imports, Haskell pragmas read as JSON policy, JavaScript-syntax patterns firing on Haskell text, and comments leaking into finding snippets (and so into stable ids) were fixed. unsafe* boundary notes report as informational.
• Remediation. New takeFileName rewrite for path traversal; the SQL rewrite uses the driver the file already imports (PostgreSQL or SQLite) and refuses others. SSRF, argument injection, password hashing, predictable randomness, cookie attributes, missing auth, resource limits, TLS validation and hard-coded secrets refuse with a class-level reason. The process and path rewrites were type-checked with GHC; the SQL, HTML and hash patches were checked only against stubs of the documented API.
• New guard. A comment-invariance test scans the Haskell cases as written, with comments blanked, and with lying comments in both directions, and requires identical findings.
• Measured, and mostly not generalising. On a new 118-site development sample from eight real projects (one labeler who read every site), precision went from 4.2% to 35.7% (5 of 14 still flagged); the verification half is 1 of 4, so those counts are tiny. On six fresh projects scanned once, precision was 9.5% before and 10.6% after the first fix round, and 37.8% after follow-up fixes that the set itself motivated, so that figure is not independent. On the sealed independent Haskell set (four projects), precision is 2.9% (1 of 35 decided sites, 95% interval 0.5% to 14.5%), against 2.3% before: essentially unchanged. On unseen-v4, SAST recall is unchanged at 54.2% and taint recall fell from 73.3% to 66.7% (one case). The gains are on code the work was developed against, not on sealed code.
• Recall cost on a fresh set. Four true-positive sites in IHP's own development IDE (a command injection from an HTTP path and two request-indexed list lookups) are no longer found when scanning IHP itself; IHP request sources were added so the same flaw is found in IHP-style apps.
• Real vulnerabilities found in the development sets: weak password hashing and a predictable session id in gitit, a predictable digest nonce in hackage-server, disabled TLS verification and unbounded request bodies in IHP, an unvalidated path-traversal read in dhall's test server, reflected XSS and an open redirect in Scotty examples. None has a verified fix: all refuse honestly.