Write new code in a memory-safe language

How to do it

Seven of the 25 weaknesses in the 2025 CWE Top 25 are memory errors, such as out-of-bounds writes and use after free. Safe code in these languages cannot make them. For existing C or C++ code, write a roadmap that replaces the parts handling outside input first. Keep escape hatches, such as Rust unsafe or Go's unsafe package, in one reviewed module. Fuzz any parser that stays in C or C++, as Fuzz every parser of untrusted input says.

Examples

Plain text example

// Rust: no unsafe code anywhere in this crate
#![forbid(unsafe_code)]

// A short packet returns an error instead of reading past the end
fn read_length(packet: &[u8]) -> Result<u16, ParseError> {
    let bytes = packet.get(0..2).ok_or(ParseError::TooShort)?;
    Ok(u16::from_be_bytes([bytes[0], bytes[1]]))
}

Go example

// Go: a short packet returns an error instead of reading past the end
func readLength(packet []byte) (uint16, error) {
	if len(packet) < 2 {
		return 0, ErrTooShort
	}
	return binary.BigEndian.Uint16(packet[:2]), nil
}

Shell example

# Fail when a change adds C or C++ files that are not on the allow list
added=$(git diff --name-only --diff-filter=A origin/main...HEAD | grep -E '\.(c|cc|cpp|h)$' | grep -vxFf native-allowlist.txt)
[ -z "$added" ] || { echo "FAIL: new C or C++ files: $added"; exit 1; }

How to check

A build step fails when a change adds a .c, .cc, .cpp or .h file outside an allow list. Each allow list entry links its decision record. Every Rust crate sets #![forbid(unsafe_code)] unless it is on the list. A grep fails import "unsafe" in Go outside the list.

Sources

• CISA and NSA: Memory Safe Languages
• CISA Product Security Bad Practices
• CWE Top 25 of 2025

Related rules

• TST-39 Fuzz every parser of untrusted input in Testing