Implementation of Static Code Scanning in Zhuanzhuan's DevOps Platform

Introduction

After the launch of Zhuanzhuan's self‑developed DevOps platform "beetle" at the end of 2017, the company began building its own DevOps toolchain, with static code scanning being one of the earliest capabilities. The following sections describe the concrete practice at Zhuanzhuan.

Significance of Static Code Scanning

Static scanning is a software security analysis technique that inspects source code or binaries for potential vulnerabilities and coding errors. Configured rules can detect security issues (e.g., XSS, SQL injection), logical errors, null‑pointer dereferences, uninitialized variables, and style violations.

By integrating scanning into the development‑test pipeline, teams can discover and fix problems early, reducing defect probability and improving overall quality. For Zhuanzhuan, it serves as a continuous, repeatable, low‑cost safety net, especially important when self‑testing accounts for about 70% of development work.

Overall Architecture

Pipeline Management: Uses Zhuanzhuan's internal CI/CD tool "beetle", a lightweight self‑developed platform.

Scanning Engine: Core functionality is provided by the community edition of SonarQube, while Jenkins schedules scanning jobs onto available scanning machines.

Process Flow: Scans are triggered asynchronously during compilation, results are displayed or blocked in the testing stage, and enforced during sandbox deployment to ensure incremental issues are corrected.

Static Scanning Workflow

Trigger Timing: When a branch is compiled, Jenkins automatically creates a Sonar task based on the branch name; if the task already exists, it re‑uses it. Both manual and automatic builds trigger a scan.

Result Reporting: After Jenkins finishes scanning, results are reported to the internal SonarQube platform, which runs analysis threads in the background and displays outcomes on the SonarQube UI.

Incremental Calculation: Because many services have a large backlog of existing static issues, Zhuanzhuan only blocks new issues introduced by the current branch, aiming for zero incremental problems. The calculation compares the current branch's scan results with those of the master branch to obtain the difference set.

Two incremental calculation schemes have been used:

Obtain static scan results for the development branch and the master branch, then compute the set difference (currently in use).

Obtain the development branch scan results and the changed line numbers, then match based on line numbers. This approach proved time‑consuming and inaccurate for large codebases.

Overall Interaction

Pipeline Display

On‑Demand Configuration

Personnel Permissions

SonarQube’s default username/password login is costly and hard to manage at scale. Zhuanzhuan implemented the following improvements:

Basic user info: Integrated LDAP to fetch basic account data.

SSO login: Modified the sonar‑auth‑gitlab‑plugin to authenticate via an internal OAuth service, achieving single sign‑on without relying on GitLab’s older SSO support.

Permission sync: Since SonarQube can view source code, full permissions cannot be granted to all users. During compilation, the system synchronizes project groups, members, and branch owners to SonarQube via its API, enforcing appropriate access controls.

Rule Selection and Promotion

Developers and testers recognize the value of static scanning as a low‑cost, proactive defect detection method.

Steps

Reach consensus with development and testing leaders through the technical committee to obtain cross‑departmental agreement.

Select rules: SonarQube offers many rule sets (built‑in, FindBugs, p3c, etc.). Using too many non‑official rules slows scanning and creates noise. Leaders collaboratively choose core rules and discard unnecessary ones.

Integrate the entire workflow into the CI/CD pipeline so users only need to review incremental results without manual interaction.

Continuously adjust rule sets based on business feedback and observed production issues.

Existing Problems

The community edition of SonarQube runs a single analysis thread in the background. For large projects, especially the "app" codebase where analysis can take around four minutes, this creates a backlog and blocks the pipeline. Zhuanzhuan mitigated the issue by deploying a separate SonarQube instance for the app projects, isolating them from backend services whose average analysis time is about ten seconds.

Conclusion

All backend projects at Zhuanzhuan now enforce incremental issue blocking. Static scanning together with dynamic code‑coverage tools have become essential safety nets in the development‑testing workflow, effectively preventing many common low‑level defects during self‑testing.

About the author: Chen Qiu, Head of Engineering Efficiency at Zhuanzhuan, responsible for configuration management and DevOps ecosystem construction. Feel free to leave comments and share experiences.