假设您为需要最大程度保证您交付给他们的软件的出处和流程合规性的客户开发。开发组织可以采取哪些措施来提供高度完整的软件？
答案 0 :(得分：3)
我在这里提到的一切都有各种各样的可能性，其适用性取决于您的预算以及您和您的客户所需的保证程度。下面的许多步骤涉及加密哈希和签名的应用，这不是偶然的。应用适当的技术控制，它们代表了一个明确的标记，即任何人（或任何机器）拥有签名密钥都肯定了该过程得到了正确的遵循。
让我们从交付结束开始，然后继续前进。这里的基本措施是签署您的二进制文件。任何关心的人都应该能够验证该签名的真实性，以及该特定签名的含义（这是受支持的版本，或者这是由我们生成的，或者其他任何可能）。这意味着公钥应该是广泛分布，与提供的二进制文件分开。这可以通过与客户预先安排，也可以通过第三方签署的证书进行。在任何一种情况下，如果您在意，验证签名应该是您的客户执行的验收过程的常规部分。对于真正的偏执狂（咳嗽 Apple 咳嗽），硬件可以进行签名检查。
现在退回二进制文件的过去：生成二进制文件的过程是什么？它是在安全的构建服务器上编译和签名的吗？随机开发人员是否在IDE的工具栏中单击“Build”？对于非生产版本，使用随机开发人员生成的二进制文件可能是可以接受的。签署发布版本的关键应该只适用于自动构建过程。然后，您可以专注于确保一个或几个有福的构建机器的安全性。另外，指定构建系统也是实施自动化测试并确保使用经过验证的工具链（编译器版本等）的机会。通过非常有限的网络访问，严格的登录授权和审计，入侵检测等，全面保护这些机器可能是有意义的。
进一步向后，正在构建什么代码？所有主要的开源项目都发布了已发布的源存档的GPG签名的tarball。那些使用流行的DVCS（如Git和Mercurial）的人在存储库本身支持类似的签名标签。对于构建系统将二进制文件签名为发布版本，它应该检查它是否构建了正确签名的所述版本的源，并且签名来自授权发布的版本。
代码来自哪里？好吧，人们写它然后他们将它提交到存储库。在将任何代码集成到发布分支之前，您可能希望采取措施来验证编写该代码的人员，以及它是否符合您的质量标准。
“谁写了”（或者现实地（除非你在监视他们的肩膀），“谁将保证它”）部分是直截了当的：对存储库的任何写访问强制执行强身份验证和审计日志记录。这可以是密码，SSH密钥，GPG签名（再次签名标签），OTP cryptotokens等。整个行业围绕提供身份验证。
“达到质量标准”可能需要更多的努力。如果您必须通过测试，则集成过程需要检查。持续集成工具在这里非常有用。如果代码必须通过检查（也就是审查），则集成应该是正面检查报告的直接结果。要查看此类策略的示例实现，请查看Gerrit。
关于如何编写代码，这取决于开发人员的良好意识。很多人已经详细介绍了开发过程，工具和技术。