对于处理漏洞来说，有一些通用的原则点，可以用来帮助指导安全思考和决策。
首先，了解我们保护的对象始终很重要，因为这对我们需要采取的行动有影响。举个例子，如果我们的人工制品是一个网络服务器，那么我们需要保护它免受不受信任的用户的侵害。如果我们的人工制品是加密软件，那么我们显然需要保护它，即使是对系统进行物理访问的用户。在每一种情况下，我们都清楚地区分风险边界是什么，以及我们需要关注的地方。
其次，配置是代码库的一部分。如果恶意行为者可以访问您的配置，那么它基本上与该恶意行为者可以访问您的代码库相同。
鉴于最近的Log4j 2.x 漏洞( Log4Shell )引发的易受攻击系统海啸，作为一个安全组织，我们可能会更密切地搜索其他潜在漏洞。然而，也许我们也应该借此机会停下来反思一下，然后再急于判断我们在代码中发现的每个潜在安全问题。冷静的头脑也可能会建议，导致安全问题的一切都不一定被归类为平等。
作为一个例子，我们可以通过这个镜头查看最近针对 Log4j 1.x 的CVE-2021-4104分配。利用这一点需要直接访问配置文件以操作设置。现在围绕Logback项目出现了类似的主题，以及Node社区中的示例。
让我们明确一点，暴露潜在的漏洞仍然是一件好事。但是在媒体恐慌中，探索我们自己的批判性思维并重新建立我们应该关注的社区基线也是合适的。制造另一场潜在漏洞的海啸可能弊大于利，进一步压倒已经压力过大的安全团队，并搅乱了行业正在进行的保护开源软件的努力。
批判性地思考 CVE
上述线程中确定的讨论提出了一些非常有趣的问题。
例如，如果一个漏洞需要对系统内部文件的特权访问才能被利用，那么这真的是一个漏洞吗？几乎任何重要的现代软件都可以配置为允许不安全的操作。与此类似的是，完全有可能sshd将其配置为允许使用空密码登录。我们是否应该认为这是一个新的漏洞sshd？
我们的安全团队使用的机制之一是考虑预期与意外行为的想法。如果一个软件可以被配置为执行远程代码并且这个功能有详细的文档，它是否是一种提供可以被利用的弱点的行为？可以认为这是预期的行为，而不是实际上本身的安全漏洞。
我们是否应该将软件设计为没有不安全的可配置模式？这可以被视为一个值得称赞的目标，但它与我们过去 30 年或更长时间设计开源软件的方式有些冲突。开源软件的典型设计目标是实现最高级别的可配置性，以允许所有用例。近年来，合理的安全默认设置已成为次要目标，但其原则始终是让用户可以选择以他们认为合适、安全或不安全的任何方式配置软件。
我们目前也生活在这样一个世界中，CVE 既容易被个人和公司筹集，也很有价值，因为它们具有可信度和缓存。这种独特的组合可能会导致有问题的分配。另一方面，拥有无摩擦地报告潜在安全问题的能力只能是一件积极的事情，因此我们面临着一些悖论。
作为一个行业，我们在识别漏洞方面做得越来越好，同时创建了大量更多的软件，因此很容易看到过载的可能性。
正确识别软件中的漏洞、评估它们并提供缓解措施是一个非常耗费资源的过程，而且主要是手动的，尤其是对于复杂的情况。虽然机器学习方法变得越来越有用，而且人工智能可能会被证明更有价值，但在许多情况下（具有讽刺意味的是）计算机在诊断方面对我们来说并没有那么有用。
展望未来
此处概述的讨论要点并非旨在改变任何特定的 CVE，而是为了开启关于漏洞评估的未来以及我们现在和未来认为的不安全因素的对话。构建适用于通用用例的强大且通用的开源软件不可避免地会产生可配置的模式，这些模式提供或多或少的安全性。如果我们想继续这样做，那么用户也有责任了解使用中的陷阱。也许答案是更好的文档和教育，以及对正常用例中的潜在漏洞进行分类。
参考：https://snyk.io/blog/when-is-a-cve-not-a-cve/
原创文章，作者：CNCSO，如若转载，请注明出处：https://cncso.com/security-of-context.html
