It's only been six months since Google released the beta of their new tool OSS-Fuzz, and it's already proving itself as an amazing tool, both for open source application developers and the communities that are using and supporting them.
OSS-Fuzz's goal is to to make common software infrastructure more secure and stable. Google initiated this effort of putting all common infrastructure open source libraries under the same security umbrella, while executing regular fuzz tests on them.
Fuzz tests is a software testing technique used to discover security vulnerabilities and coding errors that may lead to an attack that can compromise sensitive data or deny a service. In simple words, fuzzing is actually sending a lot of different data to an application or a library, with the goal of trying to crash it or awake some kind of bug. For example, sending "1125$$@12%!zz" as an input to an application instead of a person's first name, might result in an application crash if the inputs were not validated properly on the application's side.
In the last few months, Google's OSS-Fuzz scanned dozens of popular libraries looking for these sort of bugs. Well, it didn't come back empty handed. It discovered close to 1,000 bugs, while hundreds of them are high risk security vulnerabilities, memory issues and other threatening vulnerabilities.
As examples, these are the bug counts found for these popular open sources:
FreeType2: 10 bugs
FFmpeg: 17 bugs
LibreOffice: 33 bugs
SQLite: 8 bugs
Wireshark: 7 bugs
And the list goes on (with libxml2, libpng, lcms, json and others included in the list)...
The important part to understand here is actually not the fact that OSS-Fuzz found some bugs in some open sources. It's actually the part that impacts you, as a developer, as a manager in a tech company that produces products that are relying on this critical infrastructure open sources to function. That actually means that once they contain a bug, your software contains a bug, and your customers are potentially exposed to those security loopholes.
So what can you do? First, start tracking those bugs and make sure they are resolved or at least not threatening to your customers.
Also, keep track of the open sources on their list, as it will be updated once in awhile with new open sources, and you might be using some of them.
Summary
When using open source libraries, you can't assume you are safe. Those libraries are written by programmers just like you and me, which make daily mistakes, just like you and me.
Therefore, you need to keep an eye (or maybe two eyes) on the security status of these libraries, before integration, and especially after integrating and releasing them as part of your production products.
Keep it safe (and simple)!
