底线：你完蛋了。如果您担心其中一位开发人员故意在该代码库中隐藏了后门，那么您就无法判断是否存在后门。生活糟透了。

评论：这里的一些人建议您可以通过查看代码或使用静态分析工具等来检查后门。不要相信。如果他们认为这很可能会检测到故意隐藏的后门，那他们就是在自欺欺人。在我看来，这些答案过于乐观，可能会给你一种错误的安全感。（我知道我这样说和诋毁其他评论员会让自己不受欢迎，但我觉得有责任给你我诚实、坦率的建议。）

建议和缓解措施：至于你应该做什么，我认为你需要告诉我们更多关于该软件的功能，它与你的业务的关系，以及如果它确实有后门会有什么后果。以下是您可以考虑的一些通用缓解措施，它们可能与您相关，也可能与您无关，具体取决于具体情况：

• 风险转移。要求供应商提供代码没有后门的保证，如果发现有重大经济处罚条款。（请注意，如果存在后门，则发现它的机会非常低，因此发现后门的惩罚必须与检测到它的概率的倒数成正比。）

• 隔离。您可以尝试隔离后门的影响，使其只能影响该软件的功能，并且攻击您的其他系统的机会有限。您可以在虚拟机中运行它，将其与网络隔离，等等。您还可以将其与网络隔离，以使坏人更难激活后门。

• 监测。在某些情况下，可以执行外部监控以检测非法活动。例如，在老虎机联合中，您可以监控入金金额、支付金额，从统计上看，这两者应该具有很强的关系；如果您看到支出超过预期金额超过五个标准偏差，这可能是一个很好的理由来担心。再举一个例子，在银行，您可以使用复式簿记并跟踪一些综合指标，例如消费者投诉率和消费者对收费提出异议的频率。这些类型的监控技术高度特定于您的特定业务，但可能有效地检测恶作剧。

请记住，这些都不能很好地防御蓄意的后门，它们可能适用于任何特定情况，也可能不适用，但如果你幸运的话，它们可能总比没有好。

我将从结构概述开始 - 从设计的角度来看，代码的单独部分是否定义良好？例如，您是否有在整个代码库中用于这些目的的验证代码、输入和输出函数等，或者每个函数都是独立的？您是否有功能安全的代码（通常某些样式结构不会影响数据流的安全性）

例如，如果您有一个对每个功能执行身份验证的安全包装器，您可以快速查看这些功能并检查包装器功能的使用情况。

如果它是一个非常大的代码库，那么您将需要运行诸如 Fortify 之类的工具（或其他 @AviD 将能够命名的工具 :-) 来解决问题，但所有工具都缺乏上下文智能。它们根据典型签名进行识别，因此您会得到误报（可能还有误报 - 这就是为什么拥有良好的概述可以帮助您识别工具无法发现的风险）

这个想法是，该工具缩小了可能的风险区域并识别了绝大多数问题，因为工具相对便宜，然后人工验证并添加到工具的输出中，将其置于应用程序环境的上下文中。

冒着听起来过于商业化的风险，我建议使用经验丰富的安全顾问的服务，他不仅对代码审查工具了如指掌，精通 Java + Oracle，而且在基于业务和安全风险的架构方面也有经验。

@Rory 几乎涵盖了如何进行审查......

我只想补充一点，您应该知道您在寻找什么，而不仅仅是一般的“后门”（类似于@VP01 在顶部评论中所说的）。

例如，您是否正在寻找执行以下操作的后门：

• 身份验证绕过（通过特殊身份或超级密码）；
• 魔术参数 (ala "?admin=1");
• 偷便士（就像在超人 3 中一样）；
• 信息窃取（例如在后端通过电子邮件发送信用卡号）；
• ……别的东西。

如果您知道您正在寻找什么类型的后门，您就不必同等关注数百万行代码中的每一行，并且可以确定优先级。

我还要补充一点，有一些自动化工具可以编写非常丰富的脚本，因此它支持根据人类智能和上下文查找您定义的那些特定类型的后门，然后将其应用于数百万个 LOC 中。 .

PS您可能对以下一些相关问题感兴趣：

• 代码审查策略
• 用于扫描源代码漏洞的优秀开源工具？
• 寻找安全顾问进行深入的代码审查？

我认为 Rory 的回答触及了内核，但这里的时机非常重要。之后要进行代码审查，代码已经很庞大，文档记录很差，测试也很差，在生产中（我不知道这里是否是这种情况）已经几乎“为时已晚”而无法做到这一点。即使使用最好的工具和 Java/Oracle 外部分析师也将更难理解业务逻辑缺陷（故意植入那里）。在我看来，从一开始就进行代码分析是要走的路。