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

Re: Notice of Pilot Activity in CVE Auto WG

On Tue, May 9, 2017 at 12:27 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:

Thank you Harold for providing this opportunity for feedback.


As I raised on the last board call, I have concerns with using GIT as a content management solution for CVE entries, since it has some limitations.

1)  It is unknown if the CNA community will want to use this solution. If they won’t adopt the approach eventually, then a pilot is a non-starter.

I know in the open source community we're all git all the time basically, there are also various things to git gateways. 

2) A centralized solution for content management may not fit a hierarchical organization of CNAs. We generally want CVE information to flow towards the root CAN and then to the list. Not all CNA hierarchies may wish to publish centrally. It might be better to look at a syndication approach which might better align with this type of organizational structure. Perhaps this should be piloted at the same time, allowing for a comparison to be made?

Another aspect is do the CNA's do quality control/enforce their own rules, e.g. there's the minimum CVE specification, and chances are other CNA's may require more (e.g. DWF will require IMPACT explicitly, and URL's MUST be publicly accessible with no login/gateway to access them). So I assumed we'd have a publishing model where CNA's just publish to their parent until it hits MITRE.

3) GIT requires a copy of the repo to be downloaded, with all the history which can be quite large. Some pruning of history may be possible, mitigating this issue. This should be investigated as part of the pilot. If GitHub is used I believe there is a 100 MB file size limit and a 1GB soft limit and a 2 GB hard limit on all repos, with a we have a 2TB limit. This could also pose a problem.

We can easily shard the repos (already done by DWF, into blocks of 1000 per year).

4) GIT does not have a way to search entries. A separate service will need to be built on top to support this, which complicates deployments.

That is out of the scope as far as I'm concerned. For me the requirements boil down to:

1) Must support version control (who did what to which entry when and why?)
2) Must support signing so we have a strong chain of ownership (and I don't want to commit to JSON signing yet as many of those solutions make the JSON not human readable)
3) Must support collaboration (e.g. multiple CNA's using the same system, I'm not setting up one data storage thing per CNA) 
4) Must support some degree of delegation (e.g. I can allow a CNA to further grant access so I'm not a chokepoint)
5) MUST SUPPORT PUSHING OF DATA, I don't want to have to go hunting for CVE entries! (MITRE knows how much fun that is)

git fulfilled all the above, and has the bonus of a free hosting provider (github) and multiple other hosting providers (gitlabs) and the ability to easily self host (using software like gitlab for example, or setting it up myself if absolutely needed). 


I am sure there are other concerns I am missing.


I’d like to see the following occur before moving forward with this pilot:

1) Discussion of the GIT approach on the CNA list to explore if there are major concerns with its use before moving forward.

The main concern I had was git repo size, solved by sharding.

2) Discussion within the automation WG / board lists about alternate approaches that may be piloted as well. These should also be discussed on the CNA list before moving forward with a pilot.

What are the actual alternatives being proposed? I've heard of some sort of atom/rss syndication deal, but that means people have to run a system with a server that will periodically pull the data. 





From: owner-cve-board-auto-list@lists.mitre.org [mailto:owner-cve-board-auto-list@lists.mitre.org] On Behalf Of Booth, Harold (Fed)
Sent: Monday, May 08, 2017 5:09 PM
To: cve-editorial-board-list@lists.mitre.org
Cc: cve-board-auto-list <cve-board-auto-list@lists.mitre.org>
Subject: Notice of Pilot Activity in CVE Auto WG


This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing


Per discussion on the last board call it has been requested that all WGs send a brief notice to the board to both inform the board and provide an opportunity for the board to give input on any pilots.


The CVE Automation Working Group is proposing to run a pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data. We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation. Participants will be MITRE and members of the CVE Auto WG with the goal for participants to update their CVEs using the format in the GIT repo and for participants to update and receive updated information through the GIT repo. Participants will be the only ones with access to the GIT repository. All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot. Initial proposed pilot is planned to run no later than through August 21st and if we need to extend the pilot we will come back to the board to request an extension.


Unless there are any sustained objections the pilot will start in earnest on May 15th (the next CVE auto WG call).


Kurt Seifried

Page Last Updated or Reviewed: May 09, 2017