GitLab has acquired security software firms Peach Tech and Fuzzit to bolster the company's security portfolio overall and its DevSecOps tool set in particular.
Seattle-based Peach Tech specializes in protocol fuzz testing and dynamic application security testing (DAST) API testing. Fuzzit offers a continuous fuzz testing system that provides coverage-guided testing.
Fuzz testing is an automated software testing technique that finds coding errors and security loopholes by throwing lots of random data, or "fuzz," at a system to uncover vulnerabilities or make it crash. Coverage-guided testing uses program instrumentation to trace the code coverage of each input fed to a fuzz target.
"Coverage-guided is very similar to static analysis testing, where they're scanning the source code, and you're creating unit tests and testing over components within the source code repository," said David DeSanto, GitLab's director of the secure and defend sections.
The addition of Peach Tech and Fuzzit will enable GitLab customers to shift fuzz testing left as GitLab makes these offerings available in the GitLab CI/CD environment. The company will have a preview of Fuzzit integrated into the GitLab platform in its July release and the Peach Tech technology will be in the October release, DeSanto said.
The addition of both coverage-guided and behavioral fuzz testing techniques to the GitLab platform will help users find vulnerabilities that traditional testing and quality assurance techniques may miss. That's because fuzz testing can uncover issues that may not be tied to a known vulnerability in a list of common vulnerabilities and exposures.
Thomas MurphyAnalyst, Gartner
"Gitlab acquiring companies that build security tools is a smart move," said Clint Gibler, head of security research at software security startup r2C. "GitHub does seem to have the upper hand in SAST [static application security testing] due to the acquisition of CodeQL, but I expect GitLab's suite of open source tools will offer 'good enough' coverage for many companies."
Moving aggressively to DevSecOps
GitLab's goal is to be a single application for the DevOps lifecycle. As such, experts that follow this industry said these acquisitions were not unexpected, but they create another issue for GitLab.
"I think the challenge is market understanding of what fuzzing is and the fact that there are different ways that the concept gets put to use in practice," said Thomas Murphy, a Gartner analyst.
By 2022, 90% of software development projects will claim to be following DevSecOps practices, up from 40% in 2019, according to Gartner. Also by 2022, 25% of all software development projects will be following a DevOps methodology from conception to production, up from less than 10% today, Gartner said.
"I do believe a strong direction in DevOps is to integrate security into the workflow," Murphy said. "As much or more than other development issues, security has long been too siloed off from the delivery process, so you end up focusing on finding the needle in the haystack or building perimeters."
Although the concept of fuzzing has been around for decades, in recent years it has been used for application security testing for IoT, where DAST is not workable, said Sandy Carielli, an analyst at Forrester.
DAST tools are not feasible for IoT because they crawl web interfaces and APIs to find vulnerabilities but can only test those externally-facing parts of the application. IoT products are difficult to crawl and often use other protocols, so DAST tools may not be sufficient.
Part of GitLab's announcement focuses on DAST API testing. API security will be integrated for API fuzzing, and it will be integrated as GitLab's web vulnerability scanner for rest APIs as well, DeSanto said.
"API security is a growing concern, and there have been a number of high-profile security breaches that can be traced to poor API security practices," Carielli said. Baking security into the DevOps toolchain helps developers find bugs and vulnerabilities early in the development cycle.
At a macro level, application security testing in general has been moving away from a point-in-time activity conducted against an application -- either in production or before an application is released to production. Security testing is moving to continuous activities conducted in as automated and frictionless a method as possible at every stage of the software development lifecycle, according to Daniel Kennedy, an analyst at 451 Research.
"In other words, allowing developers and security folks to easily kick off scans as well as continuous background scans, providing ongoing feedback on the security disposition of any application," he said.