My comment was more in the vein of every security bug that gets reported is followed with comments along the lines of "don't they fuzz their software", or languages like Zig that aren't memory safe but claim "debug allocators" and "support for fuzzing" obviate the need for memory safety.
A memory safe language does not need fuzzing to try and prevent memory safety errors from causing security vulnerabilities, as definitionally such errors are not exploitable. Obviously fuzzing is still valuable in such an environment because crashing at runtime is a bad user experience, but it's still superior to "trampling through memory with wanton freedom and continuing to do whatever attackers want".
That’s a dangerous line of thinking: memory safe languages can and do have memory safety bugs. There are many causes for this, from incorrect compilation (as seen here IIUC), bugs in the language runtime, concurrency problems, to unsafe language features. That doesn’t mean that there is no value in memory safe languages, they are a definite improvement. But, they are not the solution to all problems around memory safety. For example, even in Rust, which provides some of the strongest memory safely guarantees, there are memory safety issues discovered in the standard library.
A memory safe language does not need fuzzing to try and prevent memory safety errors from causing security vulnerabilities, as definitionally such errors are not exploitable. Obviously fuzzing is still valuable in such an environment because crashing at runtime is a bad user experience, but it's still superior to "trampling through memory with wanton freedom and continuing to do whatever attackers want".