HPE Security Fortify Static Code Analyzer Software Version: Performance Guide

Transcription

1 HPE Security Fortify Static Code Analyzer Software Version: Performance Guide Document Release Date: April 2016 Software Release Date: April 2016

2 Legal Notices Warranty The only warranties for Hewlett Packard Enterprise Development products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HPE shall not be liable for technical or editorial errors or omissions contained herein. The information contained herein is subject to change without notice. Restricted Rights Legend Confidential computer software. Valid license from HPE required for possession, use or copying. Consistent with FAR and , Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The software is restricted to use solely for the purpose of scanning software for security vulnerabilities that is (i) owned by you; (ii) for which you have a valid license to use; or (iii) with the explicit consent of the owner of the software to be scanned, and may not be used for any other purpose. You shall not install or use the software on any third party or shared (hosted) server without explicit consent from the third party. Copyright Notice Copyright Hewlett Packard Enterprise Development LP Trademark Notices Adobe is a trademark of Adobe Systems Incorporated. Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation. Documentation Updates The title page of this document contains the following identifying information: Software Version number Document Release Date, which changes each time the document is updated Software Release Date, which indicates the release date of this version of the software To check for recent updates or to verify that you are using the most recent edition of a document, go to: You will receive updated or new editions if you subscribe to the appropriate product support service. Contact your HPE sales representative for details. HPE Security Fortify Static Code Analyzer (16.10) Page 2 of 27

3 Contents Preface 5 Contacting HPE Security Fortify Support 5 For More Information 5 About the Documentation Set 5 Change Log 6 Chapter 1: Introduction 7 Hardware Recommendations 7 Sample Scans 8 Chapter 2: Tips on Improving Performance 9 Hardware Considerations 9 Software Considerations 9 Mobile Build Sessions 10 Memory Tuning 11 Java Heap Exhaustion 12 Java Permanent Generation Exhaustion 13 Native Heap Exhaustion 13 Stack Overflow 13 CPUs, Parallel Processing, and Multithreading 14 Keeping Tainted Information in Memory 14 Chapter 3: Scan Quality and Performance 15 Breaking Down Codebases 15 Limiters 15 Quick Scan 15 Using Quick Scan and Full Scan 16 Limiting Analyzers and Languages 16 Disabling Analyzers 16 Disabling Languages 17 Scanning Complex Functions 17 Chapter 4: Scan Size and Performance 18 Filters 18 HPE Security Fortify Static Code Analyzer (16.10) Page 3 of 27

4 Filter Files 18 Scan-Time Filters 18 Creating FPRs without Source Code 19 Opening Large FPRs 20 Audit Workbench 21 Chapter 5: Monitoring Long Running Scans 22 SCAState 22 JMX 22 HPROF and HAT 22 JConsole 23 Java VisualVM 23 Chapter 6: Function too Complex to Analyze Message 25 Dataflow Analyzer Limiters 25 Control Flow and Null Pointer Analyzer Limiters 26 Send Documentation Feedback 27 HPE Security Fortify Static Code Analyzer (16.10) Page 4 of 27

5 Preface Preface Contacting HPE Security Fortify Support If you have questions or comments about using this product, contact HPE Security Fortify Technical Support using one of the following options. To Manage Your Support Cases, Acquire Licenses, and Manage Your Account To Support To Call Support For More Information For more information about HPE Security software products: About the Documentation Set The HPE Security Fortify Software Security Center documentation set contains installation, user, and deployment guides for all HPE Security Fortify Software Security Center products and components. In addition, you will find technical notes and release notes that describe new features, known issues, and lastminute updates. You can access the latest versions of these documents from the following HPE Security user community website: You will need to register for an account. HPE Security Fortify Static Code Analyzer (16.10) Page 5 of 27

6 Change Log Change Log The following table lists changes made to this document. Revisions to this document are published between software releases only if the changes made affect product functionality. Software Release / Document Version Changes Updated: Minor edits 4.40 Updated: Minor edits 4.30 Added: Section "Sample Scans" to "Introduction" on page 7 HPE Security Fortify Static Code Analyzer (16.10) Page 6 of 27

7 Chapter 1: Introduction This document provides guidelines and tips for optimizing memory usage and performance when scanning different types of codebases with HPE Security Fortify Static Code Analyzer (SCA). Hardware Recommendations Source code varies a lot which makes accurate predictions of memory usage and scan times impossible. The factors that affect memory usage and performance consists of many different factors such as: Code type Size of the code base Ancillary languages used (such as JSP, JavaScript, HTML) Number of vulnerabilities Type of vulnerabilities (what analyzer is used) Complexity of the code base Of the above stated factors, code complexity is the most difficult to measure. This problem, especially when combined with the other factors demonstrates why this issue is so complex and non-deterministic. Because code complexity is so difficult to measure, we must rely on general guidelines, and anecdotal evidence to help shape a set of best guess recommendations for hardware requirements. This section provides a set of guidelines that we have developed through our findings from scanning real world applications and distilling down the requirements derived from performance needs. It is important to note that there might be cases where scanning your codebase requires more than our guidelines imply. In an effort to improve our guidelines, we welcome your feedback on how your project requirements map to our guidelines. For SCA with HPE Security Fortify Software Security Center version 4.x and later, the following table provides recommendations based on the complexity of the application. Application Complexity CPU Cores RAM (GB) Average Scan Time Notes Simple hour A system that runs on a server or desktop in a standalone manner like a batch job or a command line utility. Medium hours A standalone system, which works with complex computer models like a tax calculation system or a scheduling system. Complex days A three tiered business system with transactional data processing like a financial system or a commercial website. HPE Security Fortify Static Code Analyzer (16.10) Page 7 of 27

