BaxBench: Can LLMs Generate Correct and Secure Backends?

We thank the reviewer for their insightful review and overall positive assessment of our paper. We address their questions below.

Q1: Can you discuss how SWE Lancer relates to BaxBench?

We thank the reviewer for pointing us to SWE Lancer and we will gladly add a discussion on it in the next revision of our paper. However, we would like to highlight that the first public copy of this paper has only been made available one month after the ICML submission deadline. Thus, it was impossible for us to include it in the submission.

First and foremost, the key difference between BaxBench and SWE Lancer is that BaxBench does security evaluation, an aspect that is not explicitly considered by SWE Lancer, and especially not using practical exploits.

Regarding the other differences between the papers, we largely agree with the reviewer’s analysis, except that: (i) BaxBench, like SWE Lancer, also uses end-to-end tests verified by professional software engineers for functionality testing (and not only function-level unit tests as other benchmarks), and (ii) BaxBench’s backend tasks, like SWE Lancer’s, are also highly diverse—in fact, while SWE Lancer sources all of its tasks from the Expensify repository, making all tasks correlated, BaxBench scenarios are highly diverse and constructed independently from scratch.

Finally, BaxBench is fully contamination-free, as the scenarios have been constructed manually from scratch. In contrast, SWE Lancer’s tasks stem from an existing open-source repository that could have very well been in the training data of the models.

We will include this discussion in the next revision of the paper.

We thank the reviewer for their insightful and constructive review and address their questions below.

Q1: Can you evaluate coding agents?

Upon the reviewer’s request, we tested the most advanced open-source general coding agent, OpenHands (OH) powered by GPT-4o and Claude 3.5 Sonnet.

We use our testing environments for the agent, however, we found that our Python-Django and Compiler environments are incompatible with the OH sandbox base image. Therefore, we exclude this framework and scenario. We compare the agent performance against the base models on the remaining 351 tasks:

Surprisingly, we see that the agent only provides an improvement on Claude 3.5, with GPT-4o (August’24 version) performing worse in the agent—the weaker model is overwhelmed by the agentic framework, making more functional mistakes. However, also on Claude, the improvement is not as drastic as one may expect (max 6.9%). Even the agent struggles strongly with BaxBench tasks, especially when it comes to security. We hypothesize that this is partially due to the limitations of the underlying LLMs, and the nature and complexity of the task at hand, differing from typical agent benchmarks focused on working in large pre-existing repositories (here, the agent needs to build from scratch, use different frameworks, write its own tests, etc.). This shows once again that fundamental development towards secure backend coding is needed.

We thank the reviewer for the interesting suggestion which will make a valuable addition to the next revision of the paper.

Note: We did not test on agentic IDEs such as Cursor and Windsurf as they are not suited for large-scale experiments. Further, we did not test Claude Code due to cost budget limitations. We will release the code in BaxBench for independent evaluations of Claude Code.

Q2: Please comment on the CWE coverage per scenario.

To address the reviewer’s question, we conduct a deeper investigation into CWE coverage.

First, we compare the CWEs that we test for with the CWEs reported by the SOTA SAST tool, Snyk Code, on OpenAI o1’s correct solutions. This analysis allows us to assess the comprehensiveness of our exploit attempts (i.e., the CWE coverage) per scenario. We find that for 24 of the 28 scenarios, we test for all CWEs that Snyk reports and further ones beyond. For the remaining 4 scenarios, Snyk and our tests overlap on all but one CWE. Looking at these cases, we see that this difference stems from Snyk testing for CWE-400 (uncontrolled resource consumption) where we test instead for CWE-703 (improper error handling), raised by crashing the server, which includes it crashing due to resource overconsumption. Note also that Snyk raises CWE-400 for rate limit issues, which are usually handled on an architectural level [2] and not considered relevant on the application level by us.

Beyond scenario-level exploit coverage, we also investigate how many insecure programs do we actually catch compared to Snyk. For this, we examine the Snyk reports on the 237 correct programs generated by OpenAI o1 and compare them to our exploit reports. We find that Snyk misses 64 (27%) vulnerabilities (i.e., where we could execute real exploits), while marking 25 (10.55%) programs vulnerable that were not marked by our exploits. Manually analyzing these 25 programs, we find that 16 are false positives (6.75%) and 2 concern rate limits which are architecture level concerns, i.e., amounting to 7 (2.95%) correct additional flags across 3 CWEs. Note that among these 7, we actually test for each of the raised CWEs, merely, our exploit attempts do not succeed. We will extend our exploits vectors accordingly.

Our analysis shows two things: (i) our exploit attempts are targeting a comprehensive set of CWEs per scenario; and (ii) our exploits are far more reliable than static analysis for actually detecting insecure code (Snyk 6.75% false positives and a whopping 27% false negatives).

Overall, we believe the above is strong evidence showing that BaxBench’s security coverage is both extensive and largely comprehensive. On a benchmark level, as also detailed in Table 4 in the appendix, we cover the most likely and critical security issues, based on the popular MITRE Top 25 and OWASP Top 10. Therefore, our benchmark is suited for supporting our key message of the paper—current models’ code is dangerously insecure.

References
[1] Yang et al., SecCodePLT: A Unified Platform for Evaluating the Security of Code GenAI. arXiv 2024.
[2] Serbout et al., API Rate Limit Adoption -- A pattern collection, EuroPLoP 23.

We thank the reviewer for their insightful and overall positive review, and address their questions below.

Q1: Do the scenarios provide sufficient semantic diversity?

Yes. The programs have to handle files, databases, access controls, OS commands, and external binaries (e.g., compilers, png, and pdf tools). The large spread of the models’ performances signifies this diversity, while the complexity is evidenced by the low overall correctness across all models. However, the ultimate goal of BaxBench is to measure the LLMs’ performance on security-critical backend tasks, with other functionality aspects (e.g., algorithmic complexity) already covered by existing benchmarks. Therefore, we do not claim that it covers all possible backend coding tasks, but it does cover most security-relevant tasks for web application backends. For a discussion on security coverage we refer to the reply to Q2 of reviewer WvVR.

Further, we believe that in comparison to current standard functional correctness and especially security benchmarks, BaxBench’s semantic diversity and volume is highly competitive:

• SWE-Bench and SWT-Bench [1,2] (agent-functionality) are based on only 12 Python repositories.
• SWE-Lancer [3] (functionality) is based on a single TypeScript repository.
• SafeCoder [4] (function-level, security-only) provides 42 security-only evaluation cases across 6 programming languages (avg. 7 per language).
• SVEN [5] (function-level, security-only) has 24 security-only evaluation cases across 2 languages (avg. 12 per language).
• CWEval [6] (function-level, security + correctness) contains 119 tasks across 5 languages, translating examples from 25 core tasks.

We thank the reviewer for their insightful question, and will add this discussion in the next revision.

Q2: Can you evaluate coding agents?

Upon the reviewer’s request, we tested the most advanced open-source general coding agent, OpenHands (OH) powered by GPT-4o and Claude 3.5 Sonnet.

We use our testing environments for the agent, excluding the Python-Django and Compiler environments as these are incompatible with the OH base image. We compare the agent performance against the base models on the remaining 351 tasks:

Surprisingly, we see that the agent only provides an improvement on Claude 3.5, with GPT-4o (August’24 version) performing worse in the agent—the weaker model is overwhelmed by the agentic framework, making more functional mistakes. However, also on Claude, the improvement is not as drastic as one may expect (max 6.9%). Even the agent struggles strongly with BaxBench tasks, especially when it comes to security. We hypothesize that this is partially due to the limitations of the underlying LLMs, and the nature and complexity of the task at hand, differing from typical agent benchmarks focused on working in large pre-existing repositories (here, the agent needs to build from scratch, use different frameworks, write its own tests, etc.). This shows once again that fundamental development towards secure backend coding is needed.

We thank the reviewer for the interesting suggestion which will make a valuable addition to the next revision of the paper.

Note: We did not test on agentic IDEs such as Cursor and Windsurf as they are not suited for large-scale experiments. Further, we did not test Claude Code due to cost budget limitations. We will release the code in BaxBench for independent evaluations of Claude Code.

Q3: How could models be improved on BaxBench?

Please see the answer to Q1 of reviewer p9gW for a general discussion on the errors the models make on BaxBench. To improve on these errors, we believe incorporating code security during model training is crucial. For example, during post-training, a low amount of high-quality data could be utilized to steer the base model towards secure code, similarly to [4,7]. We will discuss these learnings and future directions in the next revision of our paper.

References
[1] Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. ICLR 2024.
[2] Mündler et al., SWT-Bench: Testing and Validating Real-World Bug-Fixes with Code Agents. NeurIPS 2024.
[3] Miserendino et al., SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering?. arXiv 2025.
[4] He et al., Instruction Tuning for Secure Code Generation. ICML 2024.
[5] He & Vechev. Large language models for code: Security hardening and adversarial testing. CCS 2024.
[6] Peng et al., CWEval: Outcome-driven Evaluation on Functionality and Security of LLM Code Generation. LLM4Code@ICSE’25.
[7] Xu et al., ProSec: Fortifying Code LLMs with Proactive Security Alignment. arXiv 2025.

We thank the reviewer for their insightful review and overall positive assessment. We address their questions below.

Q1: How can models be improved on BaxBench?

To understand functionality challenges in BaxBench, we manually investigate 20 incorrect programs generated by OpenAI o1, and find that the model often fails on trivial, boiler-plate tasks, such as adhering to the requirements set in the API specification, adhering to formats and response codes, handling files, setting CLI flags, or producing compilable and executable code. The simplicity of these errors is surprising given the success of LLMs on algorithmic benchmarks. We believe this is due to the focus on algorithmic coding performance in model development and the prioritization of the most popular languages.

Further, models often produce vulnerable code. Meanwhile, when prompted with potential vulnerabilities, the model's vulnerability rates decrease, at the cost of functional correctness. Reasoning models’ correctness decreases much less. This crucial observation highlights the capacity of reasoning models to generate correct, secure code.

In terms of concrete improvements, we believe the gathered insights can be used in the post-training phase, where a low amount of high-quality data could be utilized to steer the base model towards secure code, similarly to [2,3]. The lack of such considerations has already led to commercially deployed exploitable applications [1].

Q2: Can you provide more details on the coverage and complexity of BaxBench scenarios in terms of backend tasks and security?

BaxBench contains highly diverse scenarios, requiring correct handling of files, databases, access controls, OS commands, and external binaries (e.g., png and pdf tools). Regarding complexity, we do not aim to measure algorithmic difficulty, already covered by other benchmarks (e.g., HumanEval), but rather application logic, e.g., registration and login, handling server communication, or storing of user messages in databases. The large spread of models’ correctness over scenarios highlights the variety in our tasks.

In terms of security coverage, we cover the most impactful security vulnerabilities, collected in the MITRE TOP 25 and OWASP Top 10 lists. We also achieve high security coverage on a scenario level. We verified this by comparing to the industry-leading SAST tool Snyk-Code on a model different from what we used for development. More details in Q3.

Q3: Could static analysis complement BaxBench’s exploits?

To address the reviewer’s question, we conduct an experiment comparing our exploits to the industry leading SOTA SAST tool Snyk-Code on the 237 correct programs produced by OpenAI’s o1. We find that Snyk misses 64 vulnerable programs exploited by our tests, i.e., has at least 27% false negative rate, while marking 25 (10.55%) programs vulnerable that we did not exploit. Through manual analysis we find that 16 (6.75%) of these are false positives and 2 concern rate limits which are often handled outside of the application, amounting to 7 (2.95%) correct additional flags across 3 CWEs. Note that even for these 3 CWEs, we already make exploit attempts, merely, our attack inputs do not succeed.

Due to the high amount of false negatives and false positives, we consider SAST tools unsuitable for benchmarking. However, we consider them useful for guiding exploit design and will add test cases for the 7 correctly discovered exploits.

In addition, SAST tools limit reproducible benchmarking, as the best tools keep constantly changing, are not open-source, and introduce a dependency on external tool providers.

Our manual exploits cover the most important threat vectors, and are clearly sufficient to show that current models’ code is strongly subpar—supporting our key message. Moreover, they guarantee the absence of false positives.

Q4: How resilient is this benchmark against contamination in future LLMs?

Once a benchmark is public, we believe the only guaranteed way to avoid contamination is to continuously update the benchmark. As stated in the paper, we plan to continuously add new scenarios and frameworks to BaxBench.

Note that future models are less likely to be contaminated by BaxBench: (i) our tasks are not based on existing code (unlike, e.g. SWE-bench [4]), (ii) accidental contamination is difficult as we do not release golden solutions, publishing only the execution framework and the prompts; and (iii) malicious contamination requires careful curation of such golden solutions.

We thank the reviewer for the thoughtful question, and will add a discussion in the next revision.

References
[1] https://x.com/tedx_ai/status/1901640901505827148
[2] He et al., Instruction Tuning for Secure Code Generation. ICML 2024.
[3] Xu et al., ProSec: Fortifying Code LLMs with Proactive Security Alignment. arXiv 2025. [4] Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. ICLR 2024.