Collaboration is Key - Making the Open-Source Community Safer for Developers

Sonar is a code quality and security tool that helps developers write Clean Code. Sonar analyzes code for issues that lead to unreliable, unmaintainable, and insecure software at two points in the development lifecycle - first, when the developer initially writes code in the IDE with SonarLint and, again, as part of the Continuous Integration (CI) pipeline before the code is sent for release with SonarQube or SonarCloud.

To keep up with the latest cyber security trends and better understand emerging threats, the dedicated research team at Sonar finds and inspects vulnerabilities in modern open-source applications; we incorporate all of our insights into our products (SonarLint, SonarQube, SonarCloud).

In our endeavor to help secure open-source projects and improve, our research team decided to take a look at the Jenkins project.

Before we get started, we’d like to thank the Jenkins team for their fast response, dedicated effort to getting this fixed, and transparency throughout the disclosure process. Okay, let’s get into it…

We saw this research as an excellent opportunity - and a challenging one, because Jenkins is highly popular, well-maintained, and has a great community. Given the broad adoption and usage of Jenkins by the community, we felt it is important to analyze the security of this code base, and if we were to find a vulnerability, it would not only help the users of Jenkins but also help us better understand and improve the security capability of our solutions.

From a research perspective, ignoring the impact aspect, going into well-maintained code is a double-edged sword. On the one hand, the code has less potential for security vulnerabilities and poses a bigger challenge for finding bugs. On the other hand, because it is easily understandable code, in addition to the well-written and thorough documentation, the researcher can progress quickly and assess the project better.

Our initial research approach is more or less identical for each project. First, we try to understand the project from a user’s perspective. In the case of Jenkins, this was made easy due to the well-documented “Jenkins Handbook” and the large community that already tackled many issues and questions on the internet.

Following that, we started debugging and getting our hands dirty. Slowly but surely we got a good grasp on the architecture of Jenkins, from how the project “staples” an endpoint to a function to the authorization methodology, authentication methods, the intended behavior of various features, and more. With this better understanding of the technical internals, we can switch to an attacker’s perspective and think of the possible attack scenarios. Which endpoints can an unauthorized attacker reach? What can a limited authorized attacker do? Is a feature doing more than intended?

One of the important mindsets of a security researcher is to know when to give up and when to stay stubborn. Our findings were not easy to catch. Jenkins code quality is superb making it less likely to have security vulnerabilities. But, with our persistence, we noticed a niche feature that used third-party, unmaintained code, which allowed us to disclose sensitive information. Usually, the feature exploited requires specific permission to execute, but due to an exception thrown before the intended behavior, the sensitive data (which was exported from the third-party code) was leaked, enabling an attacker to have a serious impact on a Jenkins instance.

From Sonar’s point of view, we have analyzed the complex call graph and found unique ways to improve our engine. On top of that, it clarified for us the importance of deeper SAST, a feature that enables developers to automatically discover and fix code security issues arising from interactions between user source code and third-party, open-source libraries.

We were excited to have this opportunity to collaborate with the Jenkins team, while also making the open-source community safer and providing a technical blog post for educating the security expert audience. Throughout the disclosure process, we were met with an impressive level of professionalism and kindness that made all of this happen.

At Sonar, we’re dedicated to enabling developers to create Clean Code — code that is consistent, intentional, adaptable, and responsible. We believe that code quality and security go hand in hand. By focusing on Clean Code best practices, it is easier to avoid mistakes that lead to vulnerabilities in code. Our Clean as You Code approach ensures that code stays consistently clean avoiding the introduction of bugs and security vulnerabilities from the start with the quality of the codebase being optimized as code is added or changed.