8 Chapter 1: Introduction Application Complexity CPU Cores RAM (GB) Average Scan Time Notes Very Complex days A system that serves up content like an application server, database server, or content management system. Note: Scanning JavaScript increases the analysis time significantly. If the total lines of code in an application is composed of more than 20% JavaScript, use the next highest recommendation. Sample Scans The following table shows the scan times you can expect for several common open-source projects. These test scans were performed using version of SCA on a dedicated Linux virtual machine with four CPUs and 32 GB of RAM. Project Name / Language Scan Time (Min:Sec) Total Issues (2015R4) Project Size (MB) WebGoat 5.0 (Java) 03: WordPress (Java) 04: phpbb 3 (PHP) 05: JBoss (Java) 39: Azureus (Java) 32: Asterisk (C/C++) 56: HPE Security Fortify Static Code Analyzer (16.10) Page 8 of 27

9 Chapter 2: Tips on Improving Performance This section contains different methods of tuning the HPE Security Fortify Static Code Analyzer to maximize its functionality. This section contains the following topics: Hardware Considerations 9 Software Considerations 9 Mobile Build Sessions 10 Memory Tuning 11 CPUs, Parallel Processing, and Multithreading 14 Keeping Tainted Information in Memory 14 Hardware Considerations While the Software Security Center system requirements are documented and mandatory, for complex and large programs SCA requires more capable hardware. This includes: Disk I/O SCA is I/O intensive so the faster the hard drive, the more savings on the I/O transaction. HPE recommends a 7,200 RPM drive, although a 10,000 RPM drive (such as the WD Raptor), or an SSD drive would be better. Another option is to use a RAM disk. In this case, save the project on the RAM disk. Also, change the property name com.fortify.sca.projectroot in <sca_install_dir>/core/config/fortify sca.properties to point to a directory located in the RAM disk. Memory The default setting is 1800 MB. However, larger applications require more RAM. See "Memory Tuning" on page 11 for more information on how to determine the amount of memory required for optimal performance. CPU HPE recommends a 2.1 GHz processor or faster Software Considerations Software Security Center can take a long time to process complex projects. The time can be spent in different stages: Translation Scan Audit/upload HPE Security Fortify Static Code Analyzer (16.10) Page 9 of 27

10 Chapter 2: Tips on Improving Performance This section provides tips on how to improve the performance so that you can complete a scan or manage the processing time in different stages that are taking too long. The following table provides a summary of the stages and the corresponding options that are the most effective. Stage Options Description More Information Translation -export-build-session Translating (and scanning) on different machines "Mobile Build Sessions" below Scan -Xmx<size>M -Xmx<size>G Additional RAM allocation "Memory Tuning" on the next page Scan -Xss<size>M -Xss<size>G Stack size allocation "Memory Tuning" on the next page Scan -j <processes> Number of processes when utilizing multi-processing "CPUs, Parallel Processing, and Multithreading" on page 14 Scan com.fortify.sca. RmiWorkerMaxHeap RAM allocation for individual processes when utilizing multiprocessing "CPUs, Parallel Processing, and Multithreading" on page 14 Scan com.fortify.sca. ThreadCount Hardcoded number of threads "CPUs, Parallel Processing, and Multithreading" on page 14 Scan com.fortify.sca. DisableSwapTaintProfile =True SCA keeps taint information in memory "Keeping Tainted Information in Memory" on page 14 Scan -bin Scan the files related to the given binary (for C/C++) "Breaking Down Codebases" on page 15 Scan -quick Quick scan "Quick Scan" on page 15 Scan -filter <filename> Applying filter by means of filter file "Filters" on page 18 Scan -disable-sourcebundling Do not include source files in FPR file "Creating FPRs without Source Code" on page 19 Mobile Build Sessions You can translate modules on different machines using the same Build ID. You can then scan everything together using the same Build ID on a different machine with better hardware. This can be done manually or by using Mobile Build Sessions (MBS) which allow a project to be translated on one computer and analyzed on another. MBS provide the advantage of performing the translation on the original computer and then moving the build session to a better equipped computer to perform the scan. The developers can run translations on their own computers and only one powerful computer is needed to run large scans. HPE Security Fortify Static Code Analyzer (16.10) Page 10 of 27

