Re: Juniper to be added to the official list of CNAs

[Kurt Seifried <kseifried@redhat.com>]

Hopefully documentation/training will reduce the screw ups/accidents, and tighter feedback loops will reduce the time to correct. One thing that was also mentioned on the board call was having a public "inventory" of CNAs, how to contact them, etc and also a private "inventory" of contact details/etc (e.g. direct managers). 

On Sat, Apr 23, 2016 at 10:02 AM, jericho <jericho@attrition.org> wrote:

On Sat, 23 Apr 2016, Landfield, Kent B wrote:

: Just to be clear.... Voting on CNAs has not occurred in the past. Or at
: least not that I can remember. I see no reason to start now.

Yet, the board used to vote on every single CVE ID assignment. Things
change.

My primary concern is that a CNA who is not following assignment
guidelines ends up causing confusion and headache for those who monitor
their advisories. We've had users and customers mail us asking about CNA
vendor assignment screwups in the past, so it isn't just us noticing. For
the last month, I have steadily increased the number of mails I am sending
to vendors and researchers about CVE assignment problems, sometimes
sending as many as five a day.

If we can better head off that problem, and make sure a potential CNA is
truly ready to step in as one, we should. I don't get the feeling that
most of the board monitors some of these vendors to the degree I do, so I
don't want a rubberstamping discussion via phone to be the only thing
stopping them from getting approved.

: I agree official votes should be on the list for items we have
: previously agreed to vote on but rough consensus on board calls is more
: than enough for most other items.

Everyone appears to agree on this so far, which I am happy to see.

: I personally would not want to start voting on everything as that would
: just slow the effort down greatly at a time when rapid improvements are
: needed.

No, but we also don't want the typical knee-jerk reaction the U.S.
government is well-known for either (and MITRE demonstrated with that
federated ID scheme change nonsense that wasn't discussed with the board).
Taking an extra few days or even weeks to ensure a solution is appropriate
benefits us more than rushing to a solution that will demand more fixes in
the months to come.

--

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