Reachability
Does the model correctly distinguish reachable from unreachable vulnerable code paths?
Measures AI models on remediating vulnerable open-source dependencies — choosing safe upgrade paths, evaluating breaking changes, and validating reachability.
Each model response is judged on these dimensions by an LLM-as-Judge calibrated against expert annotations.
Does the model correctly distinguish reachable from unreachable vulnerable code paths?
Does the suggested version avoid known regressions or breaking changes?
Does the model account for downstream dependencies affected by the upgrade?
Does the model verify license compatibility of the upgrade target?
Is the resulting lockfile and manifest change minimal and reviewable?
An illustrative case to show how the model is presented with a problem and how its response is scored.
log4j-core 2.14.1 transitive dependency with CVE-2021-44228; called via spring-boot-starter-logging.
Recommend an upgrade path or compensating control. Show the manifest changes and explain reachability.
Upgrade log4j-core to 2.17.1 via dependencyManagement override. Confirm spring-boot-starter-logging compatibility. Note that JNDI lookup is reachable based on configured appenders.
Models that recommend major-version jumps without justifying breaking-change handling are penalized.
All Remediation Labs benchmarks evolve through three versions, increasing in difficulty and realism.
Models are given the raw security finding and asked to recommend a remediation. No environment context provided.
Models receive the finding plus relevant system, code, and policy context. Evaluated on contextual reasoning quality.
Models must produce a remediation that can be safely executed end-to-end — code patches, IaC changes, runbook steps — with verification.
Get model leaderboards, scoring methodology, dataset details, and roadmap access — or discuss generating proprietary remediation datasets for your environment.
Or email us directly at info@remediationlabs.com