Multi-SALLM: a multilingual security assessment of generated code
As Large Language Models (LLMs) become increasingly integrated into software engineers’ daily workflows, it is critical to ensure the code they generate is not just functionally correct but also secure. While LLMs can boost developer productivity, prior empirical studies have shown that they often produce insecure code. This issue stems from two key factors. First, the datasets commonly used to evaluate LLMs don’t accurately reflect real-world software engineering tasks where security is a concern. Instead, they tend to focus on competitive programming problems or classroom-style exercises, which lack the complexity and security risks of production code integrated into larger systems. Second, current evaluation metrics mostly emphasize functional correctness and overlook security aspects altogether. To address these gaps, we introduce Multi-SALLM, a benchmarking framework designed to systematically evaluate LLMs’ ability to generate secure code. The framework includes three main components: (1) a novel dataset of security-focused Python, Java, and C++ prompts translated into 23 natural languages, (2) automated assessment techniques for analyzing generated code, and (3) new metrics that assess models from the perspective of secure code generation. Our empirical evaluation of four state-of-the-art LLMs (StarCoder2, Qwen2.5-Coder, GPT-4o-Mini, Gemini-2.5-Flash) reveals three key findings. First, functional correctness and security are closely related but not equivalent. GPT-4o-Mini achieves the highest pass@k and also exhibits high vulnerable@k, largely because it produces more compilable and analyzable outputs; in contrast, models that appear safer often do so due to lower functional yield rather than consistently secure generation. Second, programming language has a stronger impact than natural language: performance is broadly stable across the 23 natural languages and does not alter relative model rankings, whereas the target programming language introduces substantial variation, with Java consistently lagging behind Python and C++. Third, sampling strategy is a critical risk factor: increasing temperature and k increase the likelihood of obtaining a correct solution but also increase vulnerable@k and sharply reduce security@k, indicating that broader exploration systematically surfaces more insecure variants.