Hacker News Reader

Comment by theamk | Hacker News Reader

> An alarming 87% of container images running in production have critical or high-severity vulnerabilities, [...] Yet only 15% of those unpatched critical and high-severity vulnerabilities are in packages in use at runtime when patches are available. [...] Further, only 2% of the vulnerabilities are exploitable.

And this is why the numbers are so high -- because all of those "vulnerability reports" are complete junk most of the time. SSHD warnings for systems which do not run sshd. ImageMagick vulnerabilities for internal code docs generator. A high severity sudo vulnerability which requires a specific very uncommon configuration.

A great idea on paper, but it is achieving an opposite effect, teaching people that most of automated vulnerability detections are junk.

View on HN

I cannot empasis how true this is. The classic UNIX problem was that the LPT printer daemon has an issue (it had lots and lots). But, none of your systems were running LPT, but you still had to patch 1000+s of systems just to maintain a security policy.

What's different between full on UNIX systems and Docker, the possibility of deploying code based on scratch images. Imagine a system which only had the pieces necessary to run in production, your security exception reports would go to zero.

It’s almost free to rebuild and redeploy from a Dockerfile if you have a good devops culture. This would replace the traditional unattended upgrader with scheduled reboots.

I’ve worked doing data analysis on vulnerabilities, and it’s really really bizarre.

Some times the most secure systems are running insanely old software.

Sometimes software that’s a bit out of date correlates to fewer attacks.

When people are attacked, they upgrade their software. So a company that has gone a long time with no updates, followed by frantically updating everything could be a warning sign.

Maybe some weirdness is cleared up by noting that besides being an indication that upgrades haven't been necessary for a while, really old software often gains additional resilience to attacks by becoming more obscure with age. Targeted efforts are warded off somewhat by the unfamiliar attack surface and mass scanners typically won't be looking for ancient services. This is only tangentially related, but Im curious if you found anything about the typical length of time between systems being compromised to when intrusions are discovered as part of your work - if you would like to and are at liberty to share :)

Very old software may gain an edge. However, that takes a while and depends on the number of people using the old software as well. For instance, Windows XP was a big target for decades after it had been superseded by newer versions of windows. If your software stack is from the 90s, I'd say you might just getting obscure enough by this point.

Scanners are frequently not looking for the breakthrough 0-day vulnerabilities, but just for the low hanging fruit of old and well known vulnerabilities.

The local university maintained DECNet routing to support systems still in use in the physics department until the early 2000's (when they also ceased inter-building IPX routing). Guess which systems were never exploited for distributing Warez and porn?

All exploited systems before then were either windows nt or Linux. Commercial Unix (Dec, sgi, sun) rarely came up and generally only when there were accounts using identical credentials with a more exploitable platform.

What I'm also seeing is a knee-jerk reaction to COTS/OSS software, and people using these scores to justify building software in-house. Can't be vulnerable if you're not in vulnerability scanners, right?

Which seems a bit weird, as they wouldn't have paid a cent before for security auditing OSS codebases.

This drives me nuts. And I always remind myself not to fall into this behavior but can't help it with the sheer volume of alerts.

Reply on news.ycombinator.com