Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

> 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.

View on HN

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.

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.

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-vulne...

I think that’s about time to deploy fixed code, not about time to discover the vulnerability nor about time to fix the code.

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.

> 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.

> 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.

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.

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!

> 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.

> 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.

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.

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".

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.

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.

Reply on news.ycombinator.com