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