[eyakubovich]

Great feedback.

1) We want to be cautious about changing a score that someone else assigned (CVSS) but we'd like to add our insight to inform of its impact.

2) Absolutely and we'd like to bundle it with active blocking. After reviewing the CVE, we'll let the user either accept (e.g. mute) it or block that specific package from being used (e.g. for dormant ones).

3) We think our service is most useful to slightly larger orgs with dedicated security functions and bigger supply chains. We want to help slow down the fire-hose of vulnerability reports coming from the security to devs.

[cjbprime]

> We want to help slow down the fire-hose of vulnerability reports coming from the security to devs.

Would be interested to hear more strategy here -- in my experience, the only way to actually lift this dev burden is to make upgrading dependencies something that's expected, routine, and near-automatic.

[eyakubovich]

100% agree. The reality is that updating a dependency always carries some risk and sometimes requires changes to code. Reducing the amount of upgrades that have to be done under a stringent SLA makes life easier. In larger orgs we’ve talked to the ratio of eng:apps can be 1:2 or worse, so ownership is harder. In addition, for a fair amount of vulnerabilities, a fix is not available. These situations require a more involved risk assessment and remediation plan (e.g. moving to an alternate dependency). We aim to reduce the toil in such cases as well.