再保险:关于CVE作业oss-sec邮件列表

在11/26/2015与我,耶利哥写道:>这应该是一个关键问题,因为这是疏远>公司宣布自己“CVE兼容”。这是非常有关。我相信整个董事会,我希望世界上所有软件安全报告包括CVE id。将关键路径上的任务的脆弱性信息披露和修复过程。任务延迟意味着延迟披露,报告和修复、公开披露将更有可能发生在修复或工作区都准备好了,或者人们会赚更多的钱从别人的不安全感。拖延意味着人们呆不长。CVE被接受的关键路径的时间敏感专业的工业过程,它应该提供某种响应时间保证。我建议:1。斜方接受任务请求期限,或删除自己从关键路径,指定必须和引用所有此类请求必须能够处理期限。2。 MITRE monitor and escalate the priority given to languishing issues, or explicitly give up on them. 3. MITRE automatically make assignment requests made to MITRE available for other CNAs to handle, with thanks, if they so desire after a certain amount of time, or if the issue was abandoned as per #2. It sounds like technical resources and competency are present internally at MITRE but mismanaged, or the internal culture and incentive structure at MITRE is a mismatch for the reproducible, assured handling of time-sensitive requests. If MITRE wants to remain on the critical path, it perhaps should explain to the board how CVE assignments are tracked and prioritized? Does MITRE use an aging process increasing the priority of assignments that have been languishing, especially increasing it faster if the assignment is straightforward? Does MITRE have internal tracking and metrics so that such a process could be used? Are people held accountable internally if an issue languishes, and is there an escalation process? Thank you Kurt, for responding to a need and making the CVE more relevant and usable. CVE usability isn't just how IDs are referred to after assignments, but how quick and painless the assignment process can be. Thanks to Kurt and Brian for making the scope of the problem obvious and easily understandable, with examples. The board has had discussions in the past (many years ago) about quality vs number of identified CVE issues; these tended to emphasize the need for quality. However, CVE risks losing acceptance if it doesn't provide sufficient identifiers with a manageable latency. Pascal