Veracode Base Camp — Shuning, Veracode Community Manager (Veracode) asked a question.
Hi community!
While mitigation only temporarily addresses the flaw as opposed to remediating, in some scenarios, performing mitigation may be appropriate (or maybe the only thing you can do at the moment), such as closing out the “engineered” false positive potential: CWE 259m, CWE 321 (video: what’s engineered false positive by @Anthony Fielding (Veracode)). In those cases, a good mitigation proposal not only helps developers save time without going back and forth with the security team, but helps your company address the risks effectively by getting the right stakeholders involved and taking necessary actions outside of remediation.
In your experience, what makes an effective mitigation proposal? What are the two or three things that need to be included?
.png){kind=logo}
The built-in TSRV (Technique, Specifics, Residual risk, and Verification) approach is a great way to develop and get approved Mitigation Proposals. If they're done well, they can be used to collect potential custom-cleansers for common situations, like using a RegEx to filter and validate an input string with a constrained set of values. While the static scan may not recognize these as a cleansing function, a well-run internal static scan process can pick up on how these are used to determine possible reuse and establishing it as a custom cleanser for Veracode. Once this happens, the TSRV proposal is automatic and can be auto-approved or quickly reviewed and approved by the InfoSec team. The point is, embracing the use of TSRV as a serious method to propose mitigations can lead to reduced triage and processing times for static scans. The feature is there, but it needs to be used as Veracode intended it.
This is a great question. A mitigation proposal needs to clearly describe how a flaw's risk is being managed.
In my experience, the best way to do that is to include as much detail as possible. A well-written mitigation proposal should summarize the controls that reduce the risk, then explain in detail how those controls reduce it, and make an argument that the issue can be considered resolved. The proposal should be thoroughly detailed to the point that a security team can easily understand the mitigation in play, even if code snippets are not available to them. This will also make it easy for teammates of developers to understand the mitigation, even if they join a team later. Think of a detailed mitigation proposal as a gift that you give to yourself in the future. It's just like reaping the eventual benefits of writing good comments in code: if a Veracode report ever raises doubt about a component’s security, a well-written mitigation proposal can quickly resolve the discussion.
I also echo @Mark_M (Community Member) 's comment about TSRV, because the whole point of that format is to streamline the inclusion of the most effective bits of information into a proposal.
Thank you @Mark_M (Community Member) and @krichard84 (Veracode, Inc.) for the insights! I also wanted to share with the Community these two new tutorials about mitigation proposal that @krichard84 (Veracode, Inc.) created recently: