I must disagree. a vulnerability where a threat actor has no way of exploiting it in the real world is not a security issue. On the flip side, a software that magically lacks any vulnerability in its code can still have design issues like bad UX or easy to misconfigure (is it elastic's fault when people expose their elastic db to the internet for example).
In the software dev world, there is this view that security is absolute. in reality, it is very much relative to the data and real-world threat. Since software devs aren't expected to know details about current threats, they're expected to think in terms of absolute and hypothetical scenarios. Which is great for writing software,but when evaluating or discussing security (software or otherwise), it's not about how many vulnerabilities there are, it is about data vs threat actors and how that risk impacts you.
But if we built a culture and practice that low-security code is low-quality code, and made security issues a software defect like any other, it would get handled. Plenty of developers (and leads, and PMs) are fine with shipping low-security code, but would fight to the death if accused of shipping low-quality code.
[0] https://blog.invisiblethings.org/2008/09/02/three-approaches...