As a developer who has fought countless up-hill battles to fix critical security, stability, and performance issues in lieu of feature delivery, there is truth about the pressure to deliver features in lieu of security. The problem is there is often no “eye candy” for stakeholders to see when evaluating progress on getting the features they want if time is spent on the code internals fixing a security issue. Most stakeholders don’t ask for security as a feature; it usually comes as a non-functional requirement if it is even considered.
Stakeholders are often not technical enough to understand the security issue or foresee the crisis that comes with detecting and fixing an issue post-deployment. Their goal is to deliver features that work - period. Did it work in the sprint demo? Yes: check the box, ship it!
I’ve observed that in many cases the stakeholders, having a successful product delivery, are immediately promoted away from the project. When an issue is discovered, the original stakeholders that did not allow for fixes are long gone. Some of the devs usually stay around for a while; they are the ones that will be blamed when the product falls over in production or a vulnerability is discovered.
If you’ve ever noticed a mass-exodus of devs aligning with a product delivery, this could almost be a KPI of the technical problems they foresee based on what they were prevented from fixing.
I always thought a logical approach would be to base the career paths of stakeholders on several releases spanning the useful life of the software. Delivering something that worked during the sprint demos and something that can continuously provide high-value, low-risk to the business over 3 - 5 years are completely different input criteria for assessing stakeholder career advancement.