问题描述
对ISO 27001的背景和DevOps之间的关系有疑问。ISO 27001主要涉及组织和运营方面，听起来有点抽象和规范化。而在DevOps中，特别是在DevSecOps中，对于确保不向客户交付漏洞存在着积极和非常具体的需求。这两个领域如何结合在一起？在安全审计中，安全审计员是否会询问以下问题：
– “作为组件依赖管理的一部分，您是否进行了漏洞扫描？”
– “您是否检查了API是否存在OWASP漏洞？”
– “您是否扫描了Docker镜像，并了解与基础镜像相关的风险？”
解决方案
请注意以下操作注意版本差异及修改前做好备份。
背景知识
根据我的经验，审计员倾向于遵循自上而下的风险评估流程，他们会审查公司或系统的业务和IT的固有风险，然后查看公司为减轻固有风险而采取的控制措施以及剩余风险。自上而下的风险评估与大多数技术人员的工作方式相反，我们会从具体的漏洞、缺陷和设计缺陷开始，然后以自下而上的方式逐步推进。这两种方法都有其适用的场景。
ISO 27001和DevOps的结合
ISO 27001和大多数标准一样，并不是具体的规定，而是旨在提供一种标准的商业语言，以便实现业务/IT与审计员之间的沟通。实施任何标准通常是识别满足标准要求的现有流程并对其进行记录，然后查找任何缺陷或漏洞并加以修补。同样的逻辑也适用于ISO 9000、ITIL、COBIT、COSO等标准，很少是强制执行某些预定义的流程，而是要在审计员寻找的内容和企业正在做的内容之间建立映射。
安全审计中的问题
在安全审计中，审计员通常不会询问特定领域的问题，比如”您是否检查了API是否存在OWASP漏洞”，而是会询问类似”您有哪些控制措施来减轻由于软件漏洞导致的数据丢失风险”的问题。这意味着审计员更关注的是数据丢失的风险，而不是特定的技术细节。因此，在安全审计中，DevSecOps可能在概念上是”隐形”的。
DevSecOps的可见性
理论上，DevSecOps应该是隐形的，但不幸的是，通常需要向内部和外部审计解释很多，因为你打破了他们对”对与错”的心理模型。此外，你还需要考虑整个系统，即系统思维，例如，审计员可能会指出代码进入生产环境的变更管理流程无效，因为它不需要人工干预，你需要解释”第二双眼睛”已经通过Pull Requests或者Pair Programming移到了开发阶段。
总结
ISO 27001和DevOps之间的关系是通过将审计员的期望与企业正在实施的流程进行映射来实现的。在安全审计中，审计员更关注的是风险管理和控制措施，而不是特定的技术细节。因此，DevSecOps在审计中可能是”隐形”的，但需要向审计员解释和展示整个系统的安全控制措施。
以上是关于DevOps在ISO 27001安全审计中的背景和解决方案。希望对你有所帮助！