在当前的网络空间形势下，软件开发者需要在开发阶段就考虑到安全问题，因此应用程序上线前针对各种法律法规的合规测试也极为重要。合规测试实施起来困难且耗时，测试结果也常常受人为影响。

一月份，西雅图一家软件自动化公司 Chef Software 进行了一项调查，结果显示 74％ 的开发团队需要手动评估软件合规性问题，其中一半都需要手动补救问题。此外，59％ 的组织没有评估代码合规性就投入生产运营；而一旦出现问题，有 58％ 的组织需要花费几天时间才能解决。而 Chef 公司发布的 InSpec 2.0 工具可以将法律法规整合进开发部署阶段，甚至实现自动化操作，进而大大节省人力，促进 DevSecOps 的发展。

本月早些时候，AWS S3 存储桶中又暴露了两个独立的数据库。而有安全研究人员表示，上周，联邦快递也加入了泄露大家族，其数据库在 AWS S3 上泄露，泄露的内容包括“美国和国际公民扫描的超过 119,000 份文件，包含护照、驾驶执照和安全 ID 等信息。”

上述案例以及 2017 年其他 AWS S3 相关的数据泄露事件都有一个共同且简单的原因：数据库设置为公开访问。而由此造成的潜在合规影响则非常复杂。例如，如果联邦快递泄露的“国际公民”信息有一个是欧盟公民信息，欧盟的“一般数据保护条例”（GDPR，2018 年 5 月生效）就可能使联邦快递承担高达其全球收入 4％ 的罚款。联邦快递 2017 年的收入约为 600 亿美元，因此可能涉及的罚款就会达到 24 亿美元。

事实上，大部分数据泄露的原因很可能只是简单的人为错误，这也恰恰反映了安全与合规的软件开发中一个更大的问题：它涉及多个利益相关者，具有不同的优先级，并在一定程度上涉及不同的表达语言。

Chef 公司的产品营销总监 Julian Dunn 表示：

高级别合规官员通常在高度模糊的 Word 文档中明确规定合规性要求。但是在实施层面上，一个企业就算有负责系统的 DevOps 人员，但他们不理解含糊不清的 Word 文档，他们只了解代码、计算机系统和应用程序。每个人都使用不同的工具，因此导致沟通失败，进而只会减慢整个合规过程。

借由调查报告的发布，Chef Software 也宣布上线其 InSpec 2.0 合规自动化产品。2015 年，Chef Software 收购德国初创公司 VulcanoSec 后，在 VulcanoSec 已有技术的基础上发展出了 InSpec 技术。最新版本的 Inspect 提升了性能并增加了新的线程。 Chef 声称，与 InSpec 1.0 相比， InSpec 2.0 在 Windows 上的性能提升了 90%（在 Linux/Unix上提升了 30％）。InSpec 的一大用途是解决 2017 年问题频发的 AWS S3 存储桶的合规性问题。

InSpec 2.0 可以验证 AWS 和 Azure 策略（甚至能移除意外公开访问的 S3 存储桶中的敏感数据），还更新了 30 多内置资源。它提供了一个简单易懂的代码类方法来定义合规要求，然后定期检查公司的基础设施（包括云和本地）是否符合要求。这种代码语言中的“it {should have_mfa_enabled}”和“it {should_not have_access_key}”等代码可以解决 AWS S3 存储桶暴露的问题。

此外，合规制度要求数据库设置访问控制。在 Red Hat Linux 系统中，InSpec 代码包含“control ‘ensure_selinux_installed’do”和“it {should be_installed}”。

然后，InSpec 会定期检查基础架构，并检测是否遵守合规规定或细则的要求，这也是 InSpec 循环过程中“检测、修正、自动化”的一部分。检测有助于相关人员看见当前的合规状态，以完成审计、推动决策；修正则是纠正问题以提高性能和安全性；自动化可以加快应用程序部署和持续性的代码风险管理。

InSpec 可以在自动化阶段帮助客户，提供符合常规法规要求的预定义配置文件。不过 InSpec 从根本上说是一种通用的工具包，用于表达规则以及规则所带来的积极和消极的结果，因此它可以处理软合规（法规）也可以搞定 GDPR、PCI、SOX 等大部头的法律。

前几年，软件开发一直推崇 DevOps，以避免孤立的软件开发与部署。而现在越来越多的安全法规也在推动 DevSecOps 的发展，将安全融入开发部署之中。 InSpec 工具能自动将安全和合规融入代码开发过程，形成一个功能完善的 DevSecOps 环境，不但没有抑制反而是提升了软件开发的敏捷性，这也是 InSpec 2.0 的另一个自动成效，推动了 DevSecOps 的发展。