RIPS is the fasted SAST tool on the market and needs only minutes instead of hours or days to finish its scans. Still, it transforms all your source code files into a graph model and analyzes all possible code paths for vulnerabilities which eats time and memory. Specifically for continuous integration setups time is critical and there are a couple options you can try to further improve the performance of your local RIPS installation.
When many security issues are detected a significant amount of analysis time is used to add all these issues to the database. This process is handled by consumer containers in parallel and by default 2 containers are running.
In order to add issues faster and gain analysis speed, you can increase the number of consumer containers by using the RIPS installer tool with the following command:
The optimal amount of consumers depends primarily on the number of CPU cores and the amount of elements on the queue, thus it is recommended to have a value close to the number of CPU cores.
Reduce Issue Types
As discussed in the previous section, the more issues are found the longer the analysis lasts. Not only for adding the detected issue but of course also for the actual taint analysis of the security-sensitive operation.
If there are specific vulnerability types that you feel are not relevant to your analysis you can exclude these types in the advanced scan settings or in your analysis profile so that their analysis is not triggered by RIPS.
You can also limit the maximum number of issues per type that should be reported. RIPS will then stop, for example, at 100 XSS issues to analyze for further XSS issues in the code to save performance.
RIPS analyzes only PHP/Java files in your code repository but it is necessary to include all relevant components for your application to follow all possible code paths.
There are, however, libraries and components that you can exclude from your scans in order to reduce the analysis time, the number of non-relevant issue reports, and the memory consumption.
What can I exclude?
Indicators of such libraries or components that can be excluded are:
- The code does not introduce new user input to the code base, nor does it process user input further used in other code
- Third-party code that is decoupled from your custom code and adds only an additional feature not relevant for your security testing (e.g. a PDF export library)
- The code is part of a popular framework that is already understood by RIPS
- The code is not actually used in production (e.g. test cases and related libraries)
How can I exclude it?
You can also choose to only exclude security and quality findings in your vendor code, but to still include it into the data flow analysis (recommended).
In case this impacts the change threshold of your previously scanned code you can deactivate the option "Compare full code" in the advanced scan settings which will then exclude your ignored file paths from comparison.
Reduce Analysis Depth
You can reduce the analysis depth that RIPS uses when following a long code path in your code to look for vulnerabilities.
This can lead to the miss of deeply nested vulnerabilities. If your code is very well structured and only a few long code paths exists, the effect can be minimal.