Deep code analysis designed for developers and focused on code quality is here.
When you have an awesome new product aimed at helping developers catch and fix code quality issues during code review, it’s hard not to get excited. Then, combine that with an even cooler new mascot, who by day is “Lift-bot”, your new teammate who reviews every pull/merge request, and by night is “Rocket Squirrel”, a cosmonaut galavanting around the universe looking for deep code security issues, how do you resist pulling out every space reference you can think of?
“Captain's log, Stardate 06.15.21. These are the voyages of Sonatype Lift…”
“Not so long ago, in a galaxy not far, far away, we were witnessing all kinds of new software supply chain attacks…”
“There are those who believe that the bugs here began out there, far across the internet…”
“It can be a dangerous place, but it’s our last, best hope for quality code… this is the story of Sonatype Lift. “
Or my personal favorite:
“Houston, we have Lift Pro…”
But then you realize that a) those are cheesy and don’t do justice to the originals b) if I did all the references I wanted to, I’d never get to tell you about Sonatype Lift.
Setting all space puns aside, let’s talk about code quality, deep code analysis, and launching (ok, not all puns) Sonatype Lift, the newest addition to the Sonatype family.
Code Quality as a Security Issue
In the past year, cyber attacks have increased exponentially, with malicious actors now going after software supply chains to exploit vulnerabilities in commercial and open source code. We’ve seen this in both the SolarWinds and Codecov incidents. Even the world’s largest companies aren't immune to software quality defects inadvertently reaching production, as proven by Apple’s recent report of vulnerabilities in its Webkit browser SDK and its iOS Kernel.
Another trend we’re witnessing is that code quality issues are increasingly becoming security issues. As the recent Fastly outage demonstrated, innocent coding errors can cause just as much damage as intentional cyber attacks. Developers and security teams need to work together to ensure that code is both reliable and secure.
Problems with the Traditional Code Quality Approach
There has always been friction in the development process. Traditional development cycles pit developers pushing to release code faster, against security engineers needing to stop issues from reaching production. This slows development and causes critical bugs and vulnerabilities to get missed.
There are also issues with the tools themselves. Most code quality tools only do lightweight analysis or linting to catch performance and reliability bugs. They inspect each file in isolation, which means they can’t analyze an entire repository after build to identify deeper problems that span across the project. .
Since basic linters don’t find most security issues, you need yet another tool. Static/Dynamic Application Security Testing (SAST/DAST) tools do the deep code analysis required to catch security risk, but they take a long time to run and miss the quality issues that linters will find.
In addition to all this, existing code analysis tools generate too many unimportant issues (noise) and take time to weed out. This leads to issues ignored, issues unseen, and the tools themselves abandoned. Noisy tools don’t fit within developers’ workflows, causing a switch from one system to another, which slows software delivery even more, as well as feeding back into animosity between security and dev teams.
Research on Developer Tools
While security, quality assurance, and other stakeholders can create or implement tools, only developers can actually fix bugs. Getting feedback about quality and security issues to developers then is essential. Recent studies at both Facebook and Google have outlined that it’s more important “how and where” you make developers aware of these code issues than it is about the volume or issues themselves.
Facebook conducted a study in which they started using a “ ‘diff time’ deployment, where analyzers participate as bots in code review, making automatic comments when an engineer submits a code modification.” This was different from their old way (most of us can relate to this) where a list of bugs is presented to engineers outside of their daily workflows, expecting them to triage the list and repair what they find. Facebook goes on to “recount a striking situation where the diff time deployment saw a 70% fix rate, where a more traditional ‘offline’ or ‘batch’ deployment saw a 0% fix rate.”
Did you catch that? In this study, none of the bugs on the list handed to developers after all of the code was completed were actually fixed. Zero percent!
Google also researched optimized code quality and deep code analysis tools integrated into their pull request process. Now, every time code is submitted via a pull request, it goes through a peer code review, where developers receive input from teammates and tools on any issues that are found in the code. Once this review is complete and changes are implemented, the code is merged into the main branch for release.
Google concluded that “a code review check should...
- Be understandable
- Be actionable and easy to fix
- Produce less than 10% effective false positives (devs are fixing 90% of what is reported)
- Have the potential for significant impact on code quality.”
Principles of Deep Code Quality Analysis
Based on these findings and our own research, Sonatype’s team put together some key principles that became the foundation for Sonatype Lift:
- Use multiple tools: No single tool will find all of the types or errors that you care about.
- Integration matters: It’s not just about the tools you choose, but how you incorporate them into your processes and workflows.
- Cherish developer trust: Aim to keep improving tools, as developers will ignore or remove tools that they feel don’t provide clear value or waste time.
- Support productivity: Most developers are worried that too many tools or too many checks in Continuous Integration (CI/CD) will only slow down their processes. Make sure the tools become part of the process and not a distraction.
Introducing Sonatype Lift
Lift is easily installed on any source repository, with out-of-the-box support for GitHub, GitLab, and Bitbucket. Developer-friendly feedback then appears on issues around both security and code quality. This means a wide range of bug types are addressed, from lightweight style issues to complex coding errors commonly found in first-party source code.
The process works like this: every time a developer submits a pull request, Lift automatically analyzes their code and then reports bugs as comments in code review. The comments will surface alongside feedback from other developers on their team. This means accurate and actionable feedback for your developers at the right time and right place
The insights come from 26 (and counting) pre-configured code analyzers that aggregate and orchestrate into a single platform. Fix rates are tracked and input is continually tuned to ensure high-quality results. Its simple goal is to give feedback on bugs that developers are most likely to fix.
Additionally, Lift catches issues in open source libraries developers rely upon by pulling Software Composition Analysis (SCA) data from Sonatype’s Open Source Software Index to report vulnerable open source libraries.
Strengthening Developer and Open Source Communities
Sonatype Lift will be free forever for public repositories. As we look for more ways to serve the open source community, we want to do our part to help open source maintainers improve their code quality and security. We figure if we do that well, we can help secure the software supply chain itself.