Survivorship bias is bad if you're making a statement like "All old houses were good because we still see some old houses around".
But if you already have an old house that's working it's worth considering survivorship bias if you're building a new house to replace it. That new house is much less likely to survive that bias filter. Getting the new house as good as the old house will likely take you far more time and money than you expected.
And the same is with software. For example including outside libraries in your application makes the code much easier to write. You don't have to reproduce functionality. But libraries typically work like kitchen sinks. You may not have wanted a garbage disposal, but your library came with it and for the next X years your application is around you have to make sure that disposal doesn't catch fire. From the security side you have to make sure there is no code interaction with disposal or any of the other 'household' functions its including that you're not testing for.
At least in what I do for a living which is in the field to code security reviews (I don't do these reviews myself, but I work with the teams that do), the amount of security issues that get caught in these new applications in a multi round process, at least to me is staggering. It has to be a multi round process as we see the issues being reintroduced we'd call out in previous sessions. Quite often in these larger organizations the programming teams are so unstable that between our first calls and last calls the entire team working on it will have rotated out.