软件开发和交付过程中的高完整性/信息保证

Question

假设您为一个客户进行开发，该客户需要您交付给他们的软件的出处和流程遵从性的最大保证。开发组织可以采取什么措施来提供高完整性软件？

这篇文章最初的灵感来自于ServerFault的一篇关于开发系统安全实践的couple questions。

Answer 1

我在这里提到的每一件事都有一系列的可能性，它们的适用性取决于您的预算以及您和您的客户所希望的保证程度。下面的许多步骤都涉及到加密散列和签名的应用，这不是偶然的。应用了适当的技术控制，它们代表了一个明确的标记，即无论谁(或任何机器)拥有签名密钥，都确认了该过程得到了正确的遵循。

交付

让我们从交付端开始，然后返回。这里的基本措施是对二进制文件进行签名。任何关心的人都应该能够验证签名的真实性，以及特定签名的含义(这是一个受支持的版本，或者这是由我们生成的，或者任何其他可能的东西).That意味着公钥应该被广泛分发，与交付的二进制文件分开。这可以通过与客户预先安排，也可以通过第三方签署的证书。在任何一种情况下，如果您关心，验证签名应该是您的客户执行的接受过程的常规部分。对于真正的偏执狂(咳嗽)，硬件可以做签名检查。

编译

现在让我们回顾一下二进制文件的过去:这个二进制文件是由什么进程生成的？它是在安全的构建服务器上编译和签名的吗？是不是某个开发人员随机点击了IDE工具栏中的“Build”？对于非生产版本，使用随机开发人员生成的二进制文件可能是可以接受的。用于签署发布版本的密钥可能只对自动构建过程可用。然后，您可以专注于确保一台或几台幸运的构建机器的安全性。顺便说一句，拥有指定的构建系统也是执行自动化测试并确保使用经过验证的工具链(编译器版本等)的机会。全力以赴保护这些机器可能是有意义的，因为这些机器的网络访问非常有限，登录时严格的授权和审计，入侵检测等。

再往后看，正在构建的是什么代码？所有主要的开源项目都发布了GPG签名的已发布源代码归档的tarball。那些使用流行的DVCS的人，比如Git和Mercurial，在存储库本身中支持类似的签名标记。对于将二进制文件签名为发行版的构建系统，它应该检查它正在构建声明版本的正确签名的源代码，并且签名来自授权发布的人。

集成

代码从何而来？嗯，人们编写它，然后将其提交到存储库。在将任何代码集成到发布分支之前，您可能需要采取措施来验证是谁编写的代码，以及它是否符合您的质量标准。

“谁写的”(或者现实地说，“谁来担保”)部分很简单:对存储库的任何写访问强制执行强身份验证和审计日志。这可以是密码、SSH密钥、GPG签名(也是签名标签)、OTP加密令牌等。

“达到质量标准”可能需要更多的努力。如果您有必须通过的测试，集成过程需要检查这一点。持续集成工具在这里非常有用。如果代码必须通过检查(也就是审查)，那么集成应该是一个积极的检查报告的直接结果。要查看此类策略的示例实现，请查看Gerrit。

开发

至于代码是如何编写的，这取决于您的开发人员是否明智。很多人都写了很多关于开发过程、工具和技术的文章。