你不能审查单独的代码行。你只会死去尝试这样做。

在某些时候，你必须相信别人。1984 年，大部分 Unix 的共同发明者之一肯·汤普森（Ken Thompson）写了一篇关于信任限制的短文。在某些时候，你必须相信其他人，你必须相信编写你的文本编辑器的人不会自动隐藏一些木马代码，PHP 解释器将在某些比特币窃取恶意软件中执行这些代码。

您必须进行成本效益分析，以确定您审查的内容的优先级。

在大多数情况下，您应该尽最大努力审查代码的作者、项目的内部安全实践以及代码如何到达您的手中。实际上，审查代码既昂贵又困难，因此应该将它们保留给您认为对您的项目最重要的部分。

图书馆是一个受欢迎的图书馆，被很多人使用，拥有一家受人尊敬的公司或知名的项目负责人吗？项目是否有适当的项目管理流程？图书馆过去是否有良好的安全问题历史，他们是如何处理这些问题的？它是否有测试来涵盖它需要处理的所有行为？它是否通过了自己的测试？然后，图书馆在没有任何人注意到的情况下被入侵的风险就会降低。

获取一些示例文件以进行更深入的审查。你看到有什么关于那里的吗？如果您使用的少数文件有重大问题，您可能可以推断代码库的其余部分也存在类似问题；如果它们看起来不错，那么它会提高您对代码库的其余部分编写得同样出色的信心。请注意，在非常大的代码库中，代码的不同区域会有不同的代码质量级别。

您的包管理器存储库是否检查包签名？是否需要预先审查系统才能将包注册到存储库中，还是开放注册存储库？您收到的库是源代码形式还是预编译二进制文件？这些会影响您对图书馆的信任程度、风险因素以及如何进一步提高信任度。

您还必须考虑应用程序和应用程序将在其上运行的执行环境。这是为了国家安全代码吗？此代码处理电子商务或银行处理信用卡号码的一部分吗？此代码是否以超级用户身份运行？此代码对生命/安全至关重要吗？您是否有补偿控制来隔离和运行具有不同权限（例如容器、VM、用户权限）的代码？此代码用于周末项目吗？你如何回答这些问题应该让你定义一个预算，你可以在审查代码上投入多少，因此如何确定哪些库需要审查的优先级，在什么级别，以及哪些在信任度较低的情况下可以接受。

我的“Composer”目录树目前有超过 120,000 行代码。这就是我需要的最少数量的关键 PHP 库。

你的错误在于试图审查第三方代码，就好像它是你自己的一样。你不能也不应该尝试这样做。

您没有按名称提及任何库，但我假设其中有相当一部分是因为您使用的是较大的框架之一，例如Laravel或Symfony。像这样的框架，与其他主要库一样，都有自己的安全团队；问题可以快速修复，安装更新也很简单（只要您使用受支持的版本）。

与其尝试自己审查所有代码，不如放手并相信供应商已经完成 - 并将继续 - 为您审查。毕竟，这也是您使用第三方代码的原因之一。

实际上，您应该像对待.NET或 Java等编译环境中的第三方库一样对待第三方 PHP 库。在这些平台中，库以 DLL 文件或类似文件的形式出现，您可能永远无法看到源代码。你不能审查他们，你不会尝试。如果您对 PHP 库的态度与此不同，那么您需要问自己为什么。仅仅因为您可以阅读代码并不意味着您可以从中获得任何收益。

当然，如果您的第三方库包含不受支持或没有安全策略的较小的库，这一切都会失败。因此，这就是您需要对您正在使用的所有库提出的问题：它们是否完全受支持，它们是否具有您满意的安全策略。对于任何不这样做的人，您可能需要考虑寻找这些库的替代品。但这仍然不意味着您应该尝试自己审查它们，除非您真的打算接管对它们的支持。

不过，我要补充一点：如果您想对您的 PHP 代码进行安全审计，我强烈建议您使用RIPS 扫描仪。它并不便宜，但如果你有很强的安全要求，它很容易成为你可以为 PHP 获得的最好的自动化安全分析工具。绝对在您自己的代码上运行它；您可能会惊讶于它发现了多少问题。当然，如果您足够偏执，您也可以在您的第三方库上运行它。不过，这会花费您更多，而且我的上述观点仍然有效；你真的应该相信你的第三方供应商会为自己做这种事情。

欢迎来到新的编码范例：您在库之上使用库。您并不孤单，但您还需要了解，无论何时引入不是您编写的代码，都会带来一些风险。

您的实际问题是我如何管理这种风险？

