[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVE For Services

On 2017-09-05 09:02 PM, Andy Balinsky (balinsky) wrote:
> I plan to bring up discussion of this topic at tomorrow's board 
> meeting.
> It lead to a healthy online discussion, but has languished for 6 
> months.
> Whether we make a change to the INC3 rule or not, we need to do so
> deliberately, not by neglect of discussion.
> 
> Thanks,
> 
> Andy Balinsky (balinsky)
> PSIRT Engineering
> balinsky@cisco.com <mailto:balinsky@cisco.com>

I am in favor of this (more transparency is better IMHO), however I see
two main obstacles:

1) Many services don't want to admit to flaws, and they can generally
hide them (only if someone's blog posting goes viral do we usually find
out), it's hard to test and hold them accountable (especially with many
jurisdictions having laws against poking away at services).

2) The services that do care about this kind of thing are running bug
bounties and thus already getting a lot of the benefit that CVE would
provide in the form of having a mature security process, and having a
service CVE doesn't give them much benefit (at this time).

I would suggest if we are going to go ahead with this we talk to the
service bug bounty companies as, by definition, they have all the people
that would care about this.


-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com
Page Last Updated or Reviewed: September 06, 2017