Shipping fast and fixing security later is often rational for the vendor, even when it is bad for customers. Anderson and Moore argue that high fixed costs, network effects and lock-in make winning the race all-important, so security loses to speed unless something changes the incentives.
The race logic
Many software markets have a dominant firm. The authors give three reasons: high fixed costs with low marginal costs, network externalities and client lock-in. When the winner takes most of the market, the first firm to reach scale gets the prize.
They quote the attitude of ship it Tuesday and get it right by version 3 as perfectly rational behavior in such markets. A firm that delays for security risks losing the race.
Complementers and compliance costs
Platform vendors must appeal to the developers who build on them. For those developers, security often gets in the way. So platforms may start with too little security, and what they provide tends to be designed so compliance costs fall on end users.
Once the platform dominates, the authors say it may add more security than needed, but engineered to maximize customer lock-in.
Even the vendor may not know
The authors point out that in some cases security is worse than a lemons market, because even the vendor does not know how secure its software is. Then buyers have no reason to pay more for protection and vendors are disinclined to invest in it. See the lemons problem in security products.
Tools are not the bottleneck
The paper observes that software writers have better tools and training than ten years earlier and can write more secure software, yet the economics of the industry give them little reason to. This is why a team can have good scanners and still ship weak releases: the incentive to act on findings is weak.
How to change the incentives inside your own team
- Make the cost visible. Track security debt and review it with product owners. See how to explain security debt to executives.
- Give security a veto in a few cases. A release gate for critical findings with a short, clear definition. See how to say no to a risky feature.
- Reward fixes, not just features. Put time to remediate on the roadmap.
- Cut the cost of doing the right thing. Automate checks in the pull request so security does not cost a meeting.
- Measure what you can. Time to fix, and the stock of known issues, beat counts of tools.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate turns a security rule into part of the normal flow, which lowers the cost of acting on it.
Quick check
Why can late security be rational for a vendor?
When winning the market race matters most, speed beats security, and customers bear the cost of later fixes.
Does better tooling alone fix the problem?
No. The authors say tools and training improved while incentives stayed weak. The incentive to act has to change.
Sources
Last reviewed: 19 October 2026.
