Skip to content
This repository has been archived by the owner on Sep 16, 2022. It is now read-only.

Include vulnerabilities in trust score calculation #422

Closed
a-martynovich opened this issue Sep 24, 2019 · 5 comments · Fixed by #502
Closed

Include vulnerabilities in trust score calculation #422

a-martynovich opened this issue Sep 24, 2019 · 5 comments · Fixed by #502

Comments

@a-martynovich
Copy link
Contributor

a-martynovich commented Sep 24, 2019

This will make more sense after completion of #421.

Count the number of unique vulnerabilities which have fixes (?). If their number is more than some Vmax the trust score element should be zero. If their number is zero the trust score element should be 1.

Addition 1: split the vulnerabilities by priority, count them separately. In trust score their numbers should have different weights.

Addition 2: vulnerabilities which are not remotely exploitable should also have different weights.

@a-martynovich
Copy link
Contributor Author

@vpetersson Please specify whether we need Additions 1 or 2 (or both). And how should they affect trust score.

  • Should a low-priority vulnerability, rated as not remotely exploitable, have any effect?
  • Should a medium-priority remotely exploitable vulnerability rate higher than a high-priority not remotely exploitable vulnerability?

@a-martynovich
Copy link
Contributor Author

I've just found out that debsecan database (and security tracker) doesn't even match their own bug tracker. An example:
CVE-2018-5745 on Debian Security tracker: urgency is either low or none, no mention of remote exploitation;
Bug report related to CVE-2018-5745 rates this as "Severity: grave";
CVE-2018-5745 on ISC kb is rated as "remotely exploitable".

Hence I think we should use other databases to assess vulnerability priority.

@vpetersson
Copy link
Contributor

@a-martynovich what do you think about something like this?

For each vulnerability, we deduct:

  • 1 point for each low vulnerability
  • 2 points for each medium vulnerability
  • 3 points for each high vulnerability
  • 1 point for each remote exploitable vulnerability

(max 40 points)

@a-martynovich
Copy link
Contributor Author

@vpetersson I would change this a little bit. In case if a vuln in remotely exploitable I would double its points.
Also what to do with vulns which have no priority, meaning it's not established yet?

@vpetersson
Copy link
Contributor

I would change this a little bit. In case if a vuln in remotely exploitable I would double its points.

Sure. That seems sensible.

Also what to do with vulns which have no priority, meaning it's not established yet?

Just count them as a low until we know.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants