Silver lining in the open source vulnerability conundrum

Read time 3min 00sec

While most open source libraries used in the development of virtually every software application today contain risky code, addressing the problem is usually relatively simple, requiring only a minor version update rather than a major library upgrade.

That’s according to Veracode’s Suzanne Ciccone who was announcing the release yesterday of a special supplement to the company’s annual State of Software Security report that was published in late 2019.

The new Open Source Edition report was based on the examination of 352 000 external libraries in 85 000 applications from the Veracode scanning platform database. It found that there is a small number of libraries that are almost always found in applications, with the most commonly included libraries present in over 75% of applications developed in each language.

The report noted that while open source libraries allow developers to move faster by adding basic functionality that would be extremely tedious to write from scratch, there is widespread lack of awareness about where, how and which open source libraries are being used and their risk factors.

For example, most JavaScript and PHP applications contain hundreds of open source libraries and most languages feature the same set of core libraries.

In fact, including any PHP library in an application has a greater than 50%chance of bringing a security flaw along with it.

Prevalence brings risk. According to the report, of the more than 70% of applications that have a security flaw in an open source library, cross-site scripting is the most common, as it is present in 30% of libraries. Other categories of flaws found in libraries, which together represent 75% of all identified flaws, include access control (20%), insecure deserialisation (24%) and injection (9%).

Another issue is that developers may be pulling in more libraries than they realise. As a result, most flawed libraries end up in code indirectly: 47% of libraries are not pulled in deliberately by developers but are pulled in by the first library used.

This means that developers are introducing much more code, and often flawed code, than they might be anticipating.

The research revealed that flawed libraries don’t get used less that those with fewer flaws. “While there may be distinct characteristics by which developers choose the libraries they include, it doesn’t appear that security vulnerabilities is one of them,” the report stated.

In addition, the more libraries an application uses, the more flaws on average are going to be introduced.

However, the presence of a flaw in a library doesn’t necessarily mean that the flaws will be on the executable path of the application, or that an attacker will be poised to take advantage of it.

But this also doesn’t mean that the flaw should be ignored as it could cause problems at a later stage, and attackers are constantly finding new ways to identify and exploit them.

According to the research, securing these libraries does not have to be a major undertaking and can be addressed with a minor version update. In addition, fixes are available for even the worst and most dangerous flaws.

This therefore suggests that the problem is one of discovery and tracking, not a huge refactoring of code.

Login with