11 Chapter 2: Tips on Improving Performance We strongly recommend that you move MBS files using the export and import functions. The -exportbuild-session and -import-build-session options store and load the build session to and from a file specified on the command line. sourceanalyzer -b <Build ID> -export-build-session my-session.mbs sourceanalyzer -import-build-session my-session.mbs Below is an example of the steps required to use a mobile build session. Machine T is the computer where we perform the translation and Machine S is the computer where we apply the scan. The following commands need to be run on each machine. 1. Machine T: Translate. sourceanalyzer -b <Build ID> <Source Files> 2. Machine T: Package and export the mobile build into a file called build-session.mbs. sourceanalyzer -b <Build ID> -export-build-session build-session.mbs 3. Transfer build-session.mbs from Machine T to Machine S. 4. Machine S: Import the translation of the build folder into the SCA project root directory on the scan machine. sourceanalyzer -import-build-session build-session.mbs 5. Machine S: Perform a scan using the same Build ID used in the translation. sourceanalyzer -b <Build ID> -scan -f myresults.fpr Note: There is no support for merging multiple mobile build sessions into a single build session; each exported build session must use a unique Build ID and be imported under that unique Build ID. However, once all of the Build IDs are present in the same sourceanalyzer installation, they can be scanned as part of the same scan using multiple Build IDs with the b option, just as if they were all translated on the same machine as the scan. For example, assuming all the Build IDs were created locally, or imported to the local machine using mobile builds, you can use command similar to the following command. sourceanalyzer -b BuildID_1 -b BuildID_2 -b BuildID_3 -scan -f myresults.fpr While the resulting FPR (myresults.fpr) covers the same files as if we translated all of the files into one Build ID from the beginning, note that there are rare instances where dataflow between files might be lost if they are not translated together. Memory Tuning As discussed in "Introduction" on page 7, the amount of physical RAM required for a scan depends on the complexity of the code itself. As this is unknown until the first attempt to scan an application, you might encounter OutOfMemory errors during the analysis. HPE Security Fortify Static Code Analyzer (16.10) Page 11 of 27

12 Chapter 2: Tips on Improving Performance SCA OutOfMemory errors are classified as follows: Java Heap Exhaustion 12 Java Permanent Generation Exhaustion 13 Native Heap Exhaustion 13 Stack Overflow 13 Java Heap Exhaustion Java heap exhaustion is the most common memory problem during SCA scans and is the result of allocating too little heap space to the Java virtual machine used by SCA for the project being scanned. It can be identified by the following symptoms: Symptoms One or more of these messages appears in the SCA log file and in the command-line output: There is not enough memory available to complete analysis. For details on making more memory available, please consult the user manual. java.lang.outofmemoryerror: Java heap space java.lang.outofmemoryerror: GC overhead limit exceeded Resolution Resolving a Java heap exhaustion problem involves allocating more heap space to the SCA Java virtual machine when starting the scan. By default, SCA runs with a max heap value of 1800 MB. To increase this value, use the -Xmx command-line option when running the SCA scan. For example, -Xmx1G makes 1 GB available. Before adjusting this parameter, determine the maximum allowable value for Java heap space. The maximum value depends on two factors: Available physical memory Virtual address space limitations Each of these may limit the amount of Java heap that can be allocated to SCA. The lower of the two limiting values should be used as the upper bound for a -Xmx option. Physical Memory HPE recommends that the value of -Xmx should either not exceed 90% of the total physical memory or not exceed the total physical memory minus 1.5GB to allow for the operating system. If the system is to be dedicated to running SCA, you need not change it from here, however if the system resources are shared with other memory-intensive processes, an allowance should also be subtracted for those other processes. Note that other processes that are resident but not active while SCA is running can be swapped to disk by the operating system and do not need to be accounted for. Allocating more physical memory to SCA than is available in the environment might cause thrashing which likely slows the scan down along with everything else on the system. HPE Security Fortify Static Code Analyzer (16.10) Page 12 of 27

