Using the TSRV Format in Mitigation Proposals

Results and Reports

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.

Veracode now offers enterprise customers a feature that requires their users to use the TSRV format for mitigation proposals. This format comprises:
Technique (T): Type of mitigation in effect
Select the technique that most appropriately explains the compensating control you are using to reduce or eliminate the risk posed by this flaw. Refer to your risk proposal guidelines documentation or for more information. The mitigation type is one of the following 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

Read more about the MITRE source for technique classification at

Specifics (S): Specific compensating control in effect
Describe the implementation details by which the technique is actually realized. For example, Technique “M1: Establish and control over all your inputs” may be implemented as a whitelist or a blacklist, and each of these may be either a list of literal values, an enum data type, a regular expression, etc. 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, please reference that location for the Mitigation Approver’s benefit.
Risk (R): Risk that mitigation does not address
Explain any known situations or limitations that your compensating control does not address. Your Mitigation Approver may know that the remaining risks are addressed by some other means, or may determine the risk to be of an acceptable nature. 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, please identify those specific tests here. The Mitigation Approver can choose to refer to the results of this verification before making a decision about the acceptability of the proposal you are making. It may be necessary in the future 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 would be: Flaw: CWE 80 (XSS) is mitigated by design, with the following 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 (V), 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.