是否有某种自动扫描工具可以检测开源 Java 库中的威胁?
我认为 OWASP Orizon 项目试图构建这样一个工具,但它似乎多年来一直处于非活动状态。
我的目标是找到一个指标,可以作为决定“在我的项目中使用库 X 是否安全”的指南......
是否有某种自动扫描工具可以检测开源 Java 库中的威胁?
我认为 OWASP Orizon 项目试图构建这样一个工具,但它似乎多年来一直处于非活动状态。
我的目标是找到一个指标,可以作为决定“在我的项目中使用库 X 是否安全”的指南......
恶意逻辑和后门。您不太可能找到一个自动化工具来自动检测后门、恶意逻辑、定时炸弹等。这些都很难用当前技术检测;隐藏当前分析技术不太可能找到的后门太容易了。(静态分析和动态分析都是如此。)此外,这些类型的后门非常罕见——可能还不足以证明对构建这样一个工具进行大量投资是合理的。
我认为您应该更担心漏洞和错误,而不是恶意放置的后门。它们更常见。而且,如果您处于安全关键环境中,您认为第三方可能会试图故意将后门插入您正在使用的特定代码段中,那么您不应该使用该段代码。代码,除非您信任供应商。
今天,针对恶意后门和定时炸弹的最有效的开发时防御措施如下:
审查开发人员。选择您信任的开发人员。通常,您会希望他们成为您自己的员工。如果您使用外部供应商,则需要仔细审查他们。
强制代码审查。所有代码都应由开发人员以外的第二个人进行审查。软件开发工作流程和存储库应设计为跟踪和执行此策略。这提供了两个人的控制:没有人可以引入未经审查的代码,因此如果每个人都认真对待代码审查的要求,这个过程应该会让一个人更难在不被发现的情况下引入后门。
另请参阅如何审查后门代码?进行相关讨论。
安全的软件存储库。锁定源代码存储库和构建流程,以确保没有任何内部人员可以将恶意代码引入二进制文件。
然而,这些技术的有效性仍然有限。我觉得你也应该看看其他的防御,比如风险转移、隔离和沙盒、监控;我在本网站的其他地方对此进行了详细说明。
错误和漏洞。我建议,在大多数情况下,您应该更加关注错误和漏洞(由善意但容易犯错的开发人员无意中引入)。有许多商业和开源工具用于扫描源代码以检测错误和漏洞。有关商业工具,请参阅行业新闻;查看 Fortify、IBM Appscan、Veracode 及其竞争对手等。商业工具通常优于开源工具。
如果您使用的是第三方开源库,我还建议您检查 CVE 漏洞数据库以获取过去和公开的漏洞报告。查看报告了多少漏洞,报告的速度有多快,以及项目是否有关于漏洞性质的技术细节。这应该让您了解项目的安全立场。
如果您想要更深入地了解,您可以查看Coverity Scan 数据库,看看他们是否已经扫描了图书馆。您还可以查看库的错误跟踪器,了解他们过去是如何处理安全问题的。您可以检查他们是否有明确指示的安全错误报告流程或报告安全错误的地方。这些将使您了解项目的软件开发过程的成熟度及其对安全性的态度。
您还可以找到以下感兴趣的行业白皮书:不安全库的不幸现实。
开源。 您的问题似乎表明您可能认为开放源代码中的后门和定时炸弹比封闭源代码中的威胁更大。虽然这可能是真的,但我不知道有任何证据证明这种说法。如果您担心后门和定时炸弹,您可能应该在您使用的所有代码中担心它,开源或闭源。
我发现的另一个用于安全和缺陷信息的开源存储库是来自Coverity的存储库,但是在各种 linux 发行版中使用了很多开源库,并且在开发中使用了相当多的库。
非常感谢“不安全”开源组件的黑名单,但我找不到。
您可以通过使用策略工具创建安全策略并将其设置为 Java 虚拟机的策略来限制 Java 软件可能执行的操作。这是用于 Java 小程序的安全机制。
你确实说过“开源”。这意味着您手头有 Java 代码。因此,您可以通过使用诸如 JUnit 之类的框架以及大量的手工编码来为 Java 软件创建自动化测试,从而走得更远。您可以使用 Quickcheck 等工具为您的测试进行一定数量的自动化编码。最后,您可以使用像 Cobertura 这样的工具来检查代码的所有行和分支是否都被测试执行了。
如果该测试在您的安全策略范围内成功,那么您已经验证该软件永远不会偏离您的限制。除了实际阅读代码之外,您可能仍然不想取消安全策略的限制。例如,如果您没有成功测试 100% 的软件分支(这通常很难做到),那么该软件仍有可能检测到您的安全策略、JUnit 或 Cobertura 并相应地限制其行为.