软件完整性标准中是时候将质量与安全放在同等位置了。

软件彻底改变了传统产品开发过程，是将公司企业区分为三六九等的终极竞争优势。但再好的东西，用对了才是真的好。

软件可不是简单发售就行的东西，你得交付高质量安全软件，实现可衡量的业务优势，比如生产力增长、总拥有成本（TCO）降低。以有意义的方式让最终用户的生活更轻松惬意，才是软件的终极目标。

但是，“高质量”、“安全”软件到底何解？高质量软件是否就天然安全？如果真的安全，又是否能认为本来质量就高呢？质量和安全是一回事吗？好吧，情况真心复杂。但对于负责确保软件开发安全的CISO来说，弄清这些问题至关重要。

先定义再衡量

因为无法衡量连定义都没有的东西，所以我们先从定义开始。高质量软件可基于业务功能按预期设计和目的执行。

安全软件不会将系统或数据置于未授权访问的风险之中。质量与安全之间关系明显：美国质量协会的权威指南中明确指出，安全是软件质量的关键要素。

“不关我事”要不得

质量与安全难题是历史原因造成的。线性瀑布式开发时代以来，质量一直是开发团队的最高准则。开发团队无需考虑安全，那是安全团队的工作。与此同时，安全工作独立开展，但免不了最后关头横插一杠堵漏洞，拖慢开发进程，造成团队间摩擦。

时至今日，我们很容易看出为什么这种模式不再有效。仅2019年上半年，就有3813起安全事件曝光，泄露了超过41亿条记录，受害公司企业平均损失320万美元。这还仅仅是我们所知的事件。公司企业无法承担枉顾安全的后果——业务和声誉风险太高了。

各种问题

是人就难免犯错。而且，很多团队压根儿就没有工具或能力来创建没有错误的代码。再加上项目推进不断加快的持续压力，质量问题可能很快转化为安全噩梦。许多安全事件可追溯到代码漏洞（导致软件偏离既定用途的那些），或者潜在质量缺陷（例如未能正确基于数据描述代码，或充分验证和过滤输入）。即使代码设计完美，也只需要一次跨站脚本（XSS）攻击，就能引发安全事件。可以说，恶意代码注入不仅仅是个安全问题，也是个重大质量问题。

公司企业创建软件是为了满足客户的需求。这是软件的主要业务功能。如果我们认同这一点，那我们就不能忽视不安全的软件。

四步实现DevSecOps

软件安全人人有责。当前的现实要求开发、安全和运营相互融合协同，安全也终于摆正了自己的位置——与质量平起平坐。尽管DevSecOps方法仍然相对较新，但如今有8%的公司通过这一实践保护不低于75%的云原生应用。DevSecOps的吸引力与日俱增，采用这种方法的公司企业比例有望在两年内跃升到68%。

但这不是一朝一夕的事。接受新模式需要转变企业文化：开发人员必须认同高质量软件建立在开发各阶段内置安全的基础之上。不仅如此，开发人员还需要将安全视为自身工作的重要部分。

公司企业可以采取以下四个具体步骤来转变心态和推动转型：

  • 采用自上而下的方法。“安全人人有责”的思维应始于（源自）高层。

  • 开发人员培训加入安全内容。例如，进行“事后”教育、共享源代码存储库，以及建立身份验证/加密库。

  • 在整个开发过程中嵌入贯穿一致的安全。在整个软件开发生命周期（SDLC）中持续集成安全扫描，并以集中统一的方式监测所有问题，以便密切检测漏洞并维护完整的风险视图。

  • 利用自动化。自动化测试每次代码提交，有助于更早捕获漏洞和去芜存菁，让开发人员可按轻重缓急处理手头工作。

质量须转化为安全的产品。随着DevSecOps地位渐稳，是时候将质量和安全并列于软件完整性的指标下了。阐明这种共生关系对公司的价值，确保软件能够同时履行其满足客户需求和保护客户的终极业务功能，则是CISO的职责所在。

声明：本文来自数世咨询，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。