Results indicate that Rust's compile-time guarantees dominate at the systems layer, while managed backend frameworks offer stronger built-in defenses at the application layer, suggesting that Rust adoption in web contexts requires complementary safeguards rather than reliance on language-level safety alone.
Abstract
The Rust programming language is widely credited with eliminating entire classes of memory-safety and concurrency vulnerabilities, but the security implications of adopting it in practice extend well beyond memory safety. This paper presents a critical review of prior work on Rust's security posture in industrial settings, and extends that analysis in a direction the original study did not cover: backend web development. We first assess the strengths and limitations of the existing vulnerability classification of Rust against C, C++, and Java under the SANS Top 25, OWASP Top 10, and the 19 Deadly Sins of Software Security frameworks, identifying gaps including limited empirical validation, a small interview sample, and the absence of a secure development lifecycle discussion. We then contribute an original comparison of Rust against Node.js and Django using the same three-level classification (Rare and Difficult, Safeguarded, Unprotected), supported by side-by-side code experiments for out-of-bounds writes (CWE-787), use-after-free (CWE-416), and race conditions (CWE-362). Our results indicate that Rust's compile-time guarantees dominate at the systems layer, while managed backend frameworks offer stronger built-in defenses at the application layer, suggesting that Rust adoption in web contexts requires complementary safeguards rather than reliance on language-level safety alone.
Differential fuzzing reveals complementary bugs in the manual and LLM porting of security-critical C libraries to idiomatic Rust and translates these findings into concrete practical guidance for teams planning a similar migration.
Marco Parrillo, Marco Grassi, Luigi Laura· Future Internet· 0 citations
This paper investigates how programming language standards influence memory safety by analyzing three distinct approaches: the manual memory management of C++, the ownership-based compile-time model of Rust, and the automatic garbage collection of Python.
Gordon Bednarz, Ludvig Kåhlin, Oliver Andersson· 0 citations
RTL-Obliger is presented, a neuro-symbolic framework that infers implicit security obligations of register-transfer-level RTL in a functionality-preserving two-stage generation and raises mean all-pass rates.
Guang Yang, Xing Hu, Xiang Chen et al.· 0 citations
An empirical benchmark evaluating whether LLMs and SLMs can generate security-compliant AWS Terraform configurations suggests that prompt design is a critical factor, highlighting the need for a proper pipeline for developing and validating LLM-assisted secure IaC generation.
Francis Luis Santos Vargas, R. Mansilha, Diego Kreutz· Anais do I Simpósio de Infra...· 0 citations
It is proved that current AI coding assistants do not produce secure-by-default applications, dictating that enterprise deployments must transition from single-shot prompt engineering to continuous, standards-driven verification pipelines.
Large language models (LLMs) increasingly repair software vulnerabilities, but most evaluations judge only similarity to a developer fix or removal of the weakness. Neither reveals whether working code was broken. We evaluate eight commercial and open LLMs on 922 JavaScript vulnerability patches, scoring neutralisation and functional preservation. Lacking tests, we score at scale with a reference-based LLM judge, calibrated against execution on a 144-patch benchmark and 254 Java-CVE patches, plus a cross-family judge. The best model fixes 23% of vulnerabilities (judge-based), and cost-efficiency inverts the accuracy ranking. Our central finding concerns the instrument: both judges flag more over-fixes than execution confirms (precision 5–10%), yet on the functional axis agree far more with each other (κ=0.75) than with execution (κ≤0.26), so judge–judge agreement measures reliability, not validity. On real Java code the over-reporting persists, while the judges’ correctness estimates diverge, leaving no single judge trustworthy. Over-fixing is genuine but, under execution, uncommon: a few percent of vulnerability-removing patches, or under 2%, excluding one artefact-prone scenario, both lower bounds. Only adequately tested execution measures the functional-preservation rate, so security-patch evaluation must run the code, use a judge only to rank models, and weigh costs. We release the harness and executable benchmark.
Patrick Deininger, Wolfgang Slany· Journal of Cybersecurity and...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.