Mitigate findings

Use the Triage Flaws page in the Veracode Platform to review and mitigate findings with your teams. You can add comments to the findings, and apply mitigation actions for temporarily resolving findings.

The Triage Flaws page displays findings (flaws) for Static Analysis Upload and Scan and Veracode DAST scans of your application. For SCA findings, see the mitigation steps for SCA Upload and Scan or SCA Agent-based Scan.

After a scan is complete, the next step in the workflow is to review and prioritize all the discovered vulnerabilities in detail. Veracode enables you to sort the flaws and decide if you want to take any mitigation actions to temporarily address the flaw. You can mitigate flaws by making changes to the operating system features, network implementation, or application design. After you flag a flaw as mitigated, users in your organization with the Mitigation Approver role can accept or reject the mitigations. Accepting the mitigated flaws removes them from the application score calculation and from being considered in the determination of the application's policy status. The mitigating factors are included in the application report.

note

Mitigations do not provide long-term fixes for application security flaws. For example, changes to your environment or new attack techniques can make many mitigating factors, including network and operating system mitigations, ineffective. Veracode recommends that you use mitigations as part of a long-term plan to remediate flaws in your code.

Mitigation workflow

The mitigation workflow involves:

1. Review the flaws with your team
2. Propose mitigating factors
3. Accept or reject mitigations
4. View mitigated flaws in reports

You can do all the steps in the mitigation workflow from the Triage Flaws page, which you can access from either the Results section of the left navigation menu or from the application overview. You can perform mitigation actions on one flaw at a time or perform a mass action on multiple flaws at one time. You can accept or reject proposed mitigations from the Mitigated Flaws page.

Veracode automatically applies mitigation actions, including comments, proposals, acceptances, and rejections, to all matched flaws within the application. Veracode also applies these mitigation actions to copies of the flaw that might exist in other sandboxes and the latest policy scan.

You can also manage the mitigation workflow with the Annotations REST API.

Review flaws as a team

If you are new to reviewing results from application security tests, or you want to review the results with your teams, we recommend scheduling a consultation with Veracode security experts. Also, before attempting to resolve findings, we recommend reviewing our guidance on developing a remediation plan.

After a scan completes, members of the application security and development teams can review the list of flaws and:

• Provide collaborative comments
• Propose mitigating factors
• Review all feedback

Search for a specific flaw on the Triage Flaws page

The Triage Flaws page in the Veracode Platform shows detailed information on each flaw detected during Veracode analyses of your application. You can search for flaws using one or several criteria, including negative criteria and wildcards.

Using one or more criteria

In some cases, you might want to review a specific subset of the flaws in your application:

• Flaws in a particular module or source file, or on a particular line number
• Flaws in a particular category, for example, cross-site scripting, or CWE
• Flaws you must fix to achieve policy compliance
• Flaws that are very likely to be exploited
• Very severe flaws
• New flaws
• Flaws involving a particular function
• Flaws with pending, approved, or rejected mitigations
• Flaws with a particular effort to fix
• Any combination of the above

You can search for any of these criteria using the Search field at the top of the list of flaws. To search for a particular item:

1. Choose the column you want to search on from the Search dropdown list.
2. Enter your search criteria in the text box or select the appropriate criterion from the drop-down list.
3. Select Go. The list of flaws filters by the search criterion entered, and the search criterion entered appears above the Triage Flaws toolbar.

The flaw count to the left of the list of filter criteria tells you how many flaws your search returned. The Count column shows the number of duplicate flaws that were imported from the scan results. A duplicate flaw is determined when the same type of flaw is discovered on the same line of code, in the same file, within any given module.

You can filter the list of flaws by one or more search criteria.

Searching by multiple criteria

If you want to use multiple search criteria, for example, to find all cross-site scripting flaws in a given module, search by the first criterion, then enter the second criterion. Both search criteria appear above the Search field in the list of search criteria.

If you add more than three search criteria, select More to view the full list of search criteria.

Using wildcards

Wildcard characters are automatically appended to text-based searches so that you receive the best set of results.

