Secure Software Manifesto

Public vulnerability information (e.g. CVE, disclosure info, etc.) provides data about the activities of the hacker/bugfinder/security researcher community; it tells us nothing about the absolute or relative level of vulnerability of software.
The defining aspect of a software program’s vulnerable state is the number of vulnerabilities (known or unknown) that exist in the software. It is not how hard programmers try not to program vulnerabilities nor how hard others try to find the vulnerabilities.
The contribution of a patch to the vulnerable state of a software program is a tradeoff between the specific vulnerability (or set of vulnerabilities) it fixes and the potential new vulnerabilities it introduces.
There is currently no known measurement that determines or predicts the vulnerable state of a software program. The best recent papers on this topic are: Mining Metrics to Predict Component Failures, Using Historical In-Process and Product Metrics for Early Estimation of Software Failures, and An Attack Surface Metric.
We don’t know how many "undercover" vulnerabilities are possessed and/or in use by the bad guys, therefore we must develop solutions that don’t rely on known vulnerabilities for protection.
The single best thing any developer can do today to assist in protecting a software program is to systematically, comprehensively describe how the software is intended to operate in machine (and preferably human) readable language.

Spire Security Viewpoint