Previous: Mitigations, Part 1: What is a Mitigation

A Mitigation Proposal is a short, written statement about a mitigation. You can create a Mitigation Proposal if you have a flaw whose risk is reduced by a mitigation, but it is not possible to remediate. The proposal describes the mitigation and how it reduces the flaw’s risk. After you submit it, a designated user or team within your organization will review the proposal. If they approve it, it makes the flaw free from policy in Veracode and remediating it is no longer required. Because of this, it’s important to only submit a mitigation proposal after you have thoroughly reviewed a flaw and attempted all possible remediations. It is also important to provide plenty of details in the proposal, so that the mitigation approver can have the facts they need to make their decision. If details of a proposal are not clear, the approver may reject it or ask you to propose another. 

Here is how to create a Mitigation Proposal in Veracode. This section will use the Veracode Platform, but you can also create Mitigation Proposals while using several other Veracode products.  

In this application profile, I have navigated to the Triage Flaws view. The first step to propose a mitigation is to select the flaws that you wish to propose it on. You do this by marking the flaw’s checkbox. Once you write the mitigation proposal, it will be applied to each flaw you have selected. You can also select flaws by setting filters on the data they have in common, like CWE or source file, then clicking the All Flaws button. This will select the flaws that match all the filter criteria. Please note that it is important to still review the flaws individually before mitigating them, to make sure that the proposal applies equally to each flaw in the group.  

Once you have made your selection, you can choose the type of mitigation proposal to add by clicking the _NAMEHERE_ button. To briefly explain some of these options: 

• Mitigated by Design: the most common choice. This option applies to flaws that have mitigations which the Veracode scanner cannot detect. This can describe a lot of mitigation types, such as deployment configurations. If you are not sure about which option to select, by default, select this option.  
• Potential False Positive: describes cases where a flaw finding is simply not valid. Examples of false positives would be if the scanner misidentifies a JavaScript function call as belonging to an object of a different class, or if a destination buffer’s size in C++ is reported inaccurately to be too small for data being written there. What makes these conditions distinct is that they describe security flaws that don’t really exist, rather than flaws that were mitigated in an undetectable way.  
• Mitigated by OS Environment: can be used to document controls provided by the OS runtime environment, and  
• Mitigated By Network Environment: can be to document controls located in the app’s network environment.  

Again: if you are not sure which option to choose, a safe default is Mitigated by Design. To learn more about additional options, consult the Veracode Help Center. 

While writing the mitigation proposal, you may be required to use the TSRV format. The acronym “TSRV” stands for the four elements of this format: Technique, Specifics, Risk and Verification. We designed it to streamline the capture of data that security teams need for making informed decisions about accepting mitigation proposals. It also enables consistency when multiple teams are filing mitigation proposals. Veracode recommends the use of this format to document mitigations, and it can be used for almost all mitigation proposal types. If TSRV is not enabled for your organization, you will see a free-form text box instead of the TSRV form, but we still encourage you to follow this format. Let’s learn more about how to create a TSRV statement.  

• Technique: This field asks you to select which option most accurately describes the style of the mitigation being proposed. You will see a list of strategies for reducing risk. Security controls come in all shapes and sizes, but the items on this list covers many of their functions. For example, you can select M1/”control of inputs” to propose mitigations like validation with regexes, allowlists, or denylists. M2/”control of outputs” would cover mitigations such as output encoding. Meanwhile, M3/”control of environment” would cover authentication, zero-trust microsegmentation, and so on. Select the item that is the closest match, even if none matches your mitigation exactly.  
• Specifics: In this field, you can provide more detail about how the Technique is implemented, and how the mitigation reduces the flaw’s risk. We recommend that you be as specific as possible while completing this step. For example, if your mitigation is to validate the application’s inputs, then don’t just say “the inputs are validated”, but explain what inputs are validated and in what way, as well as where the data originates from and where the validation occurs in code. This way, the person reviewing your proposal won’t need to contact you for additional information if they cannot access or understand your code. Doing so is also very beneficial for people who may join your project in the future if they would need to work with these results. 
• Remaining Risk: This field asks you to describe any risk that remains in place despite the mitigation in effect. Remember, mitigations by their nature are not guaranteed to remove all of a flaw’s risk. So if any risk is left over, it is important to accurately disclose this to the security team before they make their decision. In this step, write a summary of the risk that would be assumed by accepting the proposal. This helps the approver to understand the mitigation’s effect on the flaw, and also shows them that you have a clear understanding of the proposal you’ve made. 
• Verification: In this final step, you can list any actions you’ve taken to ensure the effectiveness of the mitigation. If you rely on a control to remove risk from a flaw, then that control should be verified. For example, you can do so through code review, or writing unit tests, or having a discussion with a Veracode consultant. Any such steps that you’ve taken can be mentioned here.  

Once you have completed the mitigation proposal, click Continue. This will apply the proposal to the flaws and change their mitigation status to “Proposed”. To finish the process, you will need to contact your mitigation approver and ask them to review your mitigation proposal. If they approve it, then the flaw will immediately stop counting against the security policy. It will continue to be visible in the scan results for informational reasons, but it will be considered resolved, and you will not be required to take further action on it. If the same flaw instance is found again in a future scan of the same application profile, the mitigation will automatically be copied to it, so you won’t need to repeat the process with each new scan. However, please note that mitigation proposals are applied to individual flaw instances, not to the entire flaw category. Therefore, if new instances of the same flaw type are found later in different locations, they will not be mitigated automatically, so it will still be necessary to review them. 

Next: Mitigations, Part 3: Example Mitigation Proposals