Tag Archives: Coverity Scan

New study shows: Vulnerabilities in popular open source projects doubled in 2019. No need to panic!

9 June 2020

Catalin Cimpanu’s (1) post on the RiskSense study “The Dark Reality of Open Source” is well worth reading. Open source software is used everywhere. A critical vulnerability in an application that is based on open source software can lead to a data breach. But this holds also for commercial software. We can also expect that the number of flaws in open source and commercial software is roughly the same.

The main difference is that the number of open source software reviews is much higher than the number of commercial software reviews. So the results of the study are not really surprising.

In the case of TomCat, 7 of the 72 published vulnerabilities were weaponized. A quick check against the latest Coverity scan results for Apache TomCat (2) shows that the software has 987 defects, thereof 290 not yet fixed.

High impact defects are very valuable for attackers because their exploitation results in a full loss of integrity. The number of high impact defects in TomCat yet not fixed is 171. So we can expect that the number of vulnerabilities that can be weaponized is high.

In the case of Puppet, none of the 72 published vulnerabilities were weaponized. The latest Coverity scan for Puppet (3) shows no high impact vulnerabilities. So the result is not surprising.

What is the difference between Puppet and TomCat? Puppet is written in PHP/Python/Ruby with a defect density of 0.20. The defect density is the number of defects in 1000 LoC. TomCat is written in Java with a defect density of 1.19. Thus, software reviews will definitely detect more vulnerabilities in TomCat than in Puppet.

This has direct impact on your security strategy. If you use TomCat as middle-ware in the DMZ you should design your application to allow frequent patching, means, more robust against changes in the middle-ware. In addition, automated testing is required to ensure operability in the case a patch must be implemented. Finally, your operations team must be prepared to install patches within few hours upon release by the vendor.

Have you ever seen such details for commercial software? Like IIS?

Have a great week.


1. Cimpanu C. Vulnerabilities in popular open source projects doubled in 2019 [Internet]. ZDNet. 2020 [zitiert 8. Juni 2020]. Available at: https://www.zdnet.com/article/vulnerabilities-in-popular-open-source-projects-doubled-in-2019/

2. Synopsys. Coverity Scan – Static Analysis for Apache TomCat [Internet]. 2020 [zitiert 9. Juni 2020]. Available at: https://scan.coverity.com/projects/apache-tomcat

3. Synopsys. Coverity Scan – Static Analysis for Puppet [Internet]. [zitiert 9. Juni 2020]. Available at: https://scan.coverity.com/projects/puppetlabs-puppet

Concerns about using open source libraries from an IT security point of view

18 December 2017

Some days ago I participated in a discussion about the necessity of using open source libraries in industrial software development and the data scientist workbench. IT security is often perceived as spoil sport in such discussions …

To be honest, I like open software. I prefer for example Firefox on Windows 10 because the configuration of Edge is really annoying. However, when it comes to the use of open software libraries in scientific or industrial software development projects or by data scientists I have two major concerns:

1. I have just no clue what the open software libraries do in addition to their intended use.

This sounds a bit paranoid. The question is:

Can we make sure, that no malicious code snippets are hidden in an open software library which send the company’s secrets to a cyber criminal’s command and control server, or which encrypt all data?

In my opinion this is not possible. Reviewing e.g. the 300 thousand lines of code of the OpenSSL-1.0.2 project is a herculean task, which has to be repeated for every patch and release. We can automate the software review process with advanced code analyzers. With such analyzers, we can make sure that open source code has no or few critical errors. But analyzers cannot find malicious code snippets, they just make sure that such snippets cause no critical errors during program execution.

Advanced Persistent Threat (APT) solutions may detect malicious behavior. But when a developer or data scientist includes open software into his code, the threat type changes from external to insider threat, thus APT solutions are no longer effective.

Eventually, we have to trust the developers of open software. Thus, the use of open software depends largely on the risk appetite of an organization.

2. I have no idea how to fix vulnerabilities in software which uses open software libraries.

Firefox gets security patches immediately after vulnerabilities are published. For example, the remote code execution vulnerability CVE-2017-7827, published 11/15/2017, was patched on the morning of 11/17/2017. When I logged in to my Linux box in the evening, even a patch for the Firefox ESR version was installed.

The OpenSSL-1.0.2 library mentioned above can be used potentially in many applications, in the worst case, some of them may be connected directly to the internet. The developers of Firefox take care of security bugs in this library. Who cares in the case of self-developed software? And how fast? Just remember the Equifax data breach some months ago. The reason for this really costly data breach was an unpatched vulnerability in the Apache Struts framework …

The focus of open software developers is innovation. Thus, the use of open software will be a major driver in the digital transformation, and we should foster this use to stay at the cutting edge of digital transformation.

Nevertheless, we must be aware of the risks of this use and take proper precautions for their mitigation.

Have a great week.