Open source software has worked its way into the vast majority of organizations around the world. Surveys have found that nearly all organizations have open source libraries somewhere in their codebases, and as many as three out of four are using some sort of open source software to boot. That makes open source security a universal business issue, and a new report from security firm Veracode presents some very troubling findings.
The lead item is that one can expect the majority of both applications and libraries to have unpatched security flaws, and/or may no longer be updated. Given this, the security status of open source elements can change very quickly. Veracode finds that the issue is not so much one of neglect or incompetence at the developer end, however; developers that lack context about how vulnerable libraries impact their applications usually take months to address most of the existing flaws, while this time is reduced to a matter of weeks (and sometimes requires as little as one update) when this information is available to them.
Open source security requires greater diligence than many organizations are providing
The annual Veracode State of Software Security report has been centered on examining trends in third-party software in recent years. This year’s report focuses on library dynamics and how developers react to library changes (particularly the discovery of vulnerabilities and flaws). The study drew on a combination of a survey of 1,744 developers and 13 million scans of some 86,000 repositories containing 301,000 unique libraries.
One of the most important findings is that 92% of library flaws can be fixed via an update, but 79% of the time developers never update third-party libraries after they are added to a codebase. While developers do have understandable reticence about frequent updates due to the prospect of inadvertently breaking things, the report found that 69% of updates that address open source security issues are a minor version change (or smaller) that stands a low chance of causing any such problems.
Information being made available to security and development teams is also a crucial factor. When developers are aware that a library is vulnerable, they correct the flaws within one hour 17% of the time and within one week 25% of the time. When they lack contextual information about how a vulnerability in a library relates to their application, developers take more than half a year (7+ months) to fix 50% of the flaws. This same amount is fixed in an average of three weeks when developers have the necessary information about libraries.
The report examined ten of the most popular open source libraries across a variety of programming languages. It notes that the use of these top libraries has changed quite a bit since last year, with some that were in the top five already having fallen precipitously off the list. This illustrates how quickly the open source security situation can change and the need for developers to be on top of these changes as they take inventory of what is in their applications.
This rapid rise and fall of library popularity seems to have an influence on processes for evaluating and selecting them. Almost half of the respondents said that their organization either does not have a formal process for library selection, or if it does they are not aware of it and do not use it. Of the slightly more than half that do have a formal process in place, only about the same segment (52.5%) say they “always” evaluate open source security at this time. 13.9% said that they “rarely” evaluate open source security. However, these evaluations don’t seem to be making a big difference: developers that said they “always” consider security still had vulnerabilities in 80.7% of their third-party libraries, only a small improvement over the 84.2% that those who were not so rigorous in their evaluations had.
Licensing issues also tend to be common due to a general failure to do due diligence. Over 54% of respondents said they do not always check the library license to ensure that what they’re doing with it is actually legally permitted, as compared to 27% that always check.
Difficulties of addressing open source security vulnerabilities
What do developers say are the leading factors preventing them from addressing open source security vulnerabilities? Unsurprisingly, the leading issue is resources; lack of resources causes vulnerabilities to take 13.7 times longer to address on average. Other significant factors are a lack of information available to solve an issue, situations in which the only viable fix would break application functionality in some way, and the staff simply not having the skills to address the issue.
The report’s ultimate conclusion is that while “set it and forget it” approaches remain common, the state of constant flux in modern open source security almost guarantees a problem will develop sooner rather than later. While libraries tend to be infrequently updated, fixes are often no more complex than a minor software update and are unlikely to create issues with even more intricate applications.