Dense in Depth: Rethinking Security When Vulns Are Everywhere

The central argument is that software vulnerabilities are dense: fixing individual bugs does not meaningfully exhaust the supply of flaws, so security strategies built around finding and patching each one have limited reach. The case rests on a “removal-capture” analogy: if repeated searches of equal effort keep finding roughly the same number of vulnerabilities after earlier findings are patched, the underlying pool is large. Chrome’s public data shows a steady catch of dozens of bugs per milestone for years before AI-assisted scanning. After Google introduced AI scanning, Chrome fixed 1,072 bugs in milestones 149 and 150 - more than in the previous 23 milestones combined. Yet the weekly rate did not decline after thousands of fixes, reaching 175 in a week, and outside researchers also found more bugs. The conclusion is that even an exceptionally well-resourced security program cannot drain the pool.

The explanation is that vulnerabilities arise not simply from defective lines of code, but from runtime states, execution paths, and interactions among instructions. A Chrome exploit chain illustrates how individually correct instructions can combine into a flaw when an attacker changes shared state between them. Since possible execution orderings grow rapidly as software grows, patches remove particular cases while features can create many new opportunities for failures. The proposed shift is from searching endlessly for individual bugs to preventing whole classes of them by enforcing their underlying assumptions. Type systems, immutable objects, secure parsers, Rust’s borrow checker, and formal verification are cited as ways to make dangerous combinations impossible rather than relying on discovery and repair.