软件开发和交付过程中的高完整性/信息保证
假设您为客户进行开发，该客户需要最大限度地保证您交付给他们的软件的来源和流程合规性。开发组织可以采取哪些措施来提供高完整性的软件？
这最初是受到夫妇 有关 ServerFault 开发系统安全实践的问题。
Suppose you develop for a customer that requires the utmost assurances of the provenance and process-compliance of the software you deliver to them. What measures can a development organization take to provide high-integrity software?
This was originally inspired by a couple questions about security practices for development systems over at ServerFault.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在这里提到的一切都有多种可能性，其适用性取决于您的预算以及您和您的客户所期望的保证程度。下面的许多步骤都涉及加密哈希和签名的应用，这并非偶然。通过适当的技术控制，它们代表了一个明确的标志，即拥有签名密钥的任何人（或任何机器）都确认该过程得到正确遵循。
交付
让我们从交付端开始，然后再返回。这里的基本措施是签署您的二进制文件。任何关心的人都应该能够验证该签名的真实性以及该特定签名的含义（这是受支持的版本，或者是由我们生成的，或者其他任何可能的版本）。这意味着公钥应该是广泛分布，与交付的二进制文件分开。这可以通过与客户预先安排，也可以通过第三方签名的证书来实现。无论哪种情况，如果您关心的话，验证签名应该是您的客户执行的验收过程的常规部分。对于真正偏执的人（咳嗽苹果咳嗽），硬件可以进行签名检查。
编译
现在回顾一下二进制文件的过去：二进制文件是通过什么过程生成的？它是在安全的构建服务器上编译和签名的吗？随机开发人员是否单击了 IDE 工具栏中的“构建”？对于非生产版本，使用随机开发人员生成的二进制文件可能是可以接受的。签署发布版本的密钥可能只能用于自动构建过程。然后，您可以专注于确保一台或几台受祝福的构建机器的安全性。顺便说一句，拥有指定的构建系统也是执行自动化测试并确保使用经过验证的工具链（编译器版本等）的机会。全力以赴地保护这些机器，通过非常有限的网络访问、严格的登录授权和审核、入侵检测等，可能是有意义的。
再往回看，正在构建什么代码？所有主要开源项目都会发布已发布源存档的 GPG 签名 tarball。那些使用流行的 DVCS（如 Git 和 Mercurial）的人在存储库本身中支持类似签名的标签。对于将二进制文件签名为发布版本的构建系统，它应该检查它是否正在构建正确签名的指定版本的源代码，并且签名来自授权发布版本的人。
集成
代码从哪里来？好吧，人们编写它，然后将其提交到存储库。在将任何代码集成到发布分支之前，您可能需要采取措施来验证该代码的编写者以及它是否符合您的质量标准。
“谁写了它”（或者实际上（除非你在他们的肩膀上监视），“谁将为其提供担保”）部分很简单：对存储库的任何写访问强制执行强身份验证和审核日志记录。这可以是密码、SSH 密钥、GPG 签名（同样是签名标签）、OTP 加密令牌等。整个行业都是围绕提供身份验证而构建的。
“达到质量标准”可能需要付出更多努力。如果您有必须通过的测试，集成过程需要对其进行检查。持续集成工具在这里非常有用。如果代码必须通过检查（又称审查），集成应该是积极检查报告的直接结果。要查看此类策略的示例实现，请查看 Gerrit。
开发
至于如何编写代码，这取决于开发人员的判断力。很多人都详细撰写了有关开发过程、工具和技术的文章。
Everything I mention here has a range of possibilities, whose suitability is up to your budget and the degree of assurance you and your customers desire. Many of the steps below involve applications of cryptographic hashes and signatures, and that's not an accident. Applied with the proper technical controls, they represent an unambiguous mark that whoever (or whatever machine) possessed the signing key affirmed that the process was being followed properly.
Delivery
Let's start at the delivery end, and work our way back. The basic measure here is to sign your binaries. Anyone who cares to should be able to verify the authenticity of that signature, and the meaning of that particular signature (this is a supported release, or this was generated by us, or anything else is possible).That means the public keys should be widely distributed, separate from the delivered binary. That could be by pre-arrangement with your customers, or that could be through a third-party signed certificate. In either case, if you care, verifying the signature should be a routine part of the acceptance process that your customers carry out. For the really paranoid (cough Apple cough), the hardware could do that signature check.
Compilation
Take a step back in the binary's past now: by what process was the binary generated? Was it compiled and signed on a secured build server? Did a random developer click 'Build' in the IDE's toolbar? For non-production builds, it may be acceptable to use binaries generated by random developers. The key for signing release builds should probably only be available to the automated build process. Then, you can focus on ensuring the security of the one or few blessed build machines. As an aside, having designated build systems is also an opportunity to enforce automated tests and ensure the use of a validated tool chain (compiler versions and such). It may make sense to go all-out in protecting these machines, with very limited network access, strict authorization and auditing on logins, intrusion detection, etc.
Going further backward, what code is being built? All of the major open source projects release GPG-signed tarballs of the released source archive. Those using the popular DVCS like Git and Mercurial support similarly signed tags in the repository itself. For the build system to sign a binary as a release, it should have checked that it was building properly signed source of the stated version, and that the signature is from someone authorized to make a release.
Integration
Where does the code come from? Well, people write it and then they commit it to a repository. Before any code gets integrated into a release branch, you'll probably want to take measures to verify both who wrote that code, and that it's up to your quality standards.
The "who wrote it" (or realistically (unless you're watching over their shoulders), "who will vouch for it") part is straightforward: enforce strong authentication and audit logging on any write access to the repository. This can be passwords, SSH keys, GPG signatures (again, signed tags), OTP cryptotokens, etc. There's a whole industry built around providing authentication.
The "up to quality standards" can require somewhat more effort. If you have tests that must pass, the integration process needs to check that. Continuous integration tools can be really helpful here. If code must pass inspection (aka review), integration should be a direct result of a positive inspection report. To see an example implementation for this sort of policy, have a look at Gerrit.
Development
As for how the code gets written, that's up to the good sense of your developers. Plenty of people have written at length about development process, tools, and techniques.