再保险:CVE托管服务

2017-02-22 16:19,耶利哥写道:结婚>,2017年2月22日,帕斯卡贝写道:> >:恐怕条目的描述,对问题> >服务:像facebook.com,将通常非常模糊,无法核实的。>我>:对现有条目,读起来像“问题X > >:不同于cve - 1234 - 5678和cve - 1234 - 7890”。>问题是什么?>:这可以从中学习到什么?我们不教> >:应该做些什么,或者教做得更好吗?不知道。> >好点。> >还认为,这样的描述几乎从不携带>版本信息,基于*近似*日期。我们经常听到> Facebook“固定vuln”但几天或几周后它真的发生了。> >版本以来是确定潜在的重复问题,一个巨大的工具>没有那将是痛苦的。 Agreed, there's likely pain for cataloging purposes (de-duplication) and low value for engineering purposes. But the overriding factor for me is *identification* (and yes, for ID to work, it has to be possible to distinguish different vulnerabilities). CVE throws light on vulnerabilities. Probably weekly, without looking, I come across issues that don't have CVE IDs assigned and therefore aren't noticed by people who might benefit from knowing. I make a note to send in a minimum viable entry, but haven't yet. Oh, services have CVEs? Airplanes? Dentist office software? Oh, large services freely admit they have vulnerabilities, and fix them? Users/customers actually like such transparency? Vulnerabilities are common and everywhere and aren't terribly special individually. Name them and go about your choice of defensive activities, probably including vulnerability management. - Art