13 Chapter 2: Tips on Improving Performance Java Permanent Generation Exhaustion Java maintains a separate memory region from the main heap which is called the Permanent Generation. In some rare cases, this memory region might fill up during a scan, causing an OutOfMemoryError. Permanent generation exhaustion can be identified by the following error message: Symptoms This message typically appears in an SCA log file, but could also appear in the command-line output: java.lang.outofmemoryerror: PermGen space Resolution Permanent generation exhaustion is resolved by increasing the maximum size of the permanent generation. The permanent generation size can be tuned by passing the -XX:MaxPermSize option to SCA. For example -XX:MaxPermSize=128M. The default maximum value for the permanent generation if unspecified is 64 MB. Note that the permanent generation is allocated as a separate memory region from the Java heap, so increasing the permanent generation will increase the overall memory requirements for the process. See the discussion of virtual address space and physical memory limitations in the previous section for determining overall limits. Native Heap Exhaustion Native heap exhaustion is a very rare scenario in which the Java virtual machine is able to allocate the Java memory regions on startup, but is left with so few resources (either virtual address space or physical memory) for its native operations (such as garbage collection) that it eventually encounters a fatal memory allocation failure that immediately terminates the process. Symptoms Native heap exhaustion can be identified by abnormal termination of the SCA process with the following output on the command line: # A fatal error has been detected by the Java Runtime Environment: # # java.lang.outofmemoryerror: requested... bytes for GrET... Because this is a fatal Java virtual machine error, it is usually accompanied by an error log created in the working directory with the file name hs_err_pidnnn.log. Resolution Because the problem is a result of overcrowding within the process, the resolution is to reduce the amount of memory used for the Java memory regions (Java heap and Java permanent generation). Reducing either of these values should reduce the crowding problem and allow the scan to complete successfully. Stack Overflow Each thread in a Java application has its own stack. The stack holds return addresses, function/method call arguments, and so on. If a thread tends to process large structures with recursive algorithms, it might need a large stack for all those return addresses. With the Sun JVM, you can set that size with the -Xss option. HPE Security Fortify Static Code Analyzer (16.10) Page 13 of 27

14 Chapter 2: Tips on Improving Performance Symptoms This message typically appears in the SCA log file, but might also appear in the command-line output: java.lang.stackoverflowerror Resolution The default stack size is 1 MB. Increase the stack size by passing the -Xss option to the sourceanalyzer command. For example, -Xss8M increases the stack to 8 MB and -Xss16M to 16 MB. CPUs, Parallel Processing, and Multithreading Multithreaded execution is implemented during: Pre-analysis Where data structures used by the analyzers are constructed Post-analysis Where whole-program analysis are conducted and the final issues are generated FPR generation: where the source is bundled and the issues are written to the FPR file You can trigger parallel processing during the main analysis stage; during the running of the SCA analyzers. Parallel processing allows you to reduce scan times by harnessing multiple cores, memory, and processing power in your machine. For more information on how to use the parallel analysis, see the HPE Security Fortify Static Code Analyzer User Guide. Keeping Tainted Information in Memory To save memory, SCA saves the tainted information to disk and swaps the information when needed. You can set a flag to keep tainted information in memory by adding the following setting into <sca_install_ dir>/core/config/fortify-sca.properties: com.fortify.sca.disableswaptaintprofiles=true Alternatively, you can pass the -Dcom.fortify.sca.DisableSwapTaintProfiles=true option with the -scan option. This causes SCA to keep all the data in memory. For example, one scan took 33 hours to complete, and after setting this property, the scan time was reduced to 13 hours. This comes at a cost of higher memory usage. If SCA has enough memory available then this option improves the scan time. Otherwise, it might cause the analysis to run out of memory and produce no results. HPE Security Fortify Static Code Analyzer (16.10) Page 14 of 27

15 Chapter 3: Scan Quality and Performance This section contains the following topics: Breaking Down Codebases 15 Limiters 15 Limiting Analyzers and Languages 16 Scanning Complex Functions 17 Breaking Down Codebases It is more efficient to break down large projects into independent modules. For example, if you have a portal application that consists of several modules that are independent of each other or have very little interactions, you can translate and scan the modules separately. The caveat to this is that dataflow might be lost if some interactions do occur. For C/C++, you might be able to reduce the scan time by using the bin option in conjunction with scan. You need to pass the binary file to it (such as -bin <filename>.exe -scan or -bin <filename>.dll -scan), and SCA finds the related files associated with the binary and scans them. This is useful when you have several binaries in a Make file. bin Specifies a subset of source files to scan. Only the source files that were linked in the named binary at build time are included in the scan. show binaries Displays the independent binaries. show-build-tree Displays all files used to create binary and all files used to create those files in a tree layout. Limiters The depth of the analysis SCA performs sometimes depends on the available resources. SCA uses a complexity metric to trade off these resources with the number of vulnerabilities that can be found. Sometimes, this means giving up on a particular function when it does not look like SCA has enough resources available. SCA allows the user to control the cut off point by using SCA properties called limiters. The different analyzers have different limiters. You can run a predefined set of these limiters using a Quick Scan. See the quick scan properties in the HPE Security Fortify Static Code Analyzer User Guide for description of the full set of limiters. Quick Scan Quick Scan Mode provides a way to quickly scan your projects for major defects. When using Quick Scan Mode, you should be aware that although the scan is significantly quicker, it does not provide a robust result set. To turn on quick scan, use -quick option with -scan. HPE Security Fortify Static Code Analyzer (16.10) Page 15 of 27

