Hi Georges,

It seems to be because the searches in Analytics and Triage Flaws are for different logical buckets of flaws:

1. Your Triage Flaws search is looking at Open flaws only, so it makes sense that it matches what's being returned in your current Latest Results of open flaw counts. Are you trying to find Time to Resolve (TTR) of open flaws? If so, know that the Analytics measure you're using (Findings "Time to Resolve") won't work - that measure only registers and stores a TTR value after a flaw is closed either by approved mitigation or a scanner auto-closure. You can verify the TTR measure behavior by adding a filter to your Analytics search on the "Finding Status = Open" and you'll see that TTR field go null across the board. If instead you're trying to see how long your currently open flaws have been open as a sort of alternative TTR measurement, the Findings dimension "Finding Age" should be able to give you that.
2. In terms of what your Analytics search is showing, without any filters on "Finding Status = Open", scan/finding open date restrictions, etc., those counts by severity are showing you the full historical flaw counts in each severity bucket for each application since its very first scan, inclusive of the those currently open and those already closed (except some of the closed flaws, per your filter - you've excluded those with approved mitigations, just note that this Mitigation filter isn't applying to any flaws auto-closed by the scanner). The TTR measure, though, is calculating on only a subset of those severity bucket flaw counts: those already closed (recall that it's null for any flaws currently open). For a true TTR historical average, I'd recommend adding a filter of "Finding Status = Closed", which will show all closed flaws in each Severity bucket and the accurate TTR across them.
3. Final tip is that depending on what you're looking for, you may also want the following filters:

• "Policy or Sandbox Scan = Policy": Without this filter, your results will include not just your regular Policy scan flaws but also those within your developers' Sandboxes. Unless you're using Sandboxes in a way that you want those results included in this analysis, you should explicitly exclude them with this filter.
  • "Policy Rule Passed = No": If your company uses Policies to disallow only a subset of all found flaws (i.e. those above X severity), it can be helpful to apply this filter so you're only looking at the flaws you care about - those that don't pass policy.

If it's helpful, I'll also share how my team tracks TTR:

1. Add Findings explore dimension "Resolved Month", sorted with the most recent month at the top
2. Add Findings explore measure "Time to Resolve"
3. Add this custom Calculation we named "Rolling 6 Mo. Average", which returns the rolling trailing average of each month and the 5 months preceding it): mean(offset_list(${fact_findings.mean_time_to_resolve}, 0, 6))
4. Then visualize a line, with these visualization settings applied:

• Limit to the first 12 rows (to show the last 12 months), but make sure restriction is applied in visualization settings, not in the actual table, or it'll mess with your oldest trailing 6-month averages.
  • Under "Series", apply column to the monthly TTR counts and a line to the rolling 6 month average:
  • Under "Series Positioning", choose Overlay to put the Rolling Avg line overtop the individual months' bar graph counts.

From here, you can apply additional filters for only certain applications, only certain severities, etc.

We find displaying the data this way tells a better narrative to our stakeholders than all-time averages - it shows how our teams are doing over time and whether their TTRs for flaws closed that month are getting shorter or longer.

Hope all this helps!

Cheers,

Kate

Hello Kate and thank you so much for this detailed answer! This indeed helps a lot 🙂

​

> Are you trying to find Time to Resolve (TTR) of open flaws?

​

Indeed, I'm looking for the Veracode estimates and use that number to roughly see which teams are drowning in their backlog the most so we can allocate resources appropriately. I was not aware that there was a boolean field tracking the open-ness of a finding, so I added that now to replace the "Mitigation Status" filter. Indeed after applying that, the report shows all "⌀" in the TTR column (which I've now removed because it wasn't the richt metric in the first place 🙂 )

​

​

> If so, know that the Analytics measure you're using (Findings "Time to Resolve") won't work - that measure only registers and stores a TTR value after a flaw is closed either by approved mitigation or a scanner auto-closure

​

Which metric would help me acheve the above? Have been scrolling through the available fields, but can't quite see which one is pointing to the dimension that puts the orange circles to the "more time needed"side of the "Fix First" graph.

​

​

Thanks in advance for any feedback.

Best regards,

Georges