Re: CVE Automation Working Group Charter

[Kurt Seifried <kseifried@redhat.com>]

One comment, and this is not me as a biased Open Source advocate, but me as someone who has had to deal with both Closed Source and OpenSource, I think it's worth stating:

1) OpenSource in generally grants a license to use that cannot be revoked (short of us doing something really silly)

2) OpenSource is generally very available, worst case we can keep archives of the stuff we use

For example some problems with Closed source: what happens when people from Crimea, Cuba, Iran, North Korea, Sudan or Syria want to do CVE? What happens if they have 0 software budget, but as students have time/inclination to do CVE? etc. What happens when the software lacks a feature, or has a security flaw, and the vendor won't provide an update? 

From a long term sustainability point of view I think we need to have control of our software stack and ideally use a service stack that is neutral (e.g. github, we can worst case scenario run this ourselves) outweighs any short term advantage of using closed source/licensed software.

On Thu, May 17, 2018 at 11:56 AM, Levendis, Chris <clevendis@mitre.org> wrote:

Hi Chris, I pulled the following principle from the charter:

 

•Use free and open source solutions where possible. Avoid solutions that require propriety, closed systems, or are not compatible with CVE terms of use

 

I agree with this principle but think it is incomplete. Efficiency of use and management, and scalability are important considerations when considering any potential solution. Effectiveness is dealt with by another principle, but it is possible to have a non-scalable and inefficient solution that is effective. In other words, it works but it is too expensive in terms of labor hours to manage. The statement could say:

 

•Use free and open source solutions where possible. Avoid solutions that require propriety, closed systems, are not plausibly scalable to support program growth, are labor intensive to manage, or are not compatible with CVE terms  of use.

 

I also recommend numbering the bullets under each of the sections so that we can refer to them by number instead of having to state the bullet each time we need to reference it in written or verbal discussion.

 

C

 

Chris Levendis

The MITRE Corporation

(W) 703-983-2801

(C) 703-298-8593

clevendis@mitre.org

 

From: Johnson, Christopher S. (Fed) [mailto:christopher.johnson@nist.gov]
Sent: Thursday, May 17, 2018 11:40 AM
To: CVE Editorial Board Discussion <cve-editorial-board-list@mitre.org>
Subject: CVE Automation Working Group Charter

 

CVE Board Members,

 

I am recommending the attached CVE Automation Working Group charter for approval by the board.  Please review the charter and submit your vote to this email list  by Noon EDT on Thursday, May 31.  The results of the vote will be announced at the June 13^th board meeting.

 

The charter is also available from the GitHub repository:

https://github.com/CVEProject/automation-working-group/blob/master/CAWG_Charter_DRAFT.md

 

 

Thank you,

Chris Johnson

CVE Automation Working Group

--

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