There is a very important concept in security engineering around feedback loops. Consider the following: A vulnerability is discovered 5 years after it was introduced. The issue is patched and life goes on for the engineering organization that discovered it. Some time passes and they discover an architectural flaw and that the issue was not isolated. They must now expend precious effort fixing this entire flaw and the 5 years of dependencies that accreted on it. Now, consider, the team that designed this system and the engineer that implemented it discover the vulnerability leading to the architectural issue within two weeks. They refactor the code and eliminated generational security debt. Not to mention the engineers that wrote the code are not around 5 years later further increasing the "interest" on the debt.

I would note you might see this as another bland "shift left" argument and you could definitely view if through this lens. But if you consider it from a systems thinking lens it actually incorporates dynamics that are not typically included in shift left. It helps you consider the system within your organization and how to shorten those feedback loops. It also, conveniently, makes engineering organizations stronger as a whole as these feedback loops are also intrinsically linked to the organizations software development process as a whole. It is pretty hard to have a tight security vulnerability discovery loop without a good software engineering practice around it. For security issues like this they are effectively a strict subset of software quality issues.

You can apply this feedback loop shortening to /so/ many things in life.