Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Metric: Security vulnerability resolution Duration #53

Open
david-a-wheeler opened this issue Jul 21, 2018 · 6 comments
Open

New Metric: Security vulnerability resolution Duration #53

david-a-wheeler opened this issue Jul 21, 2018 · 6 comments

Comments

@david-a-wheeler
Copy link

The "Closed Issue Resolution Duration" covers all issues, but is a little misleading. I routinely leave issues open for years if they are low importance, yet are nice-to-have - but that doesn't mean that the project is dead. What's missing is prioritization - if something is really important, then it should be resolved relatively quickly.

I propose "Security vulnerability resolution Duration" - the time it takes between when a vulnerability is reported to the project and when it is resolved. Security vulnerabilities have priority levels too, but clearly security vulnerabilities are more important to most projects than prettier formats or other nice-to-have things.

@david-a-wheeler
Copy link
Author

You can partly counter the priorities of vulnerabilities the same way the CII Best Practices badge does: only measure this for vulnerabilities whose CVSS score is "medium or higher".

That would mean that this measure would show how quickly a project responds to medium or higher risk vulnerabilities. If a project won't respond in a timely way to vulnerability reports, then maybe users don't need know anything else about the project...!

@GeorgLink
Copy link
Member

GeorgLink commented Jul 21, 2018 via email

@germonprez
Copy link
Contributor

Thanks @david-a-wheeler. Are you suggesting a new metrics aimed at vulnerabilities or are repositioning of this current metric?

I also think that we are not proposing any metric as an indicator of some value judgement (i.e., old open issues = dead project). We are simply putting the metric forward as a measure that could be investigated in more detail if the metrics users would like. Context is impossible in these cases so value judgements fail.

@david-a-wheeler
Copy link
Author

I am proposing it as a new metric.

As far as value judgments go, I'm not proposing it as some sort of ethical failing. But if someone doesn't plan to do anything different depending on the value of a metric, don't see why they would care about a metric. Most metric frameworks that I'm familiar with stress that there is no point in measuring something unless there is a decision to be made by using those measures. Clearly a single measurement can be misleading, but that is why multiple measurements are useful.

@germonprez
Copy link
Contributor

fair points :)

@germonprez germonprez transferred this issue from chaoss/metrics Oct 22, 2019
@GeorgLink
Copy link
Member

I think we can solve this issue with a "filter" ... assuming that issues are tagged or otherwise identified by their "priority" or "security relatedness".

@germonprez germonprez changed the title New issue: Security vulnerability resolution Duration New Metric: Security vulnerability resolution Duration Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants