Rust Security in Production on Atharva Pandey

Lesson 8: Security Fuzzing — Finding vulnerabilities before attackers do

Sun, 18 May 2025 13:29:00 +0000

I found a panic in a production parser by accident last year. A user in Japan sent a request with a multi-byte UTF-8 character right at a boundary where our code was slicing a string by byte index. It worked fine for ASCII. It worked fine for most Unicode. But this particular combination of character and position triggered an index-out-of-bounds panic that crashed the request handler.

I fixed the bug in ten minutes. What bothered me was that we’d had unit tests, integration tests, and even some property-based tests — and none of them caught it. The input space was too large. The edge case was too specific. A human writing test cases would never think to put a 3-byte UTF-8 character at exactly that offset.

Lesson 7: Sandboxing and Privilege Dropping — Least privilege

Thu, 15 May 2025 07:41:00 +0000

Here’s a pattern I’ve seen too many times: a Rust web service runs as root in a Docker container because “it needs to bind port 443.” The service handles user uploads, parses JSON, processes images, and talks to a database — all with root privileges. If any part of that pipeline has a vulnerability, the attacker gets root on the container. And if the container isn’t properly isolated, they might get the host too.

Lesson 6: Supply Chain Security — Lockfiles, vendoring, and trust

Mon, 12 May 2025 10:08:00 +0000

The xz backdoor was a wake-up call for the entire industry, but honestly, supply chain attacks had been happening for years before that — just more quietly. Typosquatting on npm, malicious PyPI packages, compromised maintainer accounts. The question isn’t whether Rust’s ecosystem is vulnerable to supply chain attacks. It is. The question is what you’re doing about it.

I spent a week last year hardening our build pipeline after we realized that a cargo build on our CI server was pulling fresh crate downloads from the internet with no verification beyond what Cargo does by default. If crates.io got compromised, or if our DNS got hijacked, we’d be compiling and shipping attacker code with zero friction.

Lesson 5: Dependency Auditing — cargo-audit and cargo-deny

Fri, 09 May 2025 14:55:00 +0000

You know what keeps me up at night? Not my own code — I can review that. It’s the 200+ transitive dependencies in my Cargo.lock that I’ve never read a single line of. Every one of those crates runs with the same permissions as my code. If any of them has a vulnerability, it’s my vulnerability.

This isn’t theoretical. In 2024, the xz backdoor showed that even core infrastructure maintained by a single person can be compromised. Rust’s ecosystem isn’t immune. We’ve had actual advisories for real crates — buffer overflows in parsing libraries, unsound unsafe code in popular crates, logic bugs in crypto implementations.

Lesson 4: Secret Management — zeroize and secure memory

Wed, 07 May 2025 08:23:00 +0000

A while back I was debugging a crash in production and pulled a core dump from the server. Sitting right there in the heap, in plain text, was a database connection string with credentials. The service had loaded the secret from Vault on startup, stored it in a regular String, and that String stayed in memory for the entire process lifetime. When it crashed, the secret got written to disk in the core dump.

Lesson 3: Cryptography — ring, RustCrypto, and sodiumoxide

Mon, 05 May 2025 11:47:00 +0000

I’m going to say something controversial: most developers should never write cryptographic code. Not because they’re not smart enough — because the field is absurdly hostile to even tiny mistakes. A single branch in your constant-time comparison function leaks timing information. A reused nonce in AES-GCM completely destroys confidentiality. An ECDSA implementation with a biased random number generator leaks your private key after enough signatures.

But you still need to use cryptography. Every production system needs hashing, encryption, signatures, or key derivation at some point. The trick is picking the right library, using it correctly, and understanding just enough of the theory to avoid the common footguns.

Lesson 2: Input Validation and Sanitization — Trust nothing

Sat, 03 May 2025 16:12:00 +0000

A few months ago, I was reviewing a PR where someone had written a REST API handler that took a user-supplied filename, appended it to a base path, and opened the file. The code compiled perfectly. Clippy was happy. Tests passed. And it was a textbook path traversal vulnerability — ../../etc/passwd would work just fine.

Rust’s type system protects you from memory corruption. It doesn’t protect you from trusting user input. That’s still on you. And honestly? It’s where most production vulnerabilities in Rust code are going to come from.

Lesson 1: Memory Safety — What Rust gives you for free

Thu, 01 May 2025 09:34:00 +0000

Last year I inherited a C++ service that had been “battle-tested” in production for three years. Within a week of digging through crash dumps, I found two use-after-free bugs, a buffer overread that leaked heap data into API responses, and a data race in the connection pool that only triggered under load. Three years. Battle-tested. Right.

That experience is what finally pushed me from “Rust is interesting” to “Rust is non-negotiable for anything touching the network.” The memory safety guarantees aren’t just a nice-to-have — they’re the single biggest security win you get by choosing Rust.