Very little --- I'll go ahead and say, to a first approximation, none --- of that safety has anything to do with software security. The same kinds of bugs that hit Java programs hit Rust programs, with maybe the sole exception of deserialization (which has nothing to do with error handling or type safety).

That matters because that's the kind of "safety" we're talking about when we discuss externalities for end-users --- not servers that need extra monitoring because they might crash.

Ignoring error codes and left-pad style issues are common sources of security issues.

Java is more left-pad resistant than Typescript, granted.

No. Rust doesn't do anything interesting to avoid supply-chain attacks.

> an ecosystem that prioritizes safety etc.

Idiomatic Rust code is just as cavalier regarding NPEs as Java or Python code. Because the language starts to look really gross when you make your code panic-safe. So you have an `expect` here, an `unwrap` there, and now you're going to have the exact same runtime issues as the more expressive managed languages. No Rust programmer thinks their `expect` will panic, just like no Java programmer expects something will be null. Rust does not force you to "exhaustively match".

expect is a lot safer than ignoring a return code.

Java and Python don't use return codes, they use exceptions. If you ignore an exception your program crashes, same as a panic in Rust.