Configuring a Project Analysis

The Rule Set Associations section allows you to select the Rule Set that will be used to correlate similar tool results into Findings.

Three options are available:

• Don't use any rules
• SRM rules
• Clone of SRM rules

By default, new projects will use the built-in "Software Risk Manager Rules" set. The "Don't use any Rules" option is available if you don't want tool results to be mapped to rules. More information on Rule Sets can be found in the Rule Sets section of this guide.

Users with the admin role can use this section to manage Rule Sets by creating, cloning, or deleting them.

Click the dropdown configuration icon to open, copy, or delete the Rule Set.

Adding a Rule Set using the Add button will initialize a blank Rule Set.

A cloned Rule Set will be initialized as a copy of the "parent" set. This can be useful if you want one project to use mostly the same correlation logic, but with a few alterations from another project. Note that the default Software Risk Manager Rules set is read-only.

To make modifications to a rule set, you need to create a clone first. Click the dropdown configuration icon and select Copy to create a clone, then make modifications to the clone.

To view or modify an existing Rule Set, click the dropdown configuration icon and select Open.

Reminder: When making changes in the Analysis Configuration window, make sure to click OK to save any changes.

Reminder 2: Since a project's configured Rule Set determines the manner in which results are correlated, changing that configuration necessitates an update of the correlation. This happens when the configured Rule Set for a project is modified in any way, or if the Analysis Configuration is changed to use a different Rule Set. When this happens, the Findings page will display a notification prompting users to do so.

Host Scopes are sets of projects that share host information with each other. They allow the Host Normalization process to determine which hosts are actually the same hosts within a Host Scope. Selecting any of the Host Scopes in the associations list will associate the current project with that Host Scope, which implies that the current project's host information belongs to the selected Host Scope. Click the Manage Host Scopes link to open the Hosts page.

When a zip-like file (e.g. Zip, Jar, War, etc) is uploaded to a Software Risk Manager project, that project's Zip Content Exclusion Rules and Zip Content Identification Rules determine how entries in that zip file (and possibly entries in other zip-like files nested within the main zip file) will be treated by bundled tools using that file as input.

Exclusion Rules determine which zip entries will be ignored by bundled tools.

Identification Rules determine the perceived source of the zip entries, as either "library code" or "custom code" (third-party or first-party, respectively). Many tools will only be interested in custom code, and others (like component analysis tools) will only be interested in library code.

Proper configuration of these rules can drastically reduce the number of unwanted findings, for example, by avoiding analyzing files from a third-party library whose code you cannot directly modify.

By default, all entries in a zip-like file will be included, and their role (library code or custom code) will be automatically guessed by Software Risk Manager.

The two Zip Content Rule sections in the Analysis Configuration window share a common format. Each row represents a rule, where files matching that rule's pattern will be subject to the decision chosen from its respective dropdown menu. Later rules (further down the list) take precedence over earlier rules. The first rule will always use ** as its pattern, since it is the fallback for all zip entries. Its pattern may not be changed, but its decision may be changed. The patterns must be Glob Patterns, e.g., **.java matches any .java file in any folder. Patterns should use forward slashes (/) to denote directories instead of backslashes (\), even on Windows.

The / button at the right of the pattern input can be clicked to add a nested pattern that will apply to files nested in a zip-like file matched by the first pattern. For example, in a project where a .war file is typically uploaded, you could configure a pattern to match a particular .jar file inside that .war file, then click the / button to configure a pattern to match certain .class files inside that particular .jar. To undo adding a nested pattern, mouse over the > icon to the left of its text input. The icon will become a delete button, which can be clicked to remove the nested pattern.

To remove an entire rule, click the (-) icon to the right of the rule.

Zip Content Identification Rules

Identification rules can be used to direct the attention of bundled tools to the correct sections of an uploaded zip file. For example, many projects will contain a mix of first- and third-party code, and without insider knowledge, there generally isn't a way for Software Risk Manager to know which is which.

One example of this is when uploading a .war file to be analyzed. The typical internal structure of a .war file includes many third-party libraries as .jar files, and often the custom code (first-party) is compiled into another .jar file and placed alongside the third-party .jars. In this case, Software Risk Manager has no way to distinguish whether each individual .jar file is first- or third-party, so it will typically assume that all of them are first-party. This can lead to analysis tools becoming overwhelmed and running out of memory and causing the analysis to fail, or if the tool doesn't fail, it will have produced a large number of unactionable results due to it analyzing code from those third-party .jars.

In the example below, a configuration has been made to address a particular case like the one described above. It starts by assuming any .jarfile is "Library Code", by combining the **.jar pattern with the Mark as "Library Code" decision. The next rule uses a more specific pattern to match a my-custom-code.jar and identify it as "Custom Code". This rule overrides the previous one because it comes after. Next, the user realized that they had some third-party library classes embedded in their "custom code" .jar file, so they configured a rule to mark those specific files as "Library Code," This was done by first entering **my-custom-code.jar as the pattern, then clicking the / button to add a nested pattern, then entering **third-party-content.class as the nested pattern.

You can set your project to schedule an analysis for its Tool Orchestration, Tool Connectors, and Git configurations. Scheduling intervals include hours and minutes, number of days with a specified time of day, and number of weeks with a specified day and time. Click the checkbox "Automatically run an analysis," then use the radio buttons to select how often to run the analysis. Click Save to keep your settings.