Open Source – The New Attack Vector
There are people who think open source is the holy grail of software, I am not one of them. Apparently hackers agree with me. So does the Department of Defense. They have even coined a term – SCRM or Supply Chain Risk Management.
Bottom line, developers need to understand that there is a war out there and they are the target. According to Sonatype, the open source tools and governance company, said that the use of vulnerable open source components is up by 120% over the last 12 months,
Sonatype estimates that there are 1.3 million – yes, million – vulnerabilities in open source software components that are not recorded in the National Vulnerability Database managed by NIST.
Sonatype estimates that the average enterprise downloads 170,000 source components a year of which possibly 1 out of 8 of those have some form of vulnerability. Sometimes those vulnerabilities get exploited in as little as 3 days.
Developers are still downloading vulnerable versions of Apache Struts (as in Equifax breach). About 80,000 times every month.
Downloads of a vulnerable version of the Spring Framework was around 85,000 a month last year; this year it is still 72,000 a month.
To add insult to injury, hackers are starting to inject vulnerabilities directly into some open source packages. Done cleverly, such a logic bomb might never be discovered.
Point is, still a HUGE problem.
So what do you need to do?
#1 – Admit that open source software is far from bug free – even hugely popular packages like Apache Struts.
#2 – Create a SCRM program. The larger the open source software package is, the more difficult it is to make sure that it is safe.
#3 – Consider using automated tools to detect vulnerabilities. Some of the tools are free and others are very expensive, and all of them change the development process. Some of them are built into the software tools that developers are already using.
#4 – Create a process for finding out about patch availability. Unfortunately, except for the most popular open source packages, they are never patched, so you are pretty much on your own.
#5 – Treat open source packages just like code you develop when it comes to code reviews and testing. The only difference that you can’t influence the development process.
Information for this post came from The Register.
by 