This bug was undeniably major and i highly doubt a standard test would have found this.
What would such a test look like, "test that no file in /tmp was touched"? That can only be done after you know such issue might exist, which is great to prevent regressions, but doesn't help to stop new unknown bugs. What else are you going to test for, no files in /foo were touched, no files in /bar and so on to infinity? "No files at all were touched", sure could be reasonable, but again keeps growing to an infinite set of "X must not happen", including other forms of IO like connections and API calls. Most security issues have this property, you can't test if a system is free of injection vulnerabilities, without exhausting every possible input combination or using advanced fuzzing techniques.
If we all lived in a fairy tale, sure, sandboxes are preferable. In this case to avoid the bug, every ssh server in the world would need a per-user tmpfs. Ideally, that would indeed be neat, short term it's not realistic. For the iterm2 case of a ssh client, an admin may also need to inspect the actual /tmp when debugging the server and then need to bypass the sandbox. A sandbox will never have the perfect granularity for every scenario. So we can't just throw our hands in the air and say "not my problem", alternative forms of verification are needed.
Besides, how do you test or review your sandbox and its configuration? Both are still needed.
Incidentally, k8s works a bit like this with no default shared tmpfs across containers. So such large scale production deployments are more protected against this type of issue. On the other hand, for debugging, as you would with ssh, it hardly has a concept of users at all, and lots of other ways to shoot yourself in the foot with :)
This bug was undeniably major and i highly doubt a standard test would have found this.
What would such a test look like, "test that no file in /tmp was touched"? That can only be done after you know such issue might exist, which is great to prevent regressions, but doesn't help to stop new unknown bugs. What else are you going to test for, no files in /foo were touched, no files in /bar and so on to infinity? "No files at all were touched", sure could be reasonable, but again keeps growing to an infinite set of "X must not happen", including other forms of IO like connections and API calls. Most security issues have this property, you can't test if a system is free of injection vulnerabilities, without exhausting every possible input combination or using advanced fuzzing techniques.