再保险(CD): CD建议:SF-LOC(软件缺陷在不同o f代码)

> - - - - - - - - - - - >从原始信息:比尔Fithen [mailto: wlf@cert.org]> >最近Linux内核的问题说明了>问题。所以我们应该> >问题几十CVE对应用su条目,因为> > >某些Linux内核的一个缺陷吗?或者我们应该问题一个条目,> > >说,这一缺陷导致了很多问题?我将去一个条目。这里的问题是一个角度。>在一个极端是软件工程安全分析师>在另一个极端是系统管理员的工作就是事实上,管理应该也明白这意味着什么,如果它不是正确的文件。>从一开始CVE一直振荡之间的这些极端>,因为我们对这些>的董事会成员,代表两个极端和介于两者之间的。我的观点来自于2经验——一个是维护一个安全审计工具,和看到的检查和竞争工具之间变得难以理解甚至高级用户由于缺乏共同的术语。这就是我们想要避免的。现在我们有了这个美妙的CVE的东西,我们投入vulns左和右。 If we're not careful, we'll end up with a big list full of garbage, and then the customers of said vendors will come along and see that the CVE list has a bazillion entries, but the auditing tools only check (a bazillion/5) entries, and make the vendor's lives miserable on that basis because the vendor can't possibly write checks for something that is either poorly documented or junk. As a _user_ of the vendor's products, I know that they love to claim that they have some number of checks >> # of competitor's checks. Every vendor I'm aware of is guilty of this to some extent. As a security admin, the last thing I want to see is ONE problem causing the number of security issues to go through the roof - screws up my ops people, and screws up my users. I don't have the luxury of a purely academic interest in these bugs - I've got a real network to secure here. My agenda (other than representing the interests of my employer) is to try to minimize the amount of junk that shows up in this list. If we end up with a huge list full of garbage, we'll have failed because it won't be useful to anyone for anything. > My hope is that the more mainstream the product and the more > significant the vulnerability, the easier we will find collecting the > necessary information. I think that this will be true, and that people will be more interested in analyzing the problem. > I agree. I use "rule" above in the natural language sense, not in the > formal logic sense. None of these CD's can have logically consistent, > universally applicable rules. The problem space is too large - we're going to have to be flexible. In light of the above, I think we have significant incentive to avoid duplicates - but data quality really has to be foremost. > > I'd agree with this - but a merge doesn't entail > irrevocable information > > loss - we still have the original source reports, and we > can still split > > something later if we really need to. We will probably err > in both ways. > > I also agree with this. But, I wasn't thinking so much in terms of > irrevocable loss of information than I was thinking how an uninformed > user of CVE might interpret the absense of the supporting information > that we squirreled away against the day when we might need to > reconsider the merge. From our perspective, no matter how we represent > the resulting CVE entries, barring some catastrophe at MITRE, we will > always have the complete set of information we had originally to > reconsider their representation. But CVE users will not have the > benefit of that hidden information. For that reason, I favor a > mistaken split over a mistaken merge. This is why I think what we really have here (whether we admit it or not) is a database, and not a list. Part of the database ought to include original references.