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

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

送货

让我们从交货的那一头开始,一路往回走。这里的基本措施是对二进制文件进行签名。任何关心的人都应该能够验证该签名的真实性,以及该特定签名的含义(这是一个受支持的版本,或者这是由我们生成的,或者其他任何可能的版本)。这意味着公钥应该广泛分布,与所传递的二进制文件分开。这可以通过与客户的预先安排,也可以通过第三方签署的证书。在这两种情况下,如果您关心的话,验证签名应该是您的客户执行的验收过程中的常规部分。对于真正的偏执狂( 咳嗽 苹果 咳嗽 ,硬件可以进行签名检查。

汇编

现在回顾一下二进制文件的过去:二进制文件是通过什么过程生成的?它是在安全的生成服务器上编译和签名的吗?随机开发人员是否单击了IDE工具栏中的“构建”?对于非生产版本,可以使用随机开发人员生成的二进制文件。签署发布版本的密钥可能只对自动生成过程可用。然后,您可以集中精力确保一个或几个幸运的构建机器的安全性。另外,拥有指定的构建系统也是一个实施自动化测试并确保使用经过验证的工具链(编译器版本等)的机会。通过非常有限的网络访问、对登录的严格授权和审核、入侵检测等,全力以赴保护这些机器可能是有意义的。

再向后看,正在构建什么代码?所有主要的开源项目都发布了由GPG签名的tarballs发布的源文件。那些使用像git和mercurial这样流行的dvc的用户在存储库中支持类似的签名标签。对于将二进制文件作为发行版签名的构建系统,它应该检查它是否正在构建声明版本的正确签名的源文件,以及签名是否来自授权发布的人。

整合

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

“谁写的”(或现实地说(除非你在他们的肩上看着),“谁会为它担保”)部分很简单:强制对存储库的任何写访问进行强身份验证和审计日志记录。这可以是密码、ssh密钥、gpg签名(同样是签名标签)、otp密码令牌等。整个行业都围绕提供身份验证而构建。

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

发展

至于如何编写代码,这取决于开发人员的良好理解。很多人已经详细地写了开发过程、工具和技术。