[pquerna]

congrats on the launch!

three questions / thoughts:

1) Your post mentions "Ranking", and while do the most impactful work first is great, the method I have most often used is when dealing with Vuln-overload is to "Reclassify". That is Common Vulnerability Scoring System (CVSS) (super flawed as it is) has let reporters check the box for "remotely exploitable" therefore its a 8.0 HIGH vulnerability -- but I think your product could let me reclassify the vuln to a medium/low - maybe a built in CVSS score editor?

2) One other thing there should also be a built-in concept of "accepting the risk" -- and ideally a concrete report of what was previously "accepted", and if that package gets used in new ways?

3) I'm curious what you think about market segmentation in this space? Specifically the sub-200? person companies seem to be using alot of the "all in one" Compliance platforms (eg, Vanta, Drata, etc). Vanta for example does have a vuln management + SLA tracking dashboard + ticketing tools.

[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.