Rust Security Posture

Rust buys a project a strong baseline against memory unsafety, but it does not make the product secure. Most real security issues in Rust applications live above the borrow checker: credentials, trust boundaries, command execution, release provenance, dependency advisories, and unbounded external input.

What Rust helps with

• Memory safety by default: no use-after-free, data races, or buffer overflows in safe Rust.
• Strong types around domain boundaries when the code chooses to model them.
• Good tooling defaults: cargo fmt, clippy, cargo audit or cargo deny, Cargo.lock, workspace lints.
• Easy explicitness: Result, typed errors, bounded wrappers, and small modules make failure paths visible.

What Rust does not solve

• A bearer token printed to stdout is still leaked.
• A config file with mode 0644 can still expose a client secret.
• A loopback OAuth listener that accepts non-loopback hosts can still cross a trust boundary.
• reqwest.bytes().await can still buffer an attacker-controlled body before validation.
• A transitive advisory still needs a fix, exception, or upstream tracking story.
• A release archive still needs provenance if users are being asked to trust it.

Rust-specific audit questions

• Is unsafe_code denied or tightly justified?
• Are external operations bounded with timeouts and size caps?
• Are blocking filesystem, keychain, and process operations isolated from hot async paths?
• Are secret-bearing types kept out of Debug, logs, snapshots, and bug reports?
• Does Cargo.lock pin the binary dependency graph?
• Does CI run cargo deny check advisories or equivalent?
• Are ignored advisories named with a reason, not hidden?

See also

• Security Audit Rubric
• Rust Project Conventions
• Idiomatic Rust Rubric