Propose mitigations for flaws

Use the Triage Flaws page in the Veracode Platform to propose mitigating factors for flaws.

Propose mitigating factors for a flaw

Before you begin:

You must have the Reviewer or Security Lead role to assign mitigating factors to a flaw in the Triage Flaws page.

To complete this task:

1. On the Triage Flaws page, select one or more checkboxes in the ID column to check out the flaws. The green lock icon appears in the column. If more than one checkbox is selected, you can perform actions in bulk.

2. Select the arrow next to a checkbox to expand the details for the flaw.

3. From the Action dropdown menu, select one of the following mitigations:

   • Mitigate by Design to state that custom business logic within the body of the application, which might not be fully identifiable by an automated process, addressed the vulnerability.
   • Mitigate by Network Environment to state that an environmental control provided by the network the application is running on addressed the vulnerability.
   • Mitigate by OS Environment to state that an environmental control provided by the operating system on the machine the application is running on addressed the vulnerability.
   • Potential False Positive to state that Veracode has incorrectly identified something as a vulnerability.
   note

   If you identify a flaw as a potential false positive, it does not cause Veracode to remove a potential false positive from your published report. Your organization can remove a potential false positive from the published report by approving it. If your organization approves a flaw as a false positive, your organization is accepting the risk that this flaw might be valid.

   • Reported to Library Maintainer to state that the current team does not maintain the library containing the flaw. You referred the vulnerability to the library maintainer.
   • Accept the Risk to state that your business is willing to accept the risk associated with a finding. Your organization evaluated the potential risk and effort required to address the finding.

4. In the Comments field next to the Action menu, enter your reasoning for your proposed mitigation. You cannot save your mitigation without entering comments.

5. Select Save. Saving your action also checks the flaw back in.

note

A user with the Mitigation Approver role who has access to your application can also check back in a flaw that you have checked out.

Flag a flaw as a potential false positive

Veracode tries to provide a low volume of incorrectly reported flaws, but occasionally you might find a flaw that is not valid. If you think that Veracode made a mistake in identifying something as a flaw, ignore the flaw by identifying it as a potential false positive. Veracode periodically reviews issues reported as false positives as part of a continuous improvement process.

If you identify a flaw as a potential false positive, it does not cause Veracode to remove a potential false positive from your published report. Your organization can remove a potential false positive from the published report by approving it. If your organization approves a flaw as a false positive, your organization is accepting the risk that this flaw might be real.

To complete this task:

1. Select the flaw on the Triage Flaws page.
2. Select Potential False Positive from the Action list.
3. Enter the reason you think that the flaw is a potential false positive, up to 1024 characters, in the comment text field and select Save.
4. Check the flaw back in.

To approve a potential false positive and remove it from the report:

1. Select the flaw on the Triage Flaws page.
2. Select Mitigation Accepted from the Action list.
3. Enter the reason for acceptance, up to 1024 characters, in the comment text field and select Save.
4. Check the flaw back in. The flaw is removed from the report and shows in the list of mitigated flaws.

Using the TSRV format in mitigation proposals

TSRV (Technique, Specifics, Remaining Risk, and Verification) is a recommended standard format for mitigation proposals that makes it easy for security teams to understand and accept mitigation proposals from development teams.

note

If you have a Mitigation Proposal Review (MPR) subscription, you must use the TSRV format for mitigation proposals.

The TSRV format comprises:

Technique (T): Type of mitigation in effect

Select the technique that most appropriately explains the compensating control you use to reduce or eliminate the risk that this flaw poses. Refer to your risk proposal guidelines documentation or MITRE. The mitigation type is one of these industry standards:

• M1: Establish and maintain control over all of your inputs
• M2: Establish and maintain control over all of our outputs
• M3: Lock down your environment
• M4: Assume that external components can be subverted, and your code can be read by anyone
• M5: Use industry-accepted security features instead of inventing your own
• GP1: Use libraries and frameworks that make it easier to avoid introducing weaknesses
• GP2: Integrate security into the entire software development lifecycle
• GP3: Use a broad mix of methods to comprehensively find and prevent weaknesses
• GP4: Allow locked-down clients to interact with your software

