Source-linked AI summary
Automating Static Code Analysis Through CI/CD Pipeline Integration
Zachary Wadhams, Ann Marie Reinhold, Clemente Izurieta
TL;DR
The paper addresses limited SAST adoption caused by usability and pipeline-integration barriers that hinder early vulnerability management. It proposes a generalized automated process for aggregating SAST outputs into familiar issue-tracking software and demonstrates it with SonarQube in GitLab. Developers responded positively to the structured workflow, real-time feedback, and proactive vulnerability management, although workflow tradeoffs and limited generalizability remain.
Problem
SAST adoption is hindered by false positives, weak warnings, limited fix guidance, insufficient pipeline support, and organizational access barriers.
Method
The paper aggregates SAST reports through a controller script, standardizes the data, and integrates findings into repository issue-tracking software within CI/CD pipelines.
Results
Developers viewed the implementation positively, especially its structured automation, GitLab integration, real-time feedback, and proactive vulnerability management.
Takeaways & Limitations
The process can improve visibility and accessibility of security issues while supporting more proactive vulnerability identification during development.
Takeaways & Limitations
The single-organization SonarQube implementation limits generalizability, and results cannot be compared practically across other SAST tools.
Abstract
from arXiv · showhide
In the contemporary landscape of software devel-opment, securing sensitive data is paramount to safeguarding organizational reputation, preventing financial losses, and pro-tecting individuals from identity theft. This paper addresses the pervasive challenge of identifying and rectifying security vulnerabilities early in the development process, emphasizing the role of Static Application Security Testing (SAST) tools. While SAST tools play a crucial role in detecting vulnerabilities, widespread adoption has been hindered by usability issues, including high false positive rates and a lack of native pipeline support. This paper proposes a novel, generalized, and automated process for aggregating SAST tool outputs and integrating them into developers' familiar issue-tracking software. The process streamlines the identification and communication of security vulnerabilities during the development lifecycle, facilitating more efficient remediation efforts. We demonstrate the successful implementation of the proposed process with the SonarQube SAST tool in a GitLab-based development environment. Developers were positive about the structured implementation, real-time feedback, and proactive vulnerability management. However, despite some challenges such as a potential learning curve and tradeoffs between secure coding and workflow disruption, the overall positive impact on security awareness and responsiveness suggests that the proposed process holds promise in enhancing the security posture of software development practices
I. INTRODUCTION
Software security requires early vulnerability detection, but SAST adoption is limited by usability and pipeline-integration problems. The paper proposes a generalized automated process that delivers aggregated SAST findings through familiar issue-tracking systems and examines its practical implementation.
- Security breaches can damage organizational reputation, cause financial loss, and harm individuals through identity theft.
- SAST analyzes source code during development to detect vulnerabilities early and support prompt remediation.
- Most SAST tools lack automation or native CI/CD pipeline support, limiting their integration into development workflows.
- Usability barriers include false positives, unhelpful warnings, missing fix suggestions, and insufficient pipeline support.
- The paper proposes a generalized automated process that aggregates SAST outputs and integrates them into familiar issue-tracking software.
- A practical implementation is examined as a case study to assess feasibility, effectiveness, challenges, and implementation considerations.
II. MOTIVATION
The motivation is to make security analysis more accessible and timely within development workflows. The proposed approach uses repository issue-tracking features to reduce disconnects between developers and security personnel.
- Organizations face moral and legal obligations to release software that protects user privacy and security.
- SAST can operate from the beginning of coding, enabling proactive security analysis earlier than dynamic analysis.
- Firewall restrictions and limited report access can separate developers from security experts, slowing fixes or allowing vulnerabilities to remain undetected.
- The process leverages familiar repository issue-tracking features to increase visibility and provide an accessible space for managing vulnerabilities and design flaws.
III. RELATED WORK
Related work identifies poor output presentation, slow feedback, workflow disruption, and limited integration as barriers to SAST use. The paper positions its process as a non-disruptive way to deliver findings within developers’ existing workflows.
- Prior studies identified poor output presentation, slow feedback, uncertain scoring, and error propagation as SAST usability concerns.
- Immediate or near-immediate code feedback makes developers more likely to consider the findings.
- Research links developer-introduced errors and gaps between security knowledge and practice to the continuing importance of static analysis assistance.
- Developers may correctly address security messages even with little or no formal security experience.
- Many tools store outputs in unfamiliar locations, requiring developers to change habits and disrupting workflow integration.
- The proposed process delivers analysis outputs in a non-disruptive, visually appealing format intended to preserve productivity and workflow.
IV. PROCESS
The process begins by identifying organizational SAST and development-environment requirements, then implements a controller script connecting analysis tools with issue tracking.
- The process first identifies preferred SAST tools and the data they provide, then examines the target environment before implementation.
- A controller script is implemented to connect SAST tools with the organization’s issue-tracking system.
A. Tool Identification and Data Assessment
The process selects GUI-based static analysis tools, treating GUI tools with APIs as the primary focus because APIs simplify report retrieval and integration.
- The process focuses on GUI tools, which generally provide greater customizability and often expose APIs.
- APIs simplify data retrieval by returning analysis reports in commonly formatted structures.
- GUI tools without APIs are treated equivalently to CLI tools within the process.
- CLI tools generate XML- or JSON-formatted report files but are outside the process’s primary focus.
B. Development Environment Exploration
The process is tailored to the organization’s development environment, especially its repository host, issue-tracking system, pipeline, and security constraints.
- The process targets GitHub, GitLab, and Bitbucket environments because these systems commonly host code and provide issue-tracking APIs.
- Repository-hosting APIs enable automated creation, editing, and resolution of issues across issue-tracking services.
- The controller script is placed after SAST execution so analysis completes before report data is retrieved.
- The process can accommodate firewalls when the tool-hosting machines and pipeline can communicate and bypass relevant firewall rules.
C. Controller Script
The controller script bridges SAST reporting and issue management by collecting, transforming, and synchronizing findings through pipeline-driven automation.
- The controller script orchestrates data flow between SAST tools and issue-tracking systems using a pipeline-supported scripting language.
- It retrieves raw SAST data through a tool API and transforms it into a standardized issue-tracking format.
- The issue-tracking API automatically creates tickets and synchronizes updated analysis results when developers commit code.
- Marking findings already transferred prevents duplicate issues and limits processing to new findings.
- A quality gate can halt pipeline progress after issue generation when major vulnerabilities or other high-risk issues are detected.
- The script can collect vulnerabilities, bugs, or design issues while filtering them by severity or impact.
V. USE CASE
Organization X implemented the process with SonarQube, Python, and GitLab under firewall constraints, then reported positive developer responses and limited workflow disruption.
- V. USE CASE: Organization X adopted the process to introduce static analysis for an application under development.
- V. USE CASE: Organization X selected SonarQube after evaluating its usability, configurability, and scalability for a growing codebase.
- V. USE CASE: The implementation used a GitLab repository for hosting code, managing pipelines, and tracking issues.
- V. USE CASE: Firewall requirements restricted SonarQube access to two senior developers among more than twenty developers.
- V. USE CASE: The Python controller retrieved SonarQube vulnerabilities and bugs through its Web API and sent formatted payloads to GitLab.
- V. USE CASE: Developers found the generated issues helpful and easy to identify, while the process avoided pipeline disruption and significant runtime increases.
VI. DISCUSSION
Developers responded positively to the structured SAST integration and its real-time vulnerability feedback, while identifying false-positive review and workflow adaptation as challenges.
- The quality gate rejected changes as expected, but developers disagreed about whether its rigidity disrupted focused coding or saved time later.
- Developers appreciated the structured implementation, automated issue identification, and integration with GitLab’s API and existing pipelines.
- Real-time feedback helped developers fix issues immediately or plan remediation for a later date.
- Systematic vulnerability identification uncovered previously unknown genuine issues that developers believed might otherwise have remained undetected.
- Detailed issue formatting made false positives harder to recognize, while the new process initially met resistance because of its learning curve.
- The discussion frames secure coding versus workflow disruption as a trade-off requiring balanced adaptation and continued process refinement.
VII. THREATS TO VALIDITY
The study’s validity is constrained by the characteristics of one organization and by using only SonarQube, limiting direct evidence about generalizability across organizations and tools.
- Organization X may have unique characteristics that limit generalizing the process findings to other organizations.The authors compared its development environment with known environments but acknowledged that this review was hardly exhaustive.
- Because Organization X used only SonarQube, the study lacks a practical implementation of other SAST tools for comparison.
- Future work will test additional tools to assess whether the process generalizes beyond the studied implementation.
VIII. CONCLUSION AND FUTURE WORK
The paper concludes that automating SAST-output integration into familiar issue-tracking software improved issue visibility and was not overly intrusive in the use case, while further tool coverage remains needed.
- The process automates aggregation of SAST outputs into developers’ familiar issue-tracking software, enhancing the visibility and accessibility of security issues.
- In the use case, developers were mostly satisfied with issue presentation and found the workflow addition not overly intrusive.
- Future work will add functionality and extend the process to CLI-only SAST tools that lack APIs for data retrieval.