SAST findings vary widely across 12 OCPP 1.6 language ports
Original title: How Well Do SAST Tools Work Across Languages? An Empirical Study Using OCPP Implementations
SonarQube, Semgrep, and language-specific analyzers reported two issues in Rust and 1,689 in Java.
Researchers compare static application security testing tools on twelve Open Charge Point Protocol 1.6 implementations for electric-vehicle charging, each written in a different language. They use SonarQube and Semgrep plus language-specific analyzers. Reported issues range from two in Rust to 1,689 in Java. The authors attribute higher counts in mature languages to more developed SAST ecosystems rather than proven differences in code quality, and say language selection should consider available tooling.
Unconfirmed: The study does not establish that higher finding counts mean lower code quality.
- The corpus contains twelve OCPP 1.6 implementations, one language each.
- Comprehensive tools are SonarQube and Semgrep, plus language-specific analyzers.
- Java yielded 1,689 findings, while Rust yielded two.
- Authors tie the disparity to tooling maturity rather than inherently worse code.
From the original article
1 min read at arxiv.orgAs electric vehicle (EV) adoption accelerates globally, securing electric vehicle charging station (EVCS) software becomes increasingly critical. The Open Charge Point Protocol (OCPP), widely adopted for EVCS management, places significant responsibility on developers to securely implement specifications that are subject to multiple interpretations.
By Zachary Wadhams · arxiv.org
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.