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

>:比尔Fithen [mailto: wlf@cert.org]>真正基本的我看来,脆弱的本质是>独立的机制(s),可用于改正它。>可能是有很多方法来正确的一个漏洞。事实上,很明显我>,这种修正的“列表”的对策是一个>完全独立承担与CVE(也许CCE ?)。这可能似乎是根本,但实际上它比这更加困难。例如,假设我有一个糟糕的DLL,暴露10症状,但是治愈是更新这个图书馆。我要说,弱点是坏的图书馆,但是有许多可能的利用。在Linux内核中最近的问题说明了这个问题。所以我们应该问题几十CVE对应用su条目,因为某些Linux内核的一个不足之处?或者我们应该说,这一个问题一个条目的缺陷导致了很多问题?我将去一个条目。 The obvious problem we have is that we are not always able to determine whether there is a single root cause, and that some vendors will just release new binaries which may fix numerous problems, and not provide enough information to determine what's going on under the covers. > If the goal of this rule is to help us split or merge based on what > the vendor says about his own product and there is no other way to > obtain that information than to infer it through the vendor's action, > I say that it makes no difference whether the vulnerabilities in > question are split or merged. We have so little information as to make > it useless. We'll probably have to handle this on a case-by-case basis. All the vendors are different. Recent Microsoft bulletins have been fairly explicit about whether a hotfix corrects related or unrelated issues, so it should be fairly easy to deal with our products. For the rest of it, YMMV - you'll see everything from very terse announcements with little to no information, all the way up to knowing which line of code failed in which module. > I would rather have a rule that says that if the previous rules fail, > then we have to depend on the vendor of the product to say whether to > split or merge and just "live" with their response. We can never have > enough information (short of someone reverse engineering the affected > code) to make a meaningful split/merge decision. Again, I'd point out that perhaps "rules" is the wrong term to use and the wrong approach. "Rules" implies a strict and inflexible process and if you attempt to apply "rules" to a situation with a lot of noise, there will be a lot of failures and/or the rules will become so complex that we'll need lawyers to write and interpret them. Perhaps it is better to set forth goals and guidelines. We can then use our collective judgement in order to try and reach those goals on a case-by-case basis. It also gets us out of the business of attempting to chart a decision tree that handles all possible issues. > All other things being inconclusive with respect to the split/merge > question, if we arrive at this rule and the vendor refuses to answer > the split/merge question, then it seems to me the only conservative > approach is to split. If we incorrectly split, the only consequence is > information redundancy. If we incorrectly merge, the consequence is > information loss. Once we split based on the lack of information, the > (possibly redundant) entries are marked as 'this is all we know' and > left that way until we know more. If at some point in the future (even > after they might be voted into CVE), if someone learns enough to > "prove" to us they should have been merged, then we merge them. 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.