Vulnerability; What would you expect to see when confronted with a vulnerability in a vulnerability management service? The answers vary of course. However, there are fundamental data and knowledge that shouldn't be missed when representing a vulnerability;

  • The name of the vulnerability
  • Generic knowledge about the vulnerability
  • The severity of the vulnerability
  • Certain assets details having the vulnerability
  • Specific details of the vulnerability that shows the way to exploit or retest (though much of the time especially developers use this piece to write black lists, unfortunate)
  • Helpful mitigation techniques and further references
  • Current status of the vulnerability. Is it open, closed, on hold, accepted, false positive, in progress, pending analysis or in a status of recheck?
  • Open and if exists close date of the vulnerability

Ok, these are the defaults. What else?

  • A risk score using severity of the vulnerability and the priority of the related asset. The sole severity of a vulnerability doesn't show its risk.
  • Who is responsible to fix the vulnerability? This is really helpful if you don't have the expertise to assign a security bug to the right authority.
  • The SLA mitigation period of the vulnerability compared to other vulnerabilities with the same severity.
  • The list of assets that have the same vulnerability category.
  • The history of the actions applied to this vulnerability from the very beginning.
  • The source of the vulnerability, which is the scanner it originated from
  • Labels assigned to the vulnerability
  • The number of times the vulnerability went through open->recheck->open cycle
  • The ticket detail of the vulnerability; who is the owner of it, when did it assigned, what is the SLA stage; Transferred, InProgress, Taken Ownership, etc.

With the data crunched comes the knowledge and it's important to show it eminently for a critical process such as vulnerability management.