For example, if you search for categories flagged debug, the Veracode Platform returns all flaws in the Leftover Debug Code category.

Using negative criteria

You can specify a filter using a negative criterion, that is, is not equal to. You can use negative criteria to exclude a set of flaws from display, such as hiding all informational flaws (Severity=0).

To use a negative criterion:

1. Choose the column by which you want to search from the Search dropdown list.
2. Select the = button next to the list to toggle the button to the Not Equals (!=) state.
3. Enter your search criterion in the text box, or select the appropriate criterion from the dropdown list.
4. Select Go. The list of flaws filters by the search criterion entered, and the search criterion entered appears above the Triage Flaws toolbar.

note

Two or more negative criteria are joined by an AND. This means that you can exclude more than one item, such as multiple CWE IDs or severities, from the display at once by adding each one as a negative criterion.

Removing search criteria

You can select a search tag to remove that search criterion. The search list refilters to apply all search criteria except for the one that was removed.

If you have selected more than three search criteria, you can select More to show all criteria, then select on any item to remove it. Selecting Apply refilters the list.

Other ways to search

You can use the Fix First chart to quickly filter the list of flaws by combinations of severity of issue and ease of remediation. After you have established a filter, you can remove the search criteria as described above.

Work collaboratively on the Triage Flaws page

The Triage Flaws page enables a team of developers and security reviewers to work with the flaws that Veracode reports.

The types of collaboration on the Triage Flaws page include:

• Discussing flaws with comments from multiple reviewers
• Documenting mitigating controls
• Documenting potential false positives

Tracking mitigation comments from multiple reviewers

You can make a comment on a flaw that other team members can review. You can make notes about possible remediation methods, work assignments, and other shared notes as comments on the flaw. Because the Triage Flaws page does not export user comments on reports, the team can treat the comments as a private working area while they remediate flaws.

To complete this task:

1. Select the flaw on the Triage Flaws page.
2. Select Comment from the Action list, if you did not already select it.
3. Enter a comment, up to 1024 characters, in the comment text field and select Save.
4. Check the flaw back in.

Flagging 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, you identify the flaw 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.

Reviewing mitigation activities of other users

You can see other comments, mitigation descriptions, and potential false positive notes for each flaw. All activities are saved to the list of past actions for the flaw, along with the ID of the user making the change and the time when the action was taken.

Comment on flaws

When you comment on a flaw, other team members can review the comment to share your opinions and offer possible remediation methods, work assignments, and other shared ideas. User comments are not exported on the scan reports. Therefore, you can consider the comments as a private type of working area while you and your team remediate flaws.

To complete this task:

1. In the Triage Flaws page, select the empty box in the Id column to check out the flaw. The green lock icon appears in the column.
2. Select the arrow next to the checkbox to expand the details for the flaw.
3. In the Action field, select Comment from the dropdown menu.
4. Enter your comment in as much detail as possible, and 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.

Review comments on flaws

You can see comments, mitigation descriptions, and potential false positive reports made by other team members for each flaw. All actions display the ID of the user who left the feedback and the date and time the user performed the action.

View data path information for flaws

You can view all paths through the code that lead to the sink, the exploitable point where a flaw is expressed, from a link on the Triage Flaws page.

To complete this task:

1. From the application overview, select Triage Flaws.
2. Select the link in the Data Paths column.
3. The Data Path tab opens, where you can view each path that leads to the sink.
4. To view details about a specific data path, select a path from the left panel. Details are displayed for each path, including the steps taken to exploit the flaw, filename or class, function name, and line number or relative location of the flaw by percentage.
5. Fix each exploitable data path to remediate the flaw.

Use the source code view

The Source Code view allows you to load source code from your local system,or a network-accessible directory, into Triage Flaws so that you can view information about the flaw in the context of your original source.

The Veracode Platform does not have access to the source code for the application, and the source code is not uploaded to the Veracode Platform when you view it in the Source Code view.

Before you begin:

You must use an HTML5-supported browser.

To complete this task:

