How do I use the Velocity Insights Page?

Last Updated: 4/1/2024

Overview

Every organization encounters vulnerabilities and performs work to remediate them. The speed by which an organization identifies, coordinates, prioritizes, and remediates these vulnerabilities differs based on their unique resource constraints, processes, and technology. 

We leverage the Mean Time to Remediate (MTTR) calculation as a measure of this speed. Some organizations may face certain hurdles which may make them slower to remediate vulnerabilities, while others may find ways to streamline their efforts and become faster. 

Our Velocity Insights page aims to identify and showcase different metrics that may be leading to this increase or decrease in speed. We hope that our users gain insight into their speed by using these correlated metrics to ask further questions of their teams in order to determine if there are broader implications.

Mean time to Remediate

Our MTTR is calculated as:

• Age = Detected Date - Remediated Date

• MTTR = (Sum of Age across group of vuln instances) / (# of vuln instances)

Velocity

Smaller MTTR = Faster

Bigger MTTR = Slower

When measuring over time, do you see a trend in your Velocity? Are you getting slower? Or faster? Or are you maintaining the same speed? How does this relate to your goals?

Now, are there potential reasons for these trends? That's what this page aims to help you in.

Filtering

You can filter the time range for this page to the following settings:

• All Time
• Last Year
• Last 6 months
• Last 3 months
• Last month

We plan on introducing filtering by Team in the future.

Example

Let's assume that your Average MTTR for your entire organization (all vuln instances) is 103 days in June. And you see the following trend for the past 6 months:

When looking at the Insight Widgets we could look at the following widgets:

• By Severity
  • We learn that for the same time period we have actually been slowest to remediate our Critical vulnerabilities. This is counter to what we expected because our SLAs are most strict on our critical vulnerabilities.
  • Now this begs the question, why?
    • Here you can review other widgets to learn more, or you can begin a conversation with your team to try to understand from their perspective. 
• By Operating System
  • We learn that we are slowest in remediating operating systems for non-traditional OSs such as Alpine Linux, or Tiny Linux among other OSs. 
  • This may help point us towards the potential that we may not have many ways to automate the patch management for a large portion of devices or there may be lack of patches for these OS which may make us slower.

Each widget may provide further context or ask more questions, but the ideal state is that you are now aware of a potential issue that you can work to resolve with your entire team.