note

If you select Accept the Risk, Veracode does not show the Technique option.

Specifics (S): Specific compensating control in effect

Describe the implementation details by which the technique is realized. For example, you can implement Technique M1: Establish and maintain control over all your inputs as an allowlist or a blocklist, and each of these might be either a list of literal values, an enum data type, or a regular expression. The clearer the explanation, the more quickly and easily it is for your Mitigation Approver to review your proposal and make a decision. If additional details are available elsewhere, reference that location for the benefit of the Mitigation Approver.

Remaining Risk (R): Risk that mitigation does not address

Explain any known situations or limitations that your compensating control does not address. Your Mitigation Approver might know that the remaining risks are addressed by some other means, or might determine the risk to be acceptable. Remember that compensating controls are intended to manage risk reduction rather than eliminate the risk. Therefore, some remaining risk is to be expected in many cases.

Verification (V): How was mitigation effectiveness verified?

Provide an explanation of how the compensating control you are documenting has been tested and confirmed to be effective. If specific automated tests or procedures confirm the effectiveness of the compensating control, identify those specific tests. The Mitigation Approver can choose to refer to the results of this verification before deciding about the acceptability of the proposal you are making. In the future, you might need to revalidate the compensating control if the risk exposure of your application changes. This revalidation ensures the recommended completeness and repeatability of Verification.

An example of the TSRV is: Flaw: CWE-80 (XSS) is mitigated by design, with this TSRV:

• T: M2 (output validation).
• S: data is passed through sanitize() which applies StringEscapeUtil.htmlEncode to the data.
• R: if data is output to JavaScript context or HTML attribute context, single-quote characters are not escaped correctly. Application does not output JavaScript or HTML attribute contexts.
• V: UAT performed on representative data sets loaded with special characters produced no apparent injection.

When proposing mitigations, select a mitigation type from the Technique (T) dropdown menu, and then provide details for the Specifics (S), Remaining Risk (R), and Verification (V).

Veracode reviews the mitigation proposal against the risk tolerance guidelines that you established. Veracode evaluates the mitigation proposal and labels it as either Conforms to Guidelines or Deviates from Guidelines. If the mitigation proposal deviates from the guidelines, this mitigation proposal either does not provide enough information or does not adhere to the guidelines listed in the risk tolerance guidelines document. You must provide additional information for the mitigation proposal, review the risk tolerance guidelines document, or schedule a consultation call to clarify how to create and document an effective mitigating control for the flaw.

Have Veracode review your mitigation proposals

You can purchase an optional Veracode Mitigation Proposal Review (MPR) service from Veracode to request that Veracode consultants perform additional mitigation triage work for your applications.

Your security team can use the Veracode Mitigation Proposal Review to request Veracode application security consultants to review mitigation proposals that your developers enter. Your security team can make a more informed decision about whether to accept or reject a mitigation proposal.

To request a Mitigation Proposal Review, contact [email protected].

During the review, the Veracode application security consultants provide feedback on the mitigation proposal based on your custom risk-tolerance guidelines. The Veracode consultants can propose the following mitigation types:

Conforms

Veracode has determined the mitigation is present and functioning as described. The mitigation might reduce the risk that the flaw presents.

Deviates

Veracode determined that the described mitigation is not present or might not reduce the risk presented by the flaw. Veracode specifies a mitigation as Deviates if the mitigation relies on factors such as:

• Trusted sources of data
• Configuration file settings
• Operating system controls
• Network controls

The Veracode consultants also specify a mitigation as Deviates if they cannot find the described control or cannot determine how the mitigation is intended to work.

Defer

Veracode has reviewed the finding proposal and the custom risk-tolerance guidelines and has determined that the mitigation requires a more thorough review by your security team.

If Veracode performed the mitigation proposal review for you, you can filter the proposed mitigations by the Mitigation Conformation type.