Michael Janke at Last In, First Out is rightly concerned about the respective run rates of the vulnerability creation process and our ability to fix them individually. He asks the question “Are we creating new vulnerabilities faster than we are fixing old ones?” after providing a list of publicly disclosed vulnerabilities from various time periods.
I am not clear whether this list of disclosed vulnerabilities is intended to represent vulnerabilities created or fixed (it is neither), but it certainly does its job in highlighting the problem. It is worth first understanding that vulnerabilities can exist in various states after creation – undiscovered/discovered; undisclosed/disclosed (publicly); and unfixed/fixed, giving us 8 different possible state combinations (though 2 are impossible) for vulnerabilities:
undiscovered, undisclosed, unfixed (latent)
undiscovered, undisclosed, fixed (due to code upgrade, for example)
undiscovered, disclosed, unfixed (impossible)
undiscovered, disclosed, fixed (impossible)
discovered, undisclosed, unfixed (true zero day; undercover vulnerability)
discovered, undisclosed, fixed (QA and internal code review teams)
discovered, disclosed, unfixed (common zero day)
discovered, disclosed, fixed (standard)
It may also be worth differentiating between a patch available state and a patch applied state depending on whether you are a vendor or an end-user, but this will suffice for now.
Back to Michael’s question, ”
Are we creating new vulnerabilities faster than we are fixing old ones?” The answer is simple: Yes. The evidence is not so readily available, but logically intuitive, I believe. The thought exercise involves considering the amount of new code being created every day and determining how many vulnerabilities you think are being created. So, for example, you might determine that there are 50 million lines of code and 5 thousand vulnerabilities created every day like I did here. You can then compare that number to the number we are “fixing” – using either the number being disclosed, like Michael does, or perhaps an estimate that incorporates the percentage of unpatched vulns in the world.Michael asks a great question and I think he and I come to similar conclusions, but we differ significantly in our reactions to this information. He believes activism and (presumably) regulations will solve the problem. In confess that I
really despise the use of automobiles as some sort of analogous situation, primarily because we are talking more about atoms and molecules than we are about physical components to a car. And even more importantly, automobile safety (at least the kind in this context) does not revolve around the INTELLIGENT ADVERSARY.
Michael is correct that we can’t eliminate all vulnerabilities but
liability is not the answer. Software Safety Data Sheets coupled with continued action against attackers will do a much better job.
Related:
