3 ms·

> The answer lies in an important observation: vulnerabilities decay exponentially. They have a half-life. [...] A large-scale study of vulnerability lifetimes2

> The answer lies in an important observation: vulnerabilities decay exponentially. They have a half-life. [...] A large-scale study of vulnerability lifetimes2 published in 2022 in Usenix Security confirmed this phenomenon. Researchers found that the vast majority of vulnerabilities reside in new or recently modified code. It stands to reason, then, that it would be even better for security to stop adding new features when they aren't absolutely necessary. Windows LTSC is presumably the most secure version of Windows.

wepple 2y ago
Or an alternative approach: only compile the subset of features you explicitly need. Obviously there’s a ton of variance in how practical this is any place, but it’s less common than it should be.
- sieabahlpark 2y ago
  Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Congrats you're back to square 1!
  - wolrah 2y ago
    > Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Yeah, but are those bugs security bugs? Memory safety bugs are a big focus because they're the most common kind of bugs that can be exploited in a meaningful way. Disabling entire segments of code is unlikely to introduce new memory safety bugs. It's certainly likely to find race conditions, and those can sometimes lead to security bugs, but its not nearly as likely as with memory safety bugs.
    - ReleaseCandidat 2y ago
      > Yeah, but are those bugs security bugs? If the software is unusable, it doesn't matter if it has security bugs too. Or, to rephrase, the safest software is software nobody uses.
- adgjlsfhk1 2y ago
  This can be a really bad idea since it drastically increases the risk of users running a compiled combination of features that was never tested.
- pjc50 2y ago
  This is usually absolutely horrendous to do, and of course exponentially increases your test workload for every possible combination of feature flags. If you're doing it by #ifdef it has the added effect of making code unreadable. Only really practical if "features" are "plugins".
  - pfdietz 2y ago
    Or it's a really great idea, since you now can produce a diversity of software products, all of which should be correct on a subset of features, and all of which can be tested independently. Perhaps bugs can be flushed out that would be latent and undetectable in your standard build. Having lots of knobs you can tweak is great for randomized testing. The more the merrier.
Ygg2 2y ago
> that it would be even better for security to stop adding new features when they aren't absolutely necessary Even if features aren't necessary to sell your software, new hardware and better security algorithms or full on deprecation of existing algos will still happen. Which will introduce new code.
Animats 2y ago
Individual bugs triggered in normal operation ought to decay over time on software that is maintained. If bugs cause problems, someone may report them and some fraction of them will be fixed. That's a decay mechanism. Not-yet exploited vulnerabilities, though, don't have that decay mechanism. They don't generate user unhappiness and bug reports. They just sit there, until an enemy with sufficient resources and motivation finds and exploits them. There are more enemies in that league than there used to be.
- elcritch 2y ago
  Your assertions contradict the Usenix research cited in TFA, which found that the lifetime of vulnerabilities _do_ follow an exponential decay. If it takes longer to find a vulnerability, then its lifetime is longer.
  - Animats 2y ago
    What the article calls a "vunerability" is something they found internally. Looking at vulnerabilities that were found from attacks, it looks different. [1] Most vulnerabilities are fixed in the first weeks or months. But ones that aren't fixed within a year hang on for a long time. About 18% of reported vulnerabilities are never fixed. [1] https://www.tenable.com/blog/what-is-the-lifespan-of-a-vulnerability https://www.tenable.com/blog/what-is-the-lifespan-of-a-vulne...
    - fanf2 2y ago
      I think that’s about time to deploy fixed code, not about time to discover the vulnerability nor about time to fix the code.
- UncleMeat 2y ago
  Vulns aren't just vulns. "Hey, in some weird circumstances we see a uaf here and the system crashes" is the sort of thing you might see in an extremely ordinary crash report while also having significant security implications. You can also uncover latent vulns over time through fuzzing or by adding new code that suddenly exercises new paths that were previously ill-tested. Yes, there are some vulns that truly will never get exercised by ordinary interaction and won't become naturally visible over time. But plenty do get uncovered in this manner.
pfdietz 2y ago
> vulnerabilities decay exponentially This should be true not just of vulnerabilities, but bugs of any kind. I certainly see this in testing of the free software project I'm involved with (SBCL). New bugs tend to be in parts that have been recently changed. I'm sure you all have seen the same sort of effect. (This is not to say all bugs are in recent code. We've all seen bugs that persist undetected for years. The question for those should be how did testing miss them.) So this suggests testing should be focused on recently changed code. In particular, mutation testing can be highly focused on such code, or on code closely coupled with the changed code. This would greatly reduce the overhead of applying this testing. Google has had a system where mutation testing has been used with code reviews that does just this.
theptip 2y ago
This is why I advise most folks to not take the latest point release of your language or libraries. The bleeding edge is where many of the new vulns are. In general the oldest supported release is usually the safest. The trade-off is when newer versions have features which will add value, of course. But usually a bad idea to take any version that ends “.0” IMO.

wepple 2y ago

Or an alternative approach: only compile the subset of features you explicitly need. Obviously there’s a ton of variance in how practical this is any place, but it’s less common than it should be.

sieabahlpark 2y ago
Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Congrats you're back to square 1!
- wolrah 2y ago
  > Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Yeah, but are those bugs security bugs? Memory safety bugs are a big focus because they're the most common kind of bugs that can be exploited in a meaningful way. Disabling entire segments of code is unlikely to introduce new memory safety bugs. It's certainly likely to find race conditions, and those can sometimes lead to security bugs, but its not nearly as likely as with memory safety bugs.
  - ReleaseCandidat 2y ago
    > Yeah, but are those bugs security bugs? If the software is unusable, it doesn't matter if it has security bugs too. Or, to rephrase, the safest software is software nobody uses.
adgjlsfhk1 2y ago
This can be a really bad idea since it drastically increases the risk of users running a compiled combination of features that was never tested.
pjc50 2y ago
This is usually absolutely horrendous to do, and of course exponentially increases your test workload for every possible combination of feature flags. If you're doing it by #ifdef it has the added effect of making code unreadable. Only really practical if "features" are "plugins".
- pfdietz 2y ago
  Or it's a really great idea, since you now can produce a diversity of software products, all of which should be correct on a subset of features, and all of which can be tested independently. Perhaps bugs can be flushed out that would be latent and undetectable in your standard build. Having lots of knobs you can tweak is great for randomized testing. The more the merrier.

Ygg2 2y ago

> that it would be even better for security to stop adding new features when they aren't absolutely necessary Even if features aren't necessary to sell your software, new hardware and better security algorithms or full on deprecation of existing algos will still happen. Which will introduce new code.

Animats 2y ago

Individual bugs triggered in normal operation ought to decay over time on software that is maintained. If bugs cause problems, someone may report them and some fraction of them will be fixed. That's a decay mechanism. Not-yet exploited vulnerabilities, though, don't have that decay mechanism. They don't generate user unhappiness and bug reports. They just sit there, until an enemy with sufficient resources and motivation finds and exploits them. There are more enemies in that league than there used to be.

elcritch 2y ago
Your assertions contradict the Usenix research cited in TFA, which found that the lifetime of vulnerabilities _do_ follow an exponential decay. If it takes longer to find a vulnerability, then its lifetime is longer.
- Animats 2y ago
  What the article calls a "vunerability" is something they found internally. Looking at vulnerabilities that were found from attacks, it looks different. [1] Most vulnerabilities are fixed in the first weeks or months. But ones that aren't fixed within a year hang on for a long time. About 18% of reported vulnerabilities are never fixed. [1] https://www.tenable.com/blog/what-is-the-lifespan-of-a-vulnerability https://www.tenable.com/blog/what-is-the-lifespan-of-a-vulne...
  - fanf2 2y ago
    I think that’s about time to deploy fixed code, not about time to discover the vulnerability nor about time to fix the code.
UncleMeat 2y ago
Vulns aren't just vulns. "Hey, in some weird circumstances we see a uaf here and the system crashes" is the sort of thing you might see in an extremely ordinary crash report while also having significant security implications. You can also uncover latent vulns over time through fuzzing or by adding new code that suddenly exercises new paths that were previously ill-tested. Yes, there are some vulns that truly will never get exercised by ordinary interaction and won't become naturally visible over time. But plenty do get uncovered in this manner.

pfdietz 2y ago

> vulnerabilities decay exponentially This should be true not just of vulnerabilities, but bugs of any kind. I certainly see this in testing of the free software project I'm involved with (SBCL). New bugs tend to be in parts that have been recently changed. I'm sure you all have seen the same sort of effect. (This is not to say all bugs are in recent code. We've all seen bugs that persist undetected for years. The question for those should be how did testing miss them.) So this suggests testing should be focused on recently changed code. In particular, mutation testing can be highly focused on such code, or on code closely coupled with the changed code. This would greatly reduce the overhead of applying this testing. Google has had a system where mutation testing has been used with code reviews that does just this.

theptip 2y ago

This is why I advise most folks to not take the latest point release of your language or libraries. The bleeding edge is where many of the new vulns are. In general the oldest supported release is usually the safest. The trade-off is when newer versions have features which will add value, of course. But usually a bad idea to take any version that ends “.0” IMO.