| |
mark :: blog
Every year since Red Hat Enterprise Linux 4 was released we've
published a risk report where we look at the state of security
of the distribution. We investigate the key vulnerabilities,
metrics on vulnerability counts, and how users could have been
exploited by them. The
Six
Years
of Red Hat Enterprise Linux 4 report (PDF) covering Feb 2005-2011
was published today.
"Red Hat knew about 51.5% of the security vulnerabilities
that we fixed in advance. The
average time between Red Hat knowing about an issue and it being made
public was 23 days (median 10 days).... A default installation of Red
Hat Enterprise Linux 4 AS was vulnerable to 20 critical security
issues over the first six years. "
The data we publish is interesting to get a feel for the risk of running
Enterprise Linux, but isn't really useful for comparisons with other
distributions, or operating systems. One important difference is that it is Red
Hat policy to count vulnerabilities and allocate CVE names to all issues that
we fix, including ones that are found internally. This is not true for many
other vendors including folks like
Microsoft
and
Adobe
who do not count or disclose issues they fix which were found internally.
Created: 17 Aug 2011
Tagged as: metrics, microsoft, red hat, security
3 comments
(new comments disabled)
|
|
|
Hi! I'm Mark Cox. This blog gives my
thoughts and opinions on my security
work, open source, fedora, home automation,
and other topics.
pics from my twitter:
popular tags:
[all],
apache,
apachecon,
apacheweek,
cve,
cvss,
fedora,
financial,
geocaching,
ha,
metrics,
microsoft,
nashville,
north carolina,
red hat summit,
redhat,
security,
trips
|
|
> One important difference is that it is Red Hat policy to > count vulnerabilities and allocate CVE names to all issues > that we fix, including ones that are found internally. what's that mean? do you guys evaluate every change you make or receive to any code for security impact? last i heard on lkml, that's not what happens for the kernel at least ;). the same source also confirmed that it is kernel policy to explicitly not to do what you claim above. how do you reconcile this apparent contradiction? or did you since fire Ingo? ;)