这一切都取决于审计的范围。

如果审计纯粹是代码（即给审计员一份代码副本，他们审计并返回报告），那么事后篡改它可能很容易。

如果审计更全面一些，包括代码开发、测试和升级到实时环境程序，那么您应该能够排除大多数篡改发生的机会。

如果您额外审核正在进行的变更管理流程，并对实时代码进行定期确认检查，那么您可以更加确信实时代码是开发和测试的代码，并且适合目的。

这就是为什么有限范围的审计基本上是无用的，除了在方框中打勾（这可能有用......）

这完全取决于您的信任边界在哪里。我建议阅读Ken Thompson [ 1 ]的关于信任的思考。

希望审计员提供被审计文件或源的签名或哈希；通过这种方式，您至少可以验证您实际上运行的是与审查过的代码相同的代码。

但是，即使您不信任审核员并且您自己从您知道好的源代码编译它（我们会假装您真的很擅长发现可能旨在隐藏它们的代码中的威胁），您仍然必须相信你的编译器。或者，如果您正在下载由审核员编译的版本，他们的编译器。

虽然这可能是安全的，但最好认识到自己编译并不是万无一失的。你永远不能完全相信任何东西；你必须设置一个信任边界，并决定在什么时候你想接受一些安全的东西。

这就是为什么很多人使用 GIT 和 Jenkings 的原因。这个想法是所有代码都进入一个集中的存储库。没有一个人可以完全访问完整的构建，当程序员提交一段代码时，它会在被推送到分支之前由另一个程序员检查。一名程序员不能随意更改代码或编译。

通常，源代码审计是在编译之前完成的，审计员会在代码编译之前检查代码，未经审计员批准，任何人都不能进行更改。另请注意，审核员不能自己介绍代码。这意味着您不能只提交任何内容。

不幸的是，这是理想的情况，并不是到处都能做到。变更管理的基本概念之一是拥有 3 个环境：

• 发展
• 质量保证
• 生产

在开发中，所有程序员都可以访问，在 QA 中只有少数（尽可能少），而在生产中，没有一个程序员应该可以访问。这一切都建立了合理的保证，但仍然可能存在篡改。最后，您尝试尽可能地承担风险，但没有什么是万无一失的。

我想说，除非他自己构建，否则客户基本上不可能相信构建对应于经过审核的源。即使这不能保证后门或其他不良功能的存在，后门与错误相同 - 你永远无法证明没有后门。

我经常想知道这在完全信任有问题的情况下是如何工作的。当美国向巴基斯坦出售 F-16 时，巴基斯坦人怎么知道航电设备中没有后门可以让他们对隐形直升机视而不见……哎呀。