16 Chapter 3: Scan Quality and Performance When Quick Scan Mode is enabled, SCA applies the properties from the <sca_install_ dir>/core/config/fortify-sca-quickscan.properties file, in addition to the standard <sca_install_ dir>/core/config/fortify-sca.properties file. By default, this scan searches for high confidence, high severity issues. You can alter the limiters used by SCA by editing the fortify-scaquickscan.properties file. If this file is empty, then the quick scan is identical to the full scan. In general, modifying fortify-sca.properties also affects quick scan behavior. HPE Security recommends doing performance tuning on quick scan, and leaving the full scan in the default settings to produce a highly accurate scan. Using Quick Scan and Full Scan Run periodic full scans When choosing to use quick scans, a periodic full scan is important as it may find issues not detected by the Quick Scan. A full scan should be run at least once per software iteration. If possible, a full scan should be run periodically when it will not interrupt workflow, such as on a weekend. Compare Quick Scan With a Full Scan To evaluate the accuracy impact of a Quick Scan, perform a quick scan and a full scan on the same code base, then load the quick scan results in Audit Workbench and merge it into the full scan. Group the issues by New Issue to produce a list of issues found in the full scan but not found in the quick scan. Quick Scans and SSC Server To avoid overwriting the results of a full scan, by default SSC does not accept FPR files scanned using Quick Scan. However, you can configure processing rules in SSC for an application version so that FPR files scanned with Quick Scan are not blocked. For more information, see the HPE Security Fortify Software Security Center User Guide. Limiting Analyzers and Languages Occasionally, you might find that a significant amount of the scan time is spent either running one particular analyzer or analyzing a particular language. It is also possible that this particular analyzer or language is not of great interest to your security requirements. You can limit the specific analyzers that run and the specific languages that are translated. Disabling Analyzers To disable specific analyzers, include the -analyzers option to SCA at scan time with a semicolon- or comma-separated list of analyzers you want to enable. The full list of analyzers is: buffer, content, configuration, controlflow, dataflow, findbugs, nullptr, semantic, and structural. To run a scan using only the dataflow, controlflow, and buffer analyzers, use the following scan command: sourceanalyzer -b <Build ID> -analyzers dataflow:controlflow:buffer -scan -f myresults.fpr You can also do the same thing by setting com.fortify.sca.defaultanalyzers in the SCA property file <sca_install_dir>/core/config/fortify-sca.properties. For example, the equivalent of the previous scan command is the following properties file setting: com.fortify.sca.defaultanalyzers=dataflow:controlflow:buffer Note: Separate the analyzers with a semicolon in Windows and with colon on all other platforms. HPE Security Fortify Static Code Analyzer (16.10) Page 16 of 27

17 Chapter 3: Scan Quality and Performance Disabling Languages To disable specific languages, include the -disable-language option in the translation phase. This is followed by a semicolon- or comma-separated list of languages that you want to disable. The full list of language options is: actionscript, c, cpp, plsql, tsql, any_sql, jsp, csharp, vb, cfml, html, java, javascript, php, asp, vbscript, vb6, cobol, python, abap, objc, llvm, swift To run a scan that excludes all SQL and HTML files, use the following command to perform the translation: sourceanalyzer -b <Build ID> <Translation Files> -disable-languages any_sql:html You can also disable languages by setting the com.fortify.sca.disabledlanguages property in the SCA properties file <sca_install_dir>/core/config/fortify-sca.properties. For example, the equivalent of the previous scan command is the following properties file setting: com.fortify.sca.disabledlanguages=any_sql:html Note: Separate multiple languages with a semicolon in Windows and with colon on all other platforms. Scanning Complex Functions While performing a scan using SCA, the data flow analyzer might encounter a function for which it cannot complete the analysis and reports the following message: Function <name> is too complex for <analyzer> analysis and will be skipped (<identifier>) To see a discussion of a resolution to this issue, see "Function too Complex to Analyze Message" on page 25. HPE Security Fortify Static Code Analyzer (16.10) Page 17 of 27

18 Chapter 4: Scan Size and Performance This section contains the following topics: Filters 18 Creating FPRs without Source Code 19 Opening Large FPRs 20 Filters Filters are usually part of the issue template and determine how the results from SCA are shown. For example, you can have a filter to put SQL Injection issues found into a separate folder called SQL Injections, or you might have a filter so that issues with a confidence below a certain threshold are hidden from the user. Along with filters, filter sets enable you to have a selection of filters used at any one time. This enables you to more easily customize your view and allows you to define a different view for developers, auditors, and managers so that they can more easily see the most important or relevant information for them. Each FPR has an issue template associated with it, and in SSC these are specified on an application version basis. For further information about issue templates and customizing them, see the HPE Security Fortify Audit Workbench User Guide. Filter Files Filter files are flat files that you can specify along with a scan using -filter <filter file name>. This is then used as a blacklist of Category IDs, Instance IDs and/or Rule IDs. This means that if you determine that a certain category of issues or rules are not relevant for this particular scan, you can stop them from flagging any issues that would go into the resulting FPR. This can be used to decrease the size of a results file along with the time it takes to scan a particular code base. For example, if the scan is on a simple program that just reads a file specified, you might not want to see issues showing path manipulation issues, since these would likely be planned as part of the functionality. To do this, you can create a new file containing a single line: Path Manipulation Then after saving this file as filter.txt, during the scan include the -filter option as in the following example: sourceanalyzer -b <Build ID> -scan -f myresults.fpr -filter filter.txt The newly created myresults.fpr does not include any issues with the category Path Manipulation. Scan-Time Filters An alternate way to filter at scan-time is by using filter sets to narrow down specifically what you want using the filters within an issue template. These scan-time filters can dramatically reduce the size of an FPR. HPE Security Fortify Static Code Analyzer (16.10) Page 18 of 27