1. From the Triage Flaws page, select Source Code Viewer radio button at the top-right of the page, if it is not already selected.
2. Select a flaw.
3. If you have not previously loaded source code for this application, locate the source code on your hard disk when prompted. For reference, the Veracode Platform shows the fully qualified path of the source code that you used to build the application. The Veracode Platform loads the source code and scrolls the file to the line of code containing the flaw. If you selected the wrong source file, you can select Load Different File to change it.
4. Hovering over the annotation on the left-hand column allows viewing a detailed description of the flaw and a remediation recommendation. You can also scroll through the code to view other flaws in the same source file, or use the Go to Line field to jump to a particular line.

View flaws found in non-debug code

The Veracode Platform allows you to view flaws found in code without debug symbols. Since source file and line number information is unavailable for these flaws, Veracode Provides other location information.

In the Flaws tab of the Triage Flaws page, the Source column contains the function prototype containing the flaw and the approximate location in the function body, by percentage, where the flaw occurs.

Selecting one of the flaws allows you to open a source file for reference. Veracode prompts you with the name of the class path containing the flaw.

About Veracode Mitigation Proposal Reviews

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 these 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.

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.

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.

Accept and reject mitigations

To accept or reject a proposed mitigation, you must have the Mitigation Approver role. To remove mitigations from the policy evaluation and security score calculation, you must accept all proposed mitigations.

To list all the applications that have proposed mitigated flaws, from the Applications page, select Show All Applications with Mitigations. The filtered list that appears lists any application that has a proposed, accepted, or rejected mitigation. From this list, you can select on any application to go straight to the Mitigated Flaws page for that application.

Accept or reject mitigations on the Triage Flaws page

A user with the Mitigation Approver role can accept or reject proposed mitigations from the Triage Flaws page of your application. To see a list of proposed mitigations, in the Search field, select Mitigation and = Mitigation Proposed. To view all mitigations except the type you selected, select the equals icon again.

note

You can only use the Triage Flaws page to accept mitigations for internally developed applications. To accept mitigations for third-party applications, use the Mitigated Flaws page.

To complete this task:

1. In the Triage Flaws page, select the checkbox in the Id column to check out the flaw. The green lock icon appears in the column.
2. Select the arrow next to the checkbox to expand the details for the flaw.
3. From the Action menu in the details, select Mitigation Accepted or Mitigation Rejected.
4. In the Comments field next to the Action menu, enter the reasoning for your decision. You cannot save your action without entering comments.
5. Select Save. Saving your action also checks the flaw back in.

You can delete mitigation comments until the mitigation has been accepted or rejected. To delete a mitigation comment, select the checkbox next to the flaw to check it out, and then click the trash can icon next to the comment you want to delete. After a mitigation has been accepted or rejected, you cannot delete previously added comments.

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. Similarly, such a user can delete mitigation comments created by others.

Accept or reject mitigations on the Mitigated Flaws page

You can accept or reject proposed mitigations in the Mitigated Flaws page for both internally developed and third-party applications.

Before you begin:

You must have the Mitigation Approver role to accept or reject proposed mitigations.

To complete this task:

1. From the Applications page in the Veracode Platform, select Show All Applications with Mitigations.
2. From the list of applications, select View at the end of the row to see a list of the proposed, accepted, or rejected mitigations for the flaws that Veracode discovered in that application.
3. Use the Filter field to sort the flaws by ID, severity, and CWE ID.
4. If you have access to the source code file for the flaw, browse to its location and load it. As in the Triage Flaws page, the source code file is not uploaded to the Veracode Platform but is simply opened by the browser for viewing.
5. Select the Comments tab to view any comments or mitigations for the flaw.
6. When you have reviewed the details of the flaw, select either Accept, Reject, or Comment.
7. Enter a comment (2048 characters or fewer) to explain your action, then select Check in Flaw.

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.

Manage mitigations for multiple flaws

You can make changes to multiple selected flaws at the same time, including commenting, marking as mitigated, or approving or rejecting mitigations if you have the appropriate role permissions. The multiple change performs the selected action on all flaws that you currently have checked out.

