In this article:
Read this article to understand the following issue types correspond to each other:
- High- , Medium- , Low-severity vulnerability in last observation
- High- , Medium- , Low-severity CVE Patching Cadence
In summary, findings for Vulnerability found in last observation are added to the CVE patching cadence issue types if an organization takes too long to patch the vulnerability.
Note: This also applies to findings for the issue types High- , Medium- , and Low-severity content management system vulnerabilities identified.
If a finding is patched within certain timeframes
If a finding for Vulnerability Found is patched within 45 days (high severity), 60 days (medium severity), or 120 days (low severity) after CVE publication date, we do not add a corresponding CVE Patching Cadence finding.
We remove the Vulnerability found finding from the Scorecard in response to a resolution request or after 45 days following the date of last observation.
If a finding is patched outside of certain timeframes
If a finding for Vulnerability Found is patched, but after the number of days listed in the preceding bullet, only then is a CVE patching cadence finding created.
Note: Both findings can appear on a Scorecard at the same time.
Once this new observation of the vulnerability decays again, it will update the Last observed date in Patching cadence issue type and extend its lifetime.
Learn more about patching cadence findings
The following points are helpful for understanding how we handle patching cadence findings:
CVE patching cadence findings are meant to stay on Scorecards because they are a statement about the past behavior of an organization and their ability to respond to the vulnerability.
These findings are automatically removed from Scorecards after 60 days (low severity), 90 days (medium severity), and 120 days (high severity) since last observation of the issue.
CVE Patching cadence is currently the only issue type on the platform with findings that need to decay on their own.
- To detect findings for patching cadence measurements, SecurityScorecard runs the target against public detection with nmap -sV -Pn <target> and then the association of that target output to CVE lists on https://nvd.nist.gov/vuln/full-listing. Matches against the CPEs appear in the findings. SecurityScorecard cross-references the software version against the CVE list.
Decay periods for findings
Here is a summary of what happens if a finding for Vulnerability found in last observation is not addressed in prescribed timeframes:
Low-severity vulnerability found in last observation
After 120 days from CVE publication date, the finding is added to Low-severity CVE patching cadence.
The finding decays after 60 days*.
Medium-severity vulnerability found in last observation
After 90 days from CVE publication date, the finding is added to Medium Severity CVE Patching Cadence.
The finding decays after 90 days*.
High-severity vulnerability found in last observation
After 45 days (from CVE publish date) the finding is added to High Severity CVE Patching Cadence.
The finding decays after 120 days*.
* After the Date of last observation of the Vulnerability Found in Last Observation finding.
Resolving CVE findings
In response to resolution requests, we remove CVE findings from the Scorecard for the following reasons:
The IP was never used by the company (misattribution).
The software is backported.
At the time of the finding, the IP did not yet belong to the organization.
I have fixed this
Note: We accept refutes in this category only if the underlying issue was fixed within 30 days.
For example, we would accept an asset which had CVEs for OpenSHH on it, that we saw only once, and not again after that because it was fixed. Because we do not observe the issue again, and the CVE has been resolved within 30 days of being observed, we should be accept it.
For example we would reject a scenario where the OpenSSH CVEs were seen on December 12, and seen again every month after. We would reject any patching refute for this OpenSSH CVE because the CVE was clearly still unpatched, and we saw it again after 30 days.
For all of the reasons mentioned above, we need to see evidence to be remove findings, according to the current product policies in place.
If you have any additional questions or believe that these findings should be removed for another reason, submit a resolution request with additional information explaining the situation. Our Support team reviews each case individually.