Imagine you're training a new developer by having them shadow a colleague. If you seat them next to the engineer who always writes auth checks, they learn to write auth checks. Seat them next to the one who skips input validation, and they learn to skip it too. LLM code assistants work exactly the same way — except nobody is thinking about which colleague the model is shadowing. This paper builds the first rigorous test of that problem. The committed claim: repository context construction — the step where an LLM coding tool gathers surrounding code before generating new code — is optimized purely for functional correctness and is essentially blind to security. CASE-Bench, the benchmark the authors build, contains 145 tasks drawn from real CVEs across 51 open-source projects, each running in Docker with functional tests AND a working proof-of-concept exploit validated in both the vulnerable and patched directions. This is not a toy setup. Each task is annotated with exactly which lines of existing repository code enforce or undermine the security property, creating ground truth for measuring what context does to secure output. The ladder is what makes this paper bite. Across 13 context construction methods and 6 LLMs, functionality-oriented context raises functional pass rates by up to 8.2 percentage points — but secure pass rates by at most 3.7 pp. That's less than half the functional lift. Worse, the sensitivity analysis is brutal: withholding a single safeguard element from context drops the secure pass rate by up to 8.1 pp, while inserting just one insecure code exemplar raises the rate of functionally-correct-but-exploitable output by 6.3 pp. The asymmetry is the finding — insecure context poisons harder than secure context heals. The architecture analysis sits at the intersection of retrieval-augmented generation (RAG), static analysis, and agentic tool use. The 13 methods tested span the landscape from naive file-level inclusion to dependency-aware retrieval to full coding agents (which can browse repos themselves). The agents — the most sophisticated pipeline — observe the relevant safeguard in only 27–36% of their trajectories. This means even when the safeguard EXISTS in the repo, the agent's exploration strategy misses it two-thirds of the time. The context window isn't the bottleneck; the retrieval strategy is. Integrity is strong for this genre. Every task is rooted in a real CVE, not a synthetic vulnerability. The Docker-based execution with bidirectional exploit validation (confirming the exploit works on vulnerable code AND fails on patched code) is a higher bar than most secure-code benchmarks clear. The 145 tasks across 51 projects give reasonable diversity. The main integrity concern is that 145 tasks, while carefully constructed, may not represent the full distribution of security-relevant context patterns. The authors acknowledge this. The milestone question is concrete: current context methods surface security-relevant code in roughly a third of cases. The unlock isn't a qubit count — it's a retrieval recall number. If security-aware context construction can push safeguard visibility from ~30% to ~80%, the 8.1 pp penalty from missing safeguards largely disappears. That's the number to track. The gap is algorithmic, not hardware — meaning it's solvable in the near term if the retrieval community takes it seriously. The obvious successor experiment the authors didn't run: a security-aware context construction method that explicitly retrieves safeguard code. They diagnose the disease thoroughly but don't test a cure. Honest read: this is a deliberate scope choice — the benchmark paper and the method paper are being separated, likely for the next submission. The benchmark alone is a contribution worth publishing.
