When the fix lives in another language
In a compound chain, the safe version and the vulnerable version are identical at the sink. The only difference is a control several files and one language upstream. That is the case you cannot pattern-match, and the reason a new browser tier of cases calls no sanitizer at all.
The oldest way to beat a benchmark is to read the answer off the page. BenchProctor already closed the obvious routes: no comments, no CWE tags, no category names, nothing in a file name or an identifier that reveals the label. The compound chain closes the last one. Even the code cannot give away the answer, because at the place a scanner is looking, the vulnerable version and the safe version are the same bytes.
The fix is not where the danger is
In a compound chain, the vulnerable app and its safe twin differ only by a control that lives in a different file, and usually a different language, than the sink. The dangerous call is identical in both. So a tool that decides safety by reading the sink gets no signal at all, because the sink is not where safety was decided.
The only way to tell the two apart is to follow the path back across the service boundaries and check whether the upstream gate actually holds. The safe twin is not a case with the weakness removed. Every planted weakness is still there, still individually reportable. One control on the path holds in the safe version and is missing or broken in the vulnerable one, several hops and one language away from the code that fires.
That is why you cannot beat it by learning what a vulnerable sink looks like. There is no vulnerable shape at the sink to memorize, because at the sink the vulnerable and safe versions are identical. The difference is a fact about the path, not a fact about the sink.
The browser is an execution context of its own
The same discipline drives the newest coverage on the JavaScript and TypeScript side: the browser
itself, as a place code runs. BenchProctor now models React, Vue, and Svelte front ends, with
client-side sources that never touch a request object at all: a URL parameter, a URL fragment, a
postMessage payload, a component prop. The DOM sinks are split by output context, because the
defenses are not interchangeable. Writing untrusted text as HTML is one weakness (CWE-79). Injecting
it into a URI attribute can be another (CWE-83): HTML escaping alone does not make an
attacker-controlled javascript: URI safe.
The hardest case in this tier is a safe one that calls no sanitizer at all. {value} in React, or
{{ value }} in Vue, is safe because the framework escapes on interpolation. Its vulnerable twin
differs only by reaching for the documented escape hatch: dangerouslySetInnerHTML, v-html,
{@html}. A tool whose rule is “I saw a scrub call, it is safe,” or the reverse, “I saw no scrub
call, it is vulnerable,” gets both halves wrong. Only a tool that knows what the framework does on
its own gets them right. It is the same trap as a broken
sanitizer, moved into the frontend.
One tier harder, same honesty
None of this relaxes the rules that make the score trustworthy. The classes stay balanced, and because the score subtracts the false-positive rate from the true-positive rate, flagging everything still nets zero. The answer key still lives outside the code the scanner reads. The chain category is built and scoring in validation, and it joins the public release when its labels clear the same bar the standalone languages did.
When it does, it is the hardest, most realistic test in the corpus, and it is the one every SARIF-emitting scanner the stack relies on, TheAuditor first, will be held to. See the category and how it is scored.