19 Chapter 4: Scan Size and Performance To do this, create a set of filters as usual in a new filter set. For example, if you use the OWASP Top , but you do not want to see any issues not categorized within this standard, then you could create a filter in Audit Workbench such as: If [OWASP Top ] does not contain A Then hide issue What this does is look through the issues and if it does not map to an OWASP Top category with A in the name, then it hides it. Due to the fact that all OWASP Top categories start with A (A1, A2,, A10), it means that any category without the letter A must not be in the OWASP Top This hides them, but they are still in the FPR. If you set this within a new filter set called OWASP_Filter_Set, and then export the issue template to a file IssueTemplate.xml, you can specify this at scan-time with the following command: sourceanalyzer -b <Build ID> -scan -f myscantimefilterresults.fpr -project-template IssueTemplate.xml -Dcom.fortify.sca.FilterSet=OWASP_Filter_set This uses the issue template file IssueTemplate.xml to determine how the results are represented, and -Dcom.fortify.sca.FilterSet is a property that tells SCA to use this filter set. Any filters that hide issues from a user s view normally are instead removed so that they are not written to the FPR. Therefore, this can be used to reduce the number of issues shown, making a scan very targeted and reduce the size of the resulting FPR file. Note that although this can reduce the size of the FPR, it will not usually reduce the scan time, as scan-time filters are looked at after the issues have been calculated to decide whether to write them to the FPR or not. Whereas the filters used from a filter file are used to determine the types of rules that should be loaded. Creating FPRs without Source Code Writing the source code into the FPR can be I/O intensive and can be part of the reason for large FPR files if the code base is large. By not saving the source code information into the FPR, the scan can be faster, especially when the files are of large size. The saved time is not significant for smaller files or smaller code bases. To disable source code being bundled into the FPR file: Within the <sca_install_dir>/core/config/fortify-sca.properties file, set com.fortify.sca.fprdisablesourcebundling=true. Alternatively this can be specified at scan-time with the option -disable-source-bundling. In addition to this you can also disable code snippets from being written to the FPR by setting the property com.fortify.sca.fvdldisablesnippets=true, which may be specified at scan time with the option fvdl-no-snippets. This can also save the I/O time, depending on the size of the program and is useful if you have security requirements that state that no source should be included within these files. The latter can also be specified at scan-time, an example of using both is: sourceanalyzer -b <Build ID> -disable-source-bundling -fvdl-no-snippets -scan -f mysourcelessresults.fpr Note that references to the code are still in use within the FPR, so if you are testing this on a single machine, the source code location might have to be changed so that it is not automatically picked up by Audit Workbench when trying to view the results. This does not place the source code back into the FPR however, and is just functionality within Audit Workbench to clearly see the full source for auditing purposes. HPE Security Fortify Static Code Analyzer (16.10) Page 19 of 27

