Fortify Flashcards
HP Fortify SCA has 6 analyzers: data flow, control flow, semantic, structural, configuration, and buffer. Each analyzer finds different types of vulnerabilities.
Data Flow This analyzer detects potential vulnerabilities that involve tainted data (user-controlled input) put to potentially dangerous use. The data flow analyzer uses global, inter-procedural taint propagation analysis to detect the flow of data between a source (site of user input) and a sink (dangerous function call or operation). For example, the data flow analyzer detects whether a user-controlled input string of unbounded length is being copied into a statically sized buffer, and detects whether a user controlled string is being used to construct SQL query text. Control Flow This analyzer detects potentially dangerous sequences of operations. By analyzing control flow paths in a program, the control flow analyzer determines whether a set of operations are executed in a certain order. For example, the control flow analyzer detects time of check/time of use issues and uninitialized variables, and checks whether utilities, such as XML readers, are configured properly before being used. Structural This detects potentially dangerous flaws in the structure or definition of the program. For example, the structural analyzer detects assignment to member variables in Java servlets, identifies the use of loggers that are not declared static final, and flags instances of dead code that will never be executed because of a predicate that is always false. Semantic This analyzer detects potentially dangerous uses of functions and APIs at the intra-procedural level. Basically a smart GREP. Configuration This analyzer searches for mistakes, weaknesses, and policy violations in an application’s deployment configuration files. Buffer This analyzer detects buffer overflow vulnerabilities that involve writing or reading more data than a buffer can hold.
Other Fortify steps
Your source code is translated into an intermediate model, which is optimized for analysis by SCA. Some types of code require multiple stages of translation. For instance, a C# file needs first to be compiled into a debug .DLL or .EXE, and then that .NET binary file disassembled into Microsoft Intermediate Language (MSIL) by the .NET SDK utility ildasm.exe. Whereas other files like a Java file or ASP file are translated in one pass by the appropriate Fortify SCA translator for that language. SCA loads the model into memory and loads the analyzers. Each analyzer loads rules and applies those roles to functions in your program model, in a coordinated manner. The matches are written into an FPR file, with the vulnerability match information, security advice, source code, source cross-reference and code navigation information, user filtering specification, any custom rules, and digital signatures all zipped into the package.
Fortify Source Code Analyser
Fortify Source Code Analyzer (SCA) is a set of software security analyzers that search for violations of security‐specific coding rules and guidelines in a variety of languages. • The rich data provided by Fortify SCA language technology enables the analyzers to pinpoint and prioritize violations so that fixes can be fast and accurate. • The analysis information produced by SCA helps you deliver more secure software, as well as making security code reviews more efficient, consistent, and complete.
Using Fortify
At the highest level, using Fortify SCA involves: • Choosing to run SCA as a stand‐alone process or integrating Fortify SCA as part of the build tool • Translating the source code into an intermediate translated format, preparing the code base for scanning by the different analyzers • Scanning the translated code, producing security vulnerability reports • Auditing the results of the scan, either by transferring the resulting FPR file to Audit Workbench or Fortify 360 Server for analysis, or directly with the results displayed onscreen
Analyzers
Data Flow: The data flow analyzer detects potential vulnerabilities that involve tainted data (user‐controlled input) put to potentially dangerous use. Eg. Buffer overflow, SQL Injections. • Control Flow: The control flow analyzer detects potentially dangerous sequences of operations. Eg. time of check/time of use issues and uninitialized variables. • Semantic: The semantic analyzer detects potentially dangerous uses of functions and APIs at the intra‐procedural level. Eg. Deprecated functions, unsafe functions. • Structural: The structural analyzer detects potentially dangerous flaws in the structure or definition of the program. For Eg. Dead Code. • Configuration: The configuration analyzer searches for mistakes, weaknesses, and policy violations in an application’s deployment configuration files.
Analysis Phases
• Fortify SCA performs source code analysis • Build Integration: The first phase of source code analysis involves making a decision whether to integrate SCA into the build compiler system. • Translation: Source code gathered using a series of commands is translated into an intermediate format which is associated with a build ID. The build ID is usually the name of the project being scanned. • Analysis: Source files identified during the translation phase are scanned and an analysis results file, typically in the Fortify project (FPR) format, is generated. FPR files are indicated by the .fpr file extension. • Verification of the translation and analysis: Ensure that the source files were scanned using the correct rulepacks and that no significant errors were reported.
Analysis Commands
The following is an example of the sequence of commands you use to analyze code: • Clean and build sourceanalyzer -b -clean • Translation sourceanalyzer -b … •Scan sourceanalyzer -b -scan -f results.fpr
Translation Options
Output Options: • -append : Appends results to the file specified with -f. If this option is not specified, Fortify SCA adds the new findings to the FPR file, and labels the older result as previous findings. • -build-label : The label of the project being scanned. • -build-project : The name of the project being scanned. • -build-version : The version of the project being scanned. • -f : The file to which results are written. • -format : Controls the output format. Valid options are fpr, fvdl, text, and auto. • -html-report : Creates an HTML summary of the results produced.
Translation Options
Analysis Options: • -disable-default-ruletype : Disables all rules of the specified type in the default rulepacks. • -encoding : Specifies the encoding for encoded source files. • -filter : Specifies a results filter file. • -findbugs : Enables FindBugs analysis for Java code. • -quick : Scans the project in Quick Scan Mode. • -rules [|] : Specifies a custom rulepack or directory. • -disable-source-rendering : Source files are not included in the FPR file. • -scan : Causes Fortify SCA to perform analysis for the specified build ID.
Translation Options
Build Integration Options • -b : Specifies the build ID. • -bin : Used with -scan to specify 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. • -exclude : Removes files from the list of files to translate. For example: sourceanalyzer –cp “**/*.jar” “**/*” -exclude “**/Test.java“ • -nc : When specified before a compiler command line.
Translation Options
Runtime Options • -auth-silent : Available on Fortify SCA Per Use edition only. Suppresses the prompt that displays the number of lines the scan requires to analyze the source code. • -64 : Runs Fortify SCA under the 64‐bit JRE. • -logfile : Specifies the log file that is produced by Fortify SCA. • -quiet : Disables the command line progress bar. • -verbose : Sends verbose status messages to the console. • -Xmx : Specifies the maximum amount of memory used by Fortify SCA.
Fortify on Demand Step 1: Initiate
Create and customize applications. Choose your desired assessment type. Upload source code, byte code or binaries, or provide URL of target application.
Step 2: Assess
Micro Focus security professionals perform an assessment and verify results. Verifiable false-positives are removed from the system before results are published with a star-rating and assessment against pass/fail criteria. Lightning-fast turnaround time (typically a few hours) depending upon assessment level and type.
Step 3: Report
Communicate relevant metrics, filtering by severity, vulnerability category, business unit, region or other company data. Quickly show identified critical vulnerabilities, applications at highest risk and trending history.
Step 4: Remediate
Click on the application name to get up-to-date audit information: scan owner, analysis type and any notes. Drill down even further for stack trace, line of code details, request/response and remediation recommendations. Manage and assign remediation tasks through the portal.
