有自动和手动方法。

对于自动化，您可以从lgtm - 用于开源项目的免费静态代码分析器开始，然后转向更复杂的 SAST 解决方案。

对于手动 - 您可以构建应用程序的威胁模型，并从最关键的部分开始通过OWASP ASVS清单运行它。如果您的威胁模型中有文件删除 - 只需调用如下内容：grep -ir 'os.remove('.

当然，最好将两者结合起来。

你要么自己做，要么相信别人

与生活中的大多数事情一样，你必须要么自己做，要么相信别人。这里的信任既包括没有恶意，又包括足够的能力来正确执行任务。

例如，您可以自己报税或委托税务顾问来报税（他们不仅不应该试图欺骗您，而且还知道如何报税！）。

如果您是一家公司，那么您自己的工作实际上将由您的一名或多名员工执行，而这些员工又需要被信任。

您信任的第三方也不必是一个人。它可能是Microsoft Windows 开发团队，也可能是Wordpress 核心开发人员。

在源代码安全方面，您希望专家不仅善意，而且知识渊博，能够以安全的方式对程序进行编码/发现可能存在的任何潜在安全问题。

（加上一些额外的边界系统，当作为一个整体对待时，例如，您希望他们的代码在将其上传到存储库时不会受到损害，或者您员工的电子邮件说明结果被您网络内的恶意黑客替换说应用程序很好）

您将需要评估您的选择，评估与每个选项相关的风险，并选择最适合您的兴趣（和预算！）的路径。

如果我要检查使用 Wordpress 的博客的源代码的安全性，我通常会相信原始代码是好的1¹，并检查正式版本和使用的版本之间的差异。如果该网站被入侵，那将更容易找到。

¹如果使用过时的版本，显然检查更高版本的变更日志。

但是，如果它是由所有者的侄子开发的，我预计会在那里发现很多漏洞，并建议对所有内容进行彻底检查。

在您的情况下，您应该评估开发该库的等价物的风险和成本（考虑到您的内部产品中出现问题的可能性也不为零，而且它取决于 - 除其他外 - 的质量相关人员）与审计和使用该库的风险和成本。

现在，可能存在简化审计的衰减因素。例如，如果不受信任的代码可以在隔离的虚拟机中运行，那可能就足以不需要进一步的审计（即使在这里，您也信任虚拟机实现）。或者，审计以 root 身份运行的程序部分可能被认为是足够的。

对于审核库，代码分析器可以帮助指出有问题的部分（如所指出的那样），但为了认为它是干净的，我实际上会让某人阅读并理解代码，即使是表面上的。

例如，删除任意文件的能力本身并不是恶意的。您需要了解该程序才能知道它是否有意义。

同样，这是您正在做的事情的威胁和风险的问题。如果您只关心库泄露数据，那么在防火墙处过滤连接就足够了。如果您担心库会删除重要文件（出于某种奇怪的原因，您不能拒绝此类权限），您可以简单地滚动一堆只进行数学计算的代码。如果该库计算发射火箭的参数……那么，您最好确保这些计算也是正确的！

使用服务

有诸如Black Duck和Whitesource 之类的专业服务可以审计开源依赖项。

如果您使用其他人的代码，那么您或多或少会受到维护者提供的完整性机制的支配——所有软件都是如此，而不仅仅是开源。

对于商业和打包的开源软件（即 rpm、deb 等），代码签名很常见 - 这证明您收到的正是签名者希望您收到的内容。

在源代码的情况下，通常使用校验和。但这没有什么价值，除非可以从源代码的不同来源访问校验和。

请注意，这些只是为了防止对应用程序的 MITM 类型的攻击。

使用托管在 GitHub 上的任意库

...在这种情况下，所有文件/版本都有一个在 Github 上发布的哈希值——为了破坏它，攻击者需要破坏 Github 本身或维护者的 Github 帐户——我可以在 Github 上分叉任何东西，但它被归因于我和原始存储库不受影响，除非维护者接受我的拉取请求。与代码的维护者相比，您可能对 Github 的完整性更有信心，在这种情况下，信任与源代码发布在同一位置的哈希是合理的。

这些机制都没有提供针对在应用完整性验证之前注入的恶意软件的保护。

在您可以访问源代码的地方，您可以选择检查代码（这比检查可执行文件要容易得多），并且可以使用诸如 odo 建议的自动化工具来执行此操作。