(a) Vulnerability is what happens to you while you are busy making other plans
About the lifetime of vulnerabilities in software development projects
Writing perfectly functional software free of bugs and vulnerabilities is the forbidden dream of every developer...
Just as having the certainty of identifying all possible security issues is probably the dream of every #pentester...
However, and it's not news, vulnerabilities exist in real-world software...
But what is surprising is how long they seem to persist (that's the real news)...
Context (for those less familiar with security topics):
- For non-experts, vulnerabilities refer to weaknesses in software that were evidently not anticipated by its creators. Depending on the case, these weaknesses could allow for misuse of the system by malicious users (the infamous hacker)...
- To prevent this circumstance, it is (or would be?) good practice during software development activities to implement a series of practices aimed at preventing the presence of vulnerabilities in the software...
Findings:
Despite all this, a recent study shows that the average lifespan of a vulnerability within a software project is, drum roll, approximately 1780 days.
In other words, nearly five years :-D
The data is interesting in itself because:
- From the perspective of the exposure window (i.e., the time an attacker has to discover and exploit a vulnerability), five years is evidently an enormous amount of time.
- The projects on which the study was based are not at all secondary projects: Firefox, Chromium, Linux (kernel), PostgreSQL, and OpenSSL, just to name a few that are easily recognizable even to a non-specialized audience.
Concerns:
Nevertheless, the data should be taken with a grain of salt:
- It is not easy to determine the exact moment when a vulnerability was introduced into the code. The authors provide an estimate, albeit a reasonable one.
- The number of projects examined is limited, although they are representative.
- Some projects, although the authors believe they don't have this effect, are OpenSource projects that have made history on the Internet. The overall data may be penalized by these projects, unlike others that are more recent (such as Firefox and Chromium), which seem to fare better (with timescales of a couple of years, at least).
For those interested in delving deeper:
- Here is the link to the paper and slides directly from the USENIX '22 website: https://www.usenix.org/conference/usenixsecurity22/presentation/alexopoulos
- Here is the direct link to the presentation on YouTube:
- An article from a few years ago, but still relevant, by Brian Krebs on criteria for evaluating software security: https://krebsonsecurity.com/2010/11/why-counting-flaws-is-flawed/