ClusterFuzzLite
For several years, Google has been making a concerted effort to improve the security of open source software. The challenge for all developers is finding a way to build more secure applications without slowing down the rate at which they are deployed. Fuzz testing makes it possible to identify issues much earlier in the application development life cycle versus just before an application is deployed.
In recent years, continuous fuzzing has become an essential part of the software development lifecycle. By feeding unexpected or random data into a program, fuzzing catches bugs that would otherwise slip through the most thorough manual checks and provides coverage that would take staggering human effort to replicate. NIST’s guidelines for software verification, recently released in response to the White House Executive Order on Improving the Nation’s Cybersecurity, specify fuzzing among the minimum standard requirements for code verification.
Google announce ClusterFuzzLite, a continuous fuzzing solution that runs as part of CI/CD workflows to find vulnerabilities faster than ever before. With just a few lines of code, GitHub users can integrate ClusterFuzzLite into their workflow and fuzz pull requests to catch bugs before they are committed, enhancing the overall security of the software supply chain.
Since its release in 2016, over 500 critical open source projects have integrated into Google’s OSS-Fuzz program, resulting in over 6,500 vulnerabilities and 21,000 functional bugs being fixed. ClusterFuzzLite goes hand-in-hand with OSS-Fuzz, by catching regression bugs much earlier in the development process. Large projects including systemd and curl are already using ClusterFuzzLite during code review, with positive results.
With the release of ClusterFuzzLite, any project can integrate this essential testing standard and benefit from fuzzing. ClusterFuzzLite offers many of the same features as ClusterFuzz, such as continuous fuzzing, sanitizer support, corpus management, and coverage report generation. Most importantly, it’s easy to set up and works with closed source projects, making ClusterFuzzLite a convenient option for any developer who wants to fuzz their software. Here are some other features of this tool.
Features
Quick code change (pull request) fuzzing to find bugs before they land
Downloads of crashing testcases
Continuous longer running fuzzing (batch fuzzing) to asynchronously find deeper bugs missed during code change fuzzing and build a corpus for use in code change fuzzing
Coverage reports showing which parts of your code are fuzzed
Modular functionality, so you can decide which features you want to use
Supported Languages
C
C++
Java (and other JVM-based languages)
Go
Python
Rust
Swift
Supported CI Systems
Support for more CI systems is in-progess, and extending support to other CI systems is easy
Supported Fuzzing Engine and Sanitizers
libFuzzer for coverage-guided testing
AddressSanitizer for finding memory safety issues
MemorySanitizer for finding use of uninitialized memory
UndefinedBehaviorSanitizer for finding undefined behavior (e.g. integer overflows)
Is there a difference between ClusterFuzz and ClusterFuzzLite?
Google says that ClusterFuzzLite can be integrated into existing workflows to fuzz pull requests, improve the chances of finding bugs/vulnerabilities earlier before anything is committed.
ClusterFuzz and ClusterFuzzLite contain some of the same features, including report creation, continuous fuzzing, and sanitizer support. They differ during setup, as ClusterFuzz is easier to set up with closed-source projects. ClusterFuzz supports Google Cloud Build, GitHub Actions, and Prow.
Getting Started
If you’re new to using libFuzzer and sanitizers, start with the Overview for an explanation of terms and the fuzzing process.
If you’re already familiar with using libFuzzer and sanitizers, start with Step 1: Build Integration.
The documentation for this tool can be read at GitHub.
Less clear, of course, is whether developers are starting to use these tools on their own or if the increased adoption is because of a concerted effort by their organization to embrace DevSecOps best practices. Regardless of the motivation, however, the overall state of application security should continue to improve as it becomes simpler for developers to invoke more advanced testing tools. If your organization wants to improve the implementation of security tools and DevSecOps best practices, check out our services in terms of security and contact us by clicking the button below.
