Incremental SAST Analysis for Source Code Version Changes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Static application security testing (SAST) can be computationally expensive due to its cubic time complexity with respect to source code length, particularly when flow-sensitive analysis is performed, and existing methods do not efficiently leverage previous SAST results in iterative software development.
Innovation Solution
Perform flow-insensitive SAST on a pruned representation of source code to reduce its size, followed by flow-sensitive SAST, and utilize analysis of a second version of source code in relation to a previously tested first version to identify security vulnerabilities more efficiently.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If flow-sensitive SAST is performed on the entire source code, then security vulnerability detection precision is improved, but execution time increases cubically with source code length
Solution Approach 1:
The source code is divided into multiple functions, and the SAST analysis is segmented to process each function individually. The system identifies entry and exit points of functions and analyzes control flow within each function boundary, rather than analyzing the entire source code as one large unit. This segmentation reduces the computational complexity from cubic to a more manageable level while maintaining security vulnerability detection precision.
Solution Approach 2:
The patent extracts and removes unnecessary code elements from the analysis process. By identifying and eliminating redundant statements, unreachable code, and non-critical paths through the source code, the system reduces the amount of code that requires flow-sensitive analysis. This extraction of essential analysis targets maintains detection precision while significantly reducing execution time.
2Reliability
If SAST is performed on every version of source code in iterative development, then security vulnerability identification is improved, but development productivity deteriorates due to repeated full analysis
Solution Approach 1:
The system performs preliminary flow-insensitive analysis on the entire source code base before performing flow-sensitive analysis. This preliminary pass identifies all functions, their entry and exit points, and basic control flow characteristics. By preparing this foundational information in advance, subsequent flow-sensitive analyses on updated code versions can focus only on changed functions and their impact areas, dramatically reducing re-analysis time while maintaining comprehensive security vulnerability identification.
Solution Approach 2:
The system leverages feedback from previous SAST runs by comparing changes between source code versions. When code is modified, the system identifies which functions have changed and only performs detailed flow-sensitive analysis on those specific functions and their called functions. Results from previous analyses are reused where applicable, creating a feedback loop that maintains security reliability while improving development productivity through selective re-analysis.
Data Source
AI summary
A second version of source code of a program is analyzed in relation to a first version of the source code to identify: which alarm instructions of the second version require analysis to identify second security vulnerabilities in the second version, and which first security vulnerabilities identified in the first version remain in the second version. Static application security testing (SAST) is performed on the second version in relation to the alarm instructions that have been identified as requiring analysis, to identify the second security vulnerabilities. Each second security vulnerability pertains to one of the alarm instructions. The first security vulnerabilities identified as remaining in the second version are added to the second security vulnerabilities that have been identified.