The risk issue is unpatched software, not open source use …
A lot of cases The open source community does an exemplary jobof issuing patches, often at a much faster pace than their proprietary counterparts
Vulnerabilities affect both Proprietary and OSS… and the key to patching software IS KNOWING WHAT SOFTWARE YOU HAVE
Fundamentally every organization is a software company whether they believe they are or not.
Remove projects with less than 1,000 files – percentage becomes 99% Last year was 57%, year before was 37% Most of the software analyzed were from companies who build software versus software that supports their enterprise… MEANING – proprietary code is the value. Gartner and Forrester state 90% of IT orgs use OSS in mission critical workloads And 90% of OSS is found in new codebases
THE REPORT Breaks down the percentages by industry.,
Black Duck scans indicate that the 20 most popular licenses cover approximately 98% of the open sourcein use. The OSI and the open source community have done a commendable job in reducing the multitude of open source licenses seen a decade ago
If these are not identified and tracked, components become out of date – which essentially puts the ownership of that version on the and owns the responsibility of the code… proprietary problem because the open source community has evolved
The most common vulnerability found was CVE-2012- 6708, jQuery before 1.9.0 vulnerable to cross-site scripting (XSS) attacks.
2017 – over 14,000 vulns 2018 – over 16,000 1999-2016, no year had more than 8,000
60%: TREND IS BETTER - Last year it was 78%
The average age of vulnerabilities identified 6.6 years
As some of you may know, this is one of my favorite open source components... not actually to use, but it demo's so well. In this case we are looking at an August vulnerability, CVE-2018-11776... which is a 9.3 out of 10 in the CVSS 2.0 scale.
On Aug 21st, this vulnerability was disclosed. It was reported that a handful of versions could be exploited with remote code execution. On the same day, the Apache published an updated version.
Now patches typically aren't built in a day, so there is a process that is followed, called the Vulnerability Embargo Process. That means a responsible security researcher, such as Man Yue Mo, discovers a vulnerability, and then notifies the vendor.
This occurred on Aug 9th, and the Apache Struts project worked with Man Yue Mo to create the patch.
An interesting thing to note, is that vulnerabilities tend to exist in projects well before they are discovered. In this case.... Version 2.0.5 is where this vulnerability was introduced, some 11 1/2 years ago.
NOW... the very next day, within 24 hrs, Black Duck published full details about this vulnerability. That includes things like how to fix it, what a workaround may be, all sorts of technical data and CVSS scoring. What you found on the CVE detail, was a number and a description... it looked like this:
ANOTHER thing to note, is initially, this vulnerability was thought to only affect a handful of versions, however, the Black Duck Security Advisory team found 23 additional versions that were affected, and reported this back to Apache Struts. Now this page that you see here, was currently awaiting analysis until...
Nov 1st, some 2 months after the vulnerability was disclosed. So, if you were only using the CVE list, you would have a number, and a description, but couldn't tell if it was high, medium, low - if there was a workaround or a fix... and ...
... this is 2 months too late, as hackers are automating exploitability these days when vulnerabilities are disclosed.
Automate and Enhance Application Security Analysis