Proposal: Add remediation priority to vulnerabilities

Problem to solve

As a user without a background in security, it is unclear where to focus engineering time first when reviewing a vulnerability report with multiple findings. Whilst there are many details available about security findings, I am not sure which fields and values of those fields help me decide which vulnerabilities to approach in which order.

Proposal

Whilst expanding the information available for sorting, filtering and searching in the vulnerability report being discussed in #342079 (closed) will help with the overall user experience of navigating the vulnerability report and filtering vulnerabilities of interest, the available detail is very much focused at engineers with a background in security engineering. In order to make a clear recommendation based on our own expertise in security, adding a "remediation priority" to vulnerabilities shown in the report would help to make it clear where an engineer should start focusing remediation efforts to have the most impact on the overall security of a project.

The "remediation priority" or simply "priority" field could be calculated as a score out of 10, from a number of existing sources. This score could then optionally be mapped to a more friendly "Do it when you can/soon/now" type representation. This could then be used to filter the vulnerability report and work through the findings based on an informed and contextual rating that embeds a general recommendation based on potentially unfamiliar security metrics. It would be important to call this out in the UI and documentation as a general recommendation, based on data, and further analysis is recommended.

Beyond what is available today, I could also imagine this would be incredibly useful if things like detection confidence were generally available for all findings, as this could also be used to modulate priority.

One example, fairly naive implementation of a prioritization system using currently available information could look something like this -

def calculate_priority(scan_type, age_in_days, severity)
  complexity_score = 0.0
  severity_score = 0.0
  age_score = age_in_days / 7 # get age in weeks

  # confidence would be a really useful variable here
  # actual CVSS if available could be used instead of severity_score

  case scan_type
  when "secret_detection"
    complexity_score = 0.5
  when "container_scanning"
    complexity_score = 1.5
  when "dependency_scanning"
    complexity_score = 2.0
  when "iac_scanning"
    complexity_score = 3.0
  when "dast"
    complexity_score = 4.5
  when "sast"
    complexity_score = 5.0
  end

  case severity
  when "critical"
    severity_score = 5.0
  when "high"
    severity_score = 4.0
  when "medium"
    severity_score = 3.0
  when "low"
    severity_score = 1.5
  when "info"
    severity_score = 0.0
  end

  score = ((5.0 - complexity_score) * severity_score) + age_score
  score.clamp(0.0, 10.0)
end

# example vulnerabilities
calculate_priority("secret_detection", 30, "critical")  # 10.0 or "do it now"
calculate_priority("container_scanning", 120, "medium") # 10.0 or "do it now"
calculate_priority("container_scanning", 7, "low")      # 6.25 or "do it when you can"
calculate_priority("dast", 7, "low")                    # 1.75 or "do it last"
calculate_priority("iac_scanning", 1, "high")           # 8.0 or "do it soon"
calculate_priority("iac_scanning", 1, "medium")         # 6.0 or "do it when you can"

Related history on the removal of confidence from security findings: #339812 (comment 666470607)

(cc @abellucci)