Hi @ssrinivas930743 (Community Member)​ — what you're seeing is almost certainly not a bug in your code path but a limitation of how the static scanner recognizes cleansers. Short version: Veracode's dataflow engine only "sees" a cleanse when the tainted data passes through a function on its supported cleansing functions list. Your HtmlHelper.SanitizeCmsHtml(...) is a custom wrapper, so the scanner doesn't know it neutralizes the input — it follows the taint straight to IValidator.ErrorMessage and flags CWE-80.

You have three good options:

1. Route through a supported .NET cleanser inside your wrapper. If SanitizeCmsHtml internally calls one of Veracode's recognized functions (e.g., Microsoft.Security.Application.AntiXss.HtmlEncode, AntiXssEncoder.HtmlEncode, HttpUtility.HtmlEncode, or WebUtility.HtmlEncode), the dataflow analysis will detect it and the finding will go away on the next scan. The full list of recognized .NET functions that cover CWE-80 is here: Supported .NET cleansing functions. If your wrapper currently uses a third-party HTML sanitizer (HtmlSanitizer, Ganss, etc.) or hand-rolled regex, that's why the scanner can't see it.
2. Annotate SanitizeCmsHtml as a custom cleanser. Veracode ships open-source annotations you can drop into your code to tell Static Analysis "this method is a cleanser for CWE-80." Once annotated, any finding whose data flows through that method gets mitigated automatically. CWE-80 (Cross-Site Scripting) is explicitly in the supported list for custom cleansers. Docs: About custom cleansers. The annotations repo is at https://github.com/veracode/veracode-annotations (and https://github.com/veracode/veracode-attributes for .NET). This is usually the right answer for exactly your situation — you already have a sanitizer, you just need the scanner to recognize it.
3. Propose a Mitigation by Design on the flaw. If you're confident the input is already safe (e.g., DynamicProperty.GetDynamicPropertyValue returns trusted CMS-authored content, not user input), you can mark the flaw as Mitigated by Design in the Triage Flaws view with a written justification. A Security Lead then approves or rejects it. Docs: Propose mitigations for flaws and Mitigate flaws using the Triage Flaws page.

One thing worth double-checking on the code itself: IValidator.ErrorMessage is rendered as HTML by the ASP.NET validator control, so the right encoding is HTML encoding (not sanitizing to allowed HTML). If SanitizeCmsHtml permits a safe subset of tags (which is typical for CMS body content), that's actually a weaker defense for this sink than a straight HttpUtility.HtmlEncode / AntiXssEncoder.HtmlEncode would be — error messages shouldn't contain markup at all. Switching this particular sink to AntiXssEncoder.HtmlEncode(...) would both close the finding automatically (it's on the supported list) and be a more appropriate fix for an error-message sink.

TL;DR: option 1 or 2 will clear the V.Likely finding without a mitigation workflow — and for this specific sink, I'd lean toward option 1 with AntiXssEncoder.HtmlEncode since error messages don't need rich HTML.