A legacy C application component repeatedly suffers from buffer overflow vulnerabilities due to manual pointer arithmetic and unchecked array bounds. The development team wants to eliminate this entire class of vulnerability going forward rather than continuing to patch individual instances. Which secure coding practice would most directly achieve this goal?
- ARewriting the component in a memory-safe language such as Rust
- BReplacing dynamic SQL statements with parameterized queries
- CAdding regular-expression-based input validation to all user-facing fields
- DImplementing output encoding for all rendered user input
Show answer & explanationAnswer & explanation
Correct answer: A. Rewriting the component in a memory-safe language such as Rust
Buffer overflows stem from manual memory management flaws inherent to languages like C. Rewriting in a memory-safe language (e.g., Rust, Go) enforces bounds checking and ownership rules at compile time, structurally eliminating this vulnerability class rather than just filtering symptoms. Input validation, output encoding, and parameterized queries address injection-style flaws, not memory corruption.
Why the other options are wrong
- B. Parameterized queries prevent SQL injection, not buffer overflows in native code.
- C. Input validation helps prevent injection attacks, not memory corruption from unsafe pointer arithmetic.
- D. Output encoding protects against XSS-style injection, unrelated to memory management.
Memory-Safe Languages
Programming languages (e.g., Rust, Go, Java) that enforce automatic bounds checking and memory management, structurally preventing buffer overflow and use-after-free vulnerabilities common in C/C++.
- Eliminates entire vulnerability class rather than patching instances
- Contrasts with manual memory management languages like C/C++
- Recommended by CISA/NSA for high-risk new development
Memory trick: Match the defense to the flaw: memory bugs need memory-safe languages, not filters