You can change a maximum number of 50,000 flaws in a multiple change.

Perform multiple changes on the Triage Flaws page

You can change more than one flaw at once from the Triage Flaws page.

To complete this task:

1. Search for the flaws you want to change.

2. Check out the flaws, either one at a time or by using the checkout button in the header row to check them all out with one click.

3. From the Select Action dropdown menu at the top of the pane, select from the following actions:

   

   • Add Comment to keep notes or provide comments to other reviewers.
   • 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. 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. Select Go. Veracode confirms the number of flaws you are changing and prompts you for a description of the change.

5. In the Change Multiple Flaws window, enter your reasoning for your proposed mitigations. If you have the TSRV feature enabled, you will see the corresponding TSRV input fields.

6. Select Continue. The Veracode Platform applies the change to the checked-out flaws.

7. Clear the flaws one-by-one to check in all files, or select Check-in in the header row to check in all files with one click.

note

Flaws not checked-in could cause additional actions to occur on them and would remain locked to other users. 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.

Perform multiple changes on the Mitigated Flaws page

You can accept, reject, or comment on several flaws from the Mitigated Flaws Page.

To complete this task:

1. In the Mitigated Flaws page of the application, filter the list of flaws to find the ones you want to change.
2. Check out the flaws, either one at a time using the checkbox next to the Id column, or by using the checkout button in the header row to check them all out with one click.
3. Select Accept, Reject, or Comment.
4. Enter your comments on the action in the Change Multiple Flaws window, then select Continue. The screen refreshes, updates the number of accepted and rejected flaws at the top of the page, and the flaws are checked 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.

You can accept multiple flaws by checking them out and selecting Accept.

Generate link to latest instance of a flaw

You can provide a URL directly to the latest instance of a flaw to save your team the time of navigating through the Veracode Platform to find it.

You can share this URL with members of your team involved in triage and remediation to allow more convenient, direct access to the specific flaw.

To link directly to the latest instance of a flaw, create a URL using this template:

https://analysiscenter.veracode.com/auth/index.jsp#ReviewResultsFlaw:{account_ID}:{application_ID}:{sandbox_ID}:{flaw_ID}                   

Before you begin:

To provide the accurate URL, you must know the account ID, application ID, sandbox ID, and flaw ID.

To complete this task:

1. To find the account ID, open the application overview page and, from the URL, copy the ID number that immediately follows https://analysiscenter.veracode.com/auth/index.jsp#HomeAppProfile:

   

2. To find the application ID, open the application overview page and, from the URL, copy the ID number that follows the account ID.

   

3. To find the sandbox ID, open a specific sandbox for the application and copy the ID number at the end of the URL. If the finding is from a policy scan, the sandbox ID is 0.

   

4. To find the flaw ID, open the Triage Flaws page and copy the ID of the flaw found in your scan.

   

5. After collecting the necessary IDs, insert them into the URL template for linking to the latest instance of a flaw: https://analysiscenter.veracode.com/auth/index.jsp#ReviewResultsFlaw:{account_ID}:{application_ID}:{sandbox_ID}{flaw_ID}:

   This URL opens the Triage Flaws page for the specified sandbox, filtered by flaw ID to show the most recent instance of the flaw being found in a scan.

   

View mitigated flaws in reports

After you have approved one or more mitigated flaws, the reports for the application update to show information about the mitigations as follows:

• Veracode recalculates the policy status, Veracode Level, and Veracode legacy rating, removing the approved mitigated flaws from consideration.
• Lists of flaws in the application by category show the effective number of flaws after the approved mitigated flaws are removed from the application.
• Approved mitigated flaws are removed from the detailed listing of flaws in reports.
• In the on-screen report, the Mitigated Flaws and Proposed Mitigations tabs show the mitigated flaws, grouped by severity, which is color-coded.
• The red and green badges on the left indicate if you must fix a flaw to meet policy or if the proposed mitigation is accepted.
• In the PDF report, a Mitigated Flaws appendix lists all the approved and proposed flaws.