Time, like love, is a universal subject in songs. Time is also a universal theme when discussing vulns; it’s a key component of risk. Equally universal is the heartbreak we feel when finding out about critical vulns or trying to figure out how to fix them.

Identifying vulns is an important part of evaluating an app’s overall risk. Vuln discovery comes from many sources — scanners, crowds, pen tests, red teams, devs, or others. These are also affected by the budget available for vuln discovery.

Fixing vulns is an important part of reducing an app’s overall risk. Whether you primarily find or fix vulns, it’s helpful to shift perspective between the two tasks. Both sides should be working against similar threat models, but the information they have will affect how each interprets, expands, or contracts those models. It’s mutually beneficial when teams can educate each other on how they perceive these models. This is especially important for resolving vulns efficiently and effectively.

My previous post looked at average resolution times across vuln categories. It revealed a stark bias that the category of Redirects and Forwards took by far the greatest amount of days to resolve, with an implication that such vulns likely pose the least risk and therefore require the least investment of DevOps attention.

In continuing the theme of resolution, here’s a graph that shows the relative number of days to resolve vulns of different risk levels. The days are measured against the average resolution time across all vulns. Fewer days represents a faster fix, greater days a longer one.

Relative days to fix critical to very low risk issues

It’s refreshing to see that the most critical vulns are fixed more quickly than average, and unsurprising to see that low-risk vulns take far longer than average. The top and bottom match what we’d expect from DevOps teams prioritizing their efforts based on risk.

But the graph doesn’t form an idealized Z, where the number of days would be least (left-hand side) for the most critical vulns and progressively increase (towards right-hand side) for less critical ones. What’s going on in the middle?

This messy middle provides a seed for many different discussions. As a metric, the number of days until a vuln is resolved is important, but it offers an incomplete story. Some vulns might be easy to find, but complex to fix. Some vulns might have one level risk when reported, but a lower one when reviewed by the DevOps team — not uncommon when the person who discovers the vuln doesn’t have the full context of the vuln’s impact. Others might be resolved by accepting the risk.

(We might also use this to start a discussion on whether risk has been assigned in an effective manner. Calculating and managing risk is something for future posts.)

As in that previous post, I haven’t noted any specific numbers related to the days. We’ll tackle SLAs and concrete timelines in a future post. The focus here is whether the criticality of a vuln influences the time it takes to resolve it. In the ideal world, they should be inversely related (more critical takes less time). But we live in the real world, where DevOps teams must make engineering trade-offs, address underlying problems, revisit assumptions, and review architectures.

Fortunately, it looks like many organizations focus attention on critical vulns. The real world is messy — just listen to all those songs about time and love. Metrics don’t make things any cleaner, but they can give us different ways to evaluate just how messy it is.