通过忽略漏洞来提高安全性

一般来说，“忽视漏洞”这样的说法并不是你期望从安全公司那里听到的。 毕竟，漏洞是造成如此严重违规行为的罪魁祸首，以至于我们的信息流连续数月充斥着事后评论、分析和建议。

而且你肯定不会看到“忽视漏洞”与“提高安全性”的概念联系在一起。 

现在你已经知道了——尽管与大多数建议一样，它也附带警告和资格。

你当然不应该忽略所有的漏洞，但事实证明有一类漏洞你现在可以安全地忽略 - 或者至少在紧急情况下降低其优先级。 我在阅读WhiteSource Software的《2018 年开源漏洞管理状况》时偶然发现了这个概念。

除了一些非常有趣的统计数据外，该论文还提出了将开源漏洞分为两类的观点：无效的和有效的。

WhiteSource 分类的前提是某些漏洞是无效的 - 即它们无法被利用，因为它们没有被自定义代码调用。 能够分析和区分意味着安全性，开发人员可以专注于那些被认为有效的漏洞，从而减少时间和精力，同时提高应用的整体安全性。  

例如，考虑一个依赖于包含易受攻击功能的开源组件的自定义应用。 根据 White Source 的定义，此示例中的易受攻击的函数可能会被声明为“无效”，因为它从未被自定义应用调用过。 精明的读者会注意到，该漏洞函数可以被开源组件（另一个组件或同一个组件）中的函数调用，从而使其有效。 当我向 WhiteSource 询问这种可能性时，他们扩展了他们的分类并指出已考虑到这种可能性。 如果从自定义代码或通过另一个开源组件间接调用存在漏洞的代码，则会将其标记为“有效”。 相反，如果没有路径（直接或间接）调用易受攻击的函数，则将其标记为“无效”。  

鉴于 WhiteSource 的研究不仅确定 96.8% 的开发人员依赖开源组件，而且 7.5% 的项目都存在漏洞，因此，能够确定需要优先关注哪些漏洞无疑会大有裨益。 WhiteSource 进一步发现，高达 64% 的开源产品仅包含无效漏洞，他们认为可以安全地忽略这些漏洞。

现在，虽然我并不认为我们应该仅仅因为漏洞没有被主动调用就轻率地忽略它们，但我确实认为使用这样的区别来优先考虑漏洞管理是有价值的。 通过关注主动调用的易受攻击的代码，开发人员和安全专家可以立即提高应用的整体安全性。 这可以更好地利用高级开发人员，White Source 的报告发现，高级开发人员平均比初级开发人员花费更多时间来解决漏洞。

需要采取某种优先排序方法。 WhiteSource 表示，2017 年报告的漏洞近 3500 个，比 2016 年增加了 60%。 所报告的 3500 个漏洞并非都会影响每个应用或组织，但我们应该记住，这些数字是不断增加的。 也就是说，这 3500 个漏洞是添加到累计总数中的新漏洞。

毋庸置疑，代码中存在很多漏洞——无论是定制的还是开源的。 能够根据补救措施是否“有效”或“无效”来确定其优先顺序，符合新兴的安全策略，该策略根据生存威胁以及其他因素对风险进行评分。 无效漏洞的存在威胁几乎不存在。 话虽如此，忽视无效的漏洞可能不是最好的长期方法。 这类漏洞最终可能会有效。 随着功能的添加和/或增强，自定义代码的变化以及开源组件随时间的推移而发生的变化，可能会导致打开调用易受攻击函数的路径。 这就是为什么专门针对漏洞的源代码分析最好应该持续进行，最坏的情况则应该在最终构建期间进行的原因之一。

但为了满足最后期限并有效利用开发人员的时间，将“无效”漏洞推到队列的后面，以便可以立即纠正“有效”漏洞，这可能是开发人员现在提高安全性的更好方法之一。