20 Chapter 4: Scan Size and Performance Opening Large FPRs There are a few ways to open large FPRs. The first way to do this is by making the results file smaller in the first place so that it is not necessary to change other settings. The quickest way to do this without affecting results is to disable the source from the being presented in the FPR as shown in "Creating FPRs without Source Code" on the previous page. Alternatively, there are a few more options and properties that you can use to fine tune what is not included in the FPR. You can set these properties in the SCA properties file: <sca_install_ dir>/core/config/fortify-sca.properties, or during the scan with -D<Property name>=true. Most of these options also have associated command-line option. Set in fortify-sca.properties File com.fortify.sca.fprdisablemetatable=true Command-line option: -disable-metatable This disables the metatable inside the FPR. This is used for mapping information to be able to find for example where a function is declared. This is used heavily by the Functions view in Audit Workbench. com.fortify.sca.fvdldisabledescriptions=true Command-line option: -fvdl-no-description This excludes descriptions from the analysis results file. If you are not using custom descriptions, descriptions are the same as the description listed in the HPE Security Fortify Taxonomy ( com.fortify.sca.fvdldisableenginedata=true Command-line option: -fvdl-no-enginedata This disables the Analysis Information inside the FPR. This is useful if your FPR contains such a large number of warnings that Audit Workbench is encountering when opening the file. The caveat of this option is that you need to merge the FPR with the current Project File locally before uploading to Software Security Center. Because the FPR does not contain the SCA version, SSC is unable to merge it on the server. com.fortify.sca.fvdldisableprogramdata Command-line option: -fvdl-no-progdata This excludes the program data section from the analysis results. This removes the Taint Sources information from the Functions tab in Audit Workbench. This property typically only has a minimal effect on the overall size of the FPR file. HPE Security Fortify Static Code Analyzer (16.10) Page 20 of 27

21 Chapter 4: Scan Size and Performance Audit Workbench There are also some specific properties that you can set in the <sca_install_ dir>/core/config/fortify.properties configuration file. These are described in the following table. Set in fortify.properties File com.fortify.disableprograminfo=true com.fortify. model.issuecutoffstartindex=<num> (inclusive) com.fortify. model.issuecutoffendindex=<num> (exclusive) This disables use of the code navigation features in Audit Workbench. The IssueCutOffStartIndex property is inclusive and IssueCutOffEndIndex is exclusive so that you can specify a subset of issues you want to see. For example, to see the first 100 issues, you can specify: com.fortify.model. IssueCutOffStartIndex=0 com.fortify.model. IssueCutOffEndIndex=101 Because the IssueCutOffStartIndex is 0 by default, you do not need to specify this property. com.fortify. model.issuecutoffbycategorystartindex=< num> (inclusive) com.fortify. model.issuecutoffbycategoryendindex=< num> (exclusive) These are similar to the above properties except these are specified for every category. For example. if you want to see the first five issues for every category you would specify: com.fortify.model. IssueCutOffByCategoryEndIndex=6 com.fortify. RestrictIssueLoading=true This restricts the data that is held in memory, but might cause poor performance. com.fortify. model.minimalload=true com.fortify. model.maxengineerrorcount=<num> This minimizes the data loaded in the FPR. This also restricts usage of the Functions view and might prevent the source being loaded from the FPR. This property limits the number of errors loaded with the FPR. For projects with a large number of scan warnings, this can significantly reduce both load time in Audit Workbench and the amount of memory required to open the FPR. HPE Security Fortify Static Code Analyzer (16.10) Page 21 of 27

22 Chapter 5: Monitoring Long Running Scans When running SCA, large and complex scans can often take a significant amount of time to complete. During the scan it is not always clear what is happening and if SCA is doing anything. In situations such as this, while we recommend you provide your debug logs to the HPE Security Fortify Technical Support team, there are a couple of ways to see in real time what SCA is doing and how it is performing. This section contains the following topics: SCAState 22 JMX 22 SCAState The SCAState tool is located in the <sca_install_dir>/bin directory. This tool provides a live view of the analysis. It also provides a set of timers and counters that show where SCA has spent its time during the scan. For more information about running SCAState, see the HPE Security Fortify Static Code Analyzer User Guide. JMX You can use a variety of tools to monitor SCA with JMX. These tools have a variety of advantages and disadvantages, however the GUI based tools specifically can offer a means to track SCA performance over time. Note: These are third party tools and are not provided or supported by HPE Security. HPROF and HAT The most straight forward tools to use are the Heap/CPU Profiling Tool (HPROF) and the Heap Analysis Tool (HAT). These two tools work together. HPROF is a simple command-line tool for heap and CPU profiling. It is a JVM native agent library which is dynamically loaded through a command-line option, at JVM startup, and becomes part of the JVM process. By supplying HPROF options at startup, you can request various types of heap and/or CPU profiling features from HPROF. The data generated can be in text or binary format, and can be used to track down and isolate performance problems involving memory usage and inefficient code. You can call HPROF when the scan is initiated with: sourceanalyzer -b <build_id> -scan -f myresults.fpr -Xrunhprof:cpu=samples,interval=1,depth=10,format=b, file=java.hprof.bin,heap=dump For all the possible command-line options, see the full Oracle documentation available at: HPE Security Fortify Static Code Analyzer (16.10) Page 22 of 27

23 Chapter 5: Monitoring Long Running Scans You can use the binary file format output from HPROF with tools such as HAT to browse the allocated objects in the heap. HAT parses a Java heap dump file and launches a web server. By default this web server listens on port To call HAT, you use a command such as the following: jhat -J-Xmx4G./java.hprof.bin For more information on HAT, see the full Oracle documentation available at: Using the --openfile option, the binary output from HPROF can also be viewed with "JConsole" below or "Java VisualVM" below. The disadvantages of using HPROF are: The statistics are only reported once the process is complete. You must use a text editor or HAT to view the results. You cannot use it remotely. It can only run on the system running the application. JConsole JConsole is an interactive, real-time monitoring tool which complies with the JMX specification. It uses the extensive instrumentation of the JVM to provide information about the performance and resource consumption of applications running on the Java platform. The disadvantage of JConsole is that you cannot save the output. To use JConsole, you must first set some additional JVM parameters. This is done by setting the following environment variable: export SCA_VM_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false" For more information about these parameters, see the full Oracle documentation available at: After the JMX parameters have been set, start an SCA scan as usual. After the scan is running, start JConsole to monitor SCA locally or remotely with the following command: jconsole <HostName>:9090 Java VisualVM Java VisualVM offers the same capabilities as JConsole. It also provides more detailed information on the JVM and allows you to save the monitor information to an application snapshot file. You can store these files and open them later with Java VisualVM. As with JConsole, before you can use Java VisualVM, you need to set the same JVM parameters as detailed in "JConsole" above. HPE Security Fortify Static Code Analyzer (16.10) Page 23 of 27

24 Chapter 5: Monitoring Long Running Scans Once the parameters have been set, start the scan as usual. You can then start Java VisualVM to monitor the scan either locally or remotely with the following command: jvisualvm <HostName>:9090 For more information about Java VisualVM, see the full Oracle documentation available at: HPE Security Fortify Static Code Analyzer (16.10) Page 24 of 27

25 Chapter 6: Function too Complex to Analyze Message While performing a scan using SCA, the data flow analyzer might encounter a function for which it cannot complete the analysis and reports the following message: Function <name> is too complex for <analyzer> analysis and will be skipped (<identifier>) where: <name> is the name of the source code function <analyzer> is the name of the SCA analyzer <identifier> is the type of complexity which is one of the following: l: Too many distinct locations m: Out of memory s: Stack size too small t: Analysis taking too much time The depth of analysis SCA performs sometimes depends on the available resources. SCA uses a complexity metric to tradeoff these resources against the number of vulnerabilities that can be found. Sometimes, this means giving up on a particular function when it does not look like SCA has enough resources available. This is normally when you see the "Function too complex" messages. When this message is displayed, it does not necessarily mean the function in the program has been completely ignored. For example, the Dataflow Analyzer typically visits a function many times before analysis is complete, and might not run into this complexity limit in the early visits (since its model of other functions is less developed). In this case, anything learned from the early visits is reflected in the results. You can control the "give up" point using some HPE Security Fortify Static Code Analyzer properties called limiters. Different analyzers have different limiters. Dataflow Analyzer Limiters There are three types of complexity identifiers for dataflow analyzers: l: Too many distinct locations m: Out of memory s: Stack size too small To resolve the issue for identifiers m and s, you can increase the memory allocation or stack size for SCA by using -Xmx or -Xss respectively. By default, SCA uses 1800 MB for -Xmx and 1 M for -Xss. HPE Security Fortify Static Code Analyzer (16.10) Page 25 of 27

26 Chapter 6: Function too Complex to Analyze Message The issue identified by l is a little more complicated. The three following limiters are involved: com.fortify.sca.limiters.maxtaintdefforvar, default 1000 com.fortify.sca.limiters.maxtaintdefforvarabort, default 4000 com.fortify.sca.limiters.maxfielddepth, default 4 The MaxTaintDefForVar limiter is a dimensionless value expressing the complexity of a function, while MaxTaintDefForVarAbort is the upper bound for it. The MaxFieldDepth limiter is used to measure the precision when dataflow analyzer analyzes any give object. SCA would always try to analyze objects at the highest precision possible. If a given function exceeds the MaxTaintDefForVar limit at a given level of precision, the Dataflow Analyzer analyzes that function with a lower level of precision (by reducing the MaxFieldDepth limiter). Reducing the precision reduces the complexity of the analysis. When the precision cannot be reduced any further, SCA then proceeds with analysis at the lowest precision level until either it finishes or the complexity exceeds the MaxTaintDefForVarAbort limiter. In other words, SCA tries harder at the lowest precision level than at higher precision levels, in order to get at least some results from the function. If SCA reaches the MaxTaintDefForVarAbort limiter, though, it gives up on the function entirely, thus the "Function too complex" warning. Control Flow and Null Pointer Analyzer Limiters There are two types of complexity identifiers for both Control Flow and Null Pointer analyzers: m: Out of memory t: Analysis taking too much time Due to the way Dataflow Analyzer handles function complexity, it does not take indefinite amount of time. Control flow and Null Pointer analyzers, however, can take a very long time when analyzing very complex functions. Therefore, SCA requires a way to abort the analysis when this happens, and then you get the "Function too complex" message with a complexity identifier of t. To change these times, you can use the following parameters: com.fortify.sca.ctrlflowmaxfunctiontime, default 10 minutes ( milliseconds) com.fortify.sca.nullptrmaxfunctiontime, default 5 minutes ( milliseconds) To resolve the complexity identifier of m, increase the memory allocation for SCA. Note: Increasing these limiters or time settings makes the analysis of complex functions take longer. It is hard to characterize the exact performance implications of a particular value for the limiters/time, because it depends on the specific function in question. If you never want see the "Function too complex" warning, you can set the limiters/time to an infeasible high value in fortify-sca.properties or on the command line, but this is likely to cause unacceptable performance degradation. HPE Security Fortify Static Code Analyzer (16.10) Page 26 of 27

27 Send Documentation Feedback If you have comments about this document, you can contact the documentation team by . If an client is configured on this system, click the link above and an window opens with the following information in the subject line: Feedback on Performance Guide (Fortify Static Code Analyzer 16.10) Just add your feedback to the and click send. If no client is available, copy the information above to a new message in a web mail client, and send your feedback to HPFortifyTechPubs@hpe.com. We appreciate your feedback! HPE Security Fortify Static Code Analyzer (16.10) Page 27 of 27