了解您的软件应该做什么

很多时候，库管理器成为一种方便的方式，可以让代码“正常工作”，而无需费心从高层次上理解它应该做什么。因此，当您信任的库代码做坏事时，您会措手不及，想知道发生了什么。这是单元测试可以提供帮助的地方，因为它测试代码应该做什么。

了解您的来源

Composer（或任何包管理器）可以从您指定的任何来源安装，包括昨天由完全未知来源汇总的库。我愿意从有 SDK 的供应商那里安装软件包，因为供应商是一个高度信任的来源。我还使用了来自执行其他受信任工作的源的包（即 PHP 项目中的某个人有一个库 repo）。盲目相信任何来源都会给你带来麻烦。

接受您永远无法完全减轻的风险

2016 年，一位 NodeJS 开发人员在退出项目并要求取消发布他们的库时破坏了大量的包。他们有一个简单的库，数百个其他包被列为依赖项。或者，也许基础设施不是为了处理包分发而构建的，所以它随机失败。互联网在分布式软件开发世界中“让事情运转”变得如此出色，以至于当它停止工作时，人们往往会感到不安或困惑。

当 PHP 7.0 出现时，我不得不做大量的工作来制作我们在 7.0 环境中使用的开源第三方软件包。我花了一些时间，但我能够帮助该软件包的作者解决一些问题并使其在 7.0 环境中可用。替代方案是替换它……这将花费更多时间。这是我们接受的风险，因为该软件包非常有用。

然而，最基本的安全问题仍然存在：我不知道这个“安装”的代码包含什么，也不知道每次更新添加/更改了什么。有一天，当我的 Composer 获取更新时，其中一位库的作者很容易受到攻击，导致我的 PHP CLI 脚本突然将我的比特币 wallet.dat 发送到某个远程服务器，在我的机器上安装 RAT/木马，甚至更糟。事实上，它可能已经发生了，我也不会更聪明。我根本不知道。我在逻辑上无法有任何想法。

查看Heartbleed，OpenSSL 中的巨大安全漏洞。Heartbleed 有效地削弱了 SSL，首先将最后的数百或数千（网络加密）事务保存为纯文本，然后为任何知道它的人留下一个简单且未记录的设施，以便远程连接并检索用户认为的所有内存缓存事务以纯文本形式安全加密。到那时，OpenSSL 正在保护绝大多数自托管网站和大量银行甚至政府情报服务。

然后查找Meltdown和Spectre，这是现代英特尔 CPU 中内置的大量错误。Meltdown 和 Spectre 完全抵消了在保护模式下运行 CPU 的效果，并且独立于操作系统，可在每个操作系统上利用。

多年前，一个名为MSBlaster的恶意软件利用了一个（我什至不确定这是一个错误 - 只是一个非常愚蠢的）Windows XP 后台服务，该服务甚至默认情况下都没有运行 - 它只会被积极使用绝大多数 Windows 用户，然后只有 IT 部门知道。这最终促使 ISP 发布了内置在其调制解调器设备中的硬件防火墙，并促使微软将内置软件防火墙嵌入到他们的操作系统中。大约在同一时间，据称“防病毒”Linux 平台的一个发行版被发现在主要发行版中包含一个内置的 rootkit。

正如其他人所说：您必须在某个时候信任某人。意外和恶意都会导致问题。我和你一样 - X-Files和Uplink的忠实粉丝（不要相信任何人！） - 但现实情况是你的 SSL 加密引擎或你的物理硬件设备同样可能存在安全漏洞，而且这些漏洞的可能性更大当它们出现时代表关键任务故障。

如果您真的想加倍努力为您和您的用户的安全重新发明 Composer 轮子，那么请认真考虑加倍努力：设计您自己的 CPU、主板、RAM、HDD 和光驱。编写自己的操作系统和硬件驱动程序。也制作自己的编译器。并且忘记 PHP，因为解释器中可能存在问题 - 事实上，也忘记 C 和 C++，因为编译器中可能存在问题，甚至不要考虑使用其他人编写的汇编器的汇编语言。使用十六进制编辑器从头开始以机器指令编写您自己的所有软件。

或者你可以表现得像这个行业的一员。订阅 Composer's/PHP's/YourLinuxDistro's 的更新时事通讯，也许还能加入一些基于安全的独立时事通讯，并订阅Wired。查看您的系统日志。定期使用 PCAP 测试您的网络，以确保没有任何未经授权的网络流进出。积极主动地监控可能的威胁，不要偏执于尚未发生的事情。