Risk acceptance

The Security Engineer role is required to perform the actions described below. This functionality is not available for other roles in Maverix.

 

Some components (e.g., open-source libraries) used in application development may not have secure versions. In such a situation, as a result of management decisions, Security Engineers can allow using of such components, accepting appropriate risks, by adding security issues to the exceptions. Eventually, Maverix doesn't take this vulnerability into account when checking QG. Thus, there is a deliberate refusal to use certain security criteria or policies for vulnerabilities added to the exceptions.

Maverix provides a mechanism for adding detected Security Issues to exceptions. In practice, by adding a security issue to exceptions (by assigning it an Accepted Risk status), Security Engineer equates such a vulnerability with a false positive. In other words, the presence of a vulnerability added through this mechanism to exceptions is considered acceptable and is not a blocking factor when, for example, making a final decision on whether a release is ready to be deployed into production. Currently, the Accepted Risk status can only be assigned to vulnerabilities detected by SCA tools (e.g., Clair and Nexus IQ).

Note that adding vulnerabilities to exceptions is implemented in one form or another in many tools. For more information, please, refer to the documentation of respective products. It's important to emphasize that the information exchange on Security Issues between Maverix and many tools is two-way. For example, once the status in Maverix changes, the status in a Nexus IQ report changes, too.

If some vulnerability is waived in the SCA tool, it receives the Accepted risk status when imported into Maverix.

If the application includes a proxy repository and the vulnerability is added to exceptions and the "Autowaive True" comment is added to the exception, an acceptance rule is created when the vulnerabilities are imported into Maverix and displayed on the Rules tab of the Risk Acceptance page.

 

 

The following information is displayed for every rule:

• The ID is a rule identifier in the system.
• The ISSUE TYPE is a type of Security Issue.
• The LIBRARY is a used library.
• The CVE is a link to the description in the Common Vulnerabilities and Exposures database.
• The IS OBSOLETE is a rule status (is obsolete/active).
• The CREATED is a date and time of rule creation.
• The EXPIRED is a rule validity period.

There is the icon to the right of every rule. Click this icon to delete the rule.

If a subsequent scan of a codebase or artifact detects a vulnerability with the same name, version and severity value,, it will automatically be assigned the Accepted risk status based on the previously created rule. This approach avoids the time-consuming task of repeatedly changing the status from To verify to Accepted risk for similar Security Issues. Once a risk has been determined as acceptable, there is no need to change the status manually in the future.

Maverix imports comments from tools. Therefore, you can see the reason for being assigned Accepted Risk status in the Comments tab of the relevant Security Issue.

In turn, if the Accepted Risk status is specified for a vulnerability in Maverix, a request is also sent to the tool (e.g., Nexus IQ) to change the status of the corresponding vulnerability (e.g., in the case of Nexus IQ, the vulnerability will receive the waived status).

The system implements two types of risk acceptance mechanisms: unconditional and conditional. In the case of an unconditional risk acceptance, Security Engineer unconditionally admits the presence of a certain vulnerability, and it isn't taken into account when calculating Quality Gates. In the second case, as the name implies, the risk is accepted with a certain condition. Similar to the first case, a vulnerability is also considered acceptable, and its existence isn't taken into account when QG calculating, but until the defined condition (rule) is met—no vulnerabilities described by this rule were found in a source code (see the "Issue Categories" section of the Application Administrator Guide). The term mitigation is often used for conditional risk acceptance.

Let us illustrate the above with the following example. Suppose you need to allow the use of a library in which SCA tools have detected a vulnerability, but only if the SAST tool does not find a vulnerability of a certain type in the source code, such as All_Passwords. Thus, a Security Engineer accepts a corresponding risk, realizing that the overall library vulnerability is due to the presence of particular unsafe methods or functions in it, and restricting their use (by setting a certain condition). At the same time, as soon as the use of unsafe methods or functions is detected by the SAST tool (the All_Passwords condition in our example is violated), the SCA-related vulnerability with Accepted Risk status will be taken into account when calculating Quality Gate.

The required rule is created in Maverix (practical implementation is described below), see the Risk accepted block in the figure below. According to it, this vulnerability is considered when Quality Gate calculating, only if a SAST vulnerability of the All_Passwords type (the Condition field) is detected during a Maverix scan.

 

 

Open the Security Issue description page (see the "Security Issues" section), click the Actions button in the right upper corner, and select the Accept risk item from the drop-down menu to designate Security Issue as the Accepted Risk in Maverix.

 

Unconditional Risk Acceptance

To accept the risk without any conditions and exclude such vulnerability from the Quality Gate calculation, in the Accept the risk window that appears, it's enough to specify both the rule expiration date (the Expiration Date field) and the reason in the Comment field, and click the Accept button.

 

 

The confirmation message appears in the bottom right corner of the user interface, and the Risk Accepted section containing brief information about the rule created appears in the right column of the Details tab:

Conditional Risk Acceptance

Conditional risk acceptance is performed similarly to unconditional one (see the "Unconditional Risk Acceptance" section above), with the difference that the With condition option must be selected in the Accept the risk window.

 

 

Then in the drop-down menu of the Considered SAST category field, select the required condition.

 

 

Specify the expiration date for the rule to be created in the Expiration Date field.

 

 

The Comment field is also required. Click the Accept button. The confirmation message is displayed in the bottom right corner of the user interface, and the corresponding rule is created in the system. If a risk is conditionally accepted, an additional Condition field appears in the Risk accepted section, indicating the selected condition.

 

Information on vulnerabilities designated as Accepted Risk

Information on vulnerabilities designated as Accepted Risk is displayed on the Risk Acceptance page.

 

 

The following information is displayed for each Security Issue with the Accepted Risk status:

• The ID is an identification number of a rule created in Maverix.
• The ISSUE ID is a Security Issue identification number.
• The ISSUE TYPE is a type of Security Issue.
• The CONDITIONAL SAST CATEGORY is a SAST category (condition) used in the case of conditional risk acceptance.
• The ACCEPTED is a date and time of the creation of the corresponding rule.
• The ACCEPTOR is a user login of the user who created the corresponding rule.