如何在不牺牲生产力的情况下构建安全软件

安全与开发效率有时会相互冲突。与其一味预防安全漏洞，不如专注于减轻漏洞的影响，这往往更加高效。Dorota Parad 主张在合规性方面保持灵活性，并与安全团队合作，共同制定实用的保护措施。通过限制漏洞的影响范围和引入自动化手段可以在不牺牲生产力的情况下增强安全性。

在 QCon 旧金山大会上，Dorota Parad 分享了如何在不牺牲生产力的情况下构建安全软件。

安全有时会与快速高效的开发流程相冲突。与其专注于预防漏洞，不如专注于减轻漏洞的影响，这往往更有效。在“确保安全而不损害软件开发生产力”一文中，Dorota Parad 探讨了如何在不损害工程生产力的情况下建立安全基础。

Parad 建议抵制那些阻碍生产力的安全要求，而第一步是了解这些要求的来源：

首席信息安全官（CISO）和安全团队的工作很少真正与安全有关，他们的职责是确保合规。与普遍观点相反，合规并不是简单地勾选复选框，复选框只是达成目标的一种方式。

Parad 表示，最终目标是构建一个能够说服第三方利益相关者（如审计师、监管机构和保险公司）的故事，让他们相信公司已经很好地控制了安全风险。

Parad 指出，没有任何安全认证或法规是绝对规定性的，公司需要自行定义安全的范围、手段和实施方式。这可能是一项艰巨的任务，因此企业可能会为了简化审计流程而采取一些措施，例如强制使用侵入性的移动设备管理（MDM）软件，而不考虑其对工程师生产力的潜在影响。

Parad 建议，如果想摆脱一些令人烦恼的安全要求，就需要与安全团队展开对话，帮助他们构建令人信服的叙事。这包括记录你对本领域风险的看法、缩小安全漏洞影响范围的措施、已实施的保护层级，以及如何最小化事件影响。

Parad 探讨了如何最小化安全漏洞的影响，并以一个常见威胁为例：恶意行为者获取了工程师的云账户凭据：

最坏的情况是什么？如果我们应用了隔舱化（bulkheads）原则，这些凭据的作用范围仅限于一个云账户，而该账户可能（也可能没有）托管我们的生产环境。

Parad 提到，如果我们采用现代软件开发实践，访问权限将仅限于只读和一些无害的配置变更，因为资源的创建和删除将被自动化，并且仅作为 CI/CD 管道的一部分。

如果该账户包含对包含用户数据的数据库的访问权限，并且我们应用了适当的加密措施，那么这些数据对攻击者来说实际上是毫无用处的，Parad 补充道。

Parad 表示，试图预防此类事件将是一项成本高昂的工作，需要针对所有不同的攻击向量进行多次补救。相比之下，限制影响范围是一种全面的解决方案，它不需要付出太多努力或成本，并且通常还会带来额外的健壮性，她总结道。

InfoQ 采访了 Dorota Parad，探讨了如何让安全与工程生产力齐头并进。

InfoQ：你如何看待抵制那些阻碍生产力的安全要求？

Dorota Parad：只有当你有其他方法来最小化安全风险时，才能抵制这些要求。这正是 BLISS 框架（隔舱化、层级化、影响、简化和成功陷阱）的用武之地，它提供了一种不会阻碍工程师工作的替代方案。通过采用 BLISS，你可以让安全策略几乎对工程师不可见，同时将其深深融入企业文化中。

InfoQ：CI/CD 管道能否被视为一种安全实践？

Parad：这有时会让安全人士感到惊讶，但我的回答是肯定的：我认为 CI/CD 管道是一种安全工具。如果实施得当，它能显著降低恶意代码进入生产环境的风险。

典型的构建/部署管道具有层层递进的严格保护层级，代码越接近生产环境，保护层级就越严格。从 Git 访问控制提交代码，到开发者凭据创建拉取请求，再到自动测试发现潜在问题，最后是另一组凭据配合人工审查合并代码。这种方式能有效最小化安全风险。

InfoQ：如何通过 CI/CD 管道来增强安全性？

Parad：每一段代码都需要通过管道才能到达生产环境，没有任何例外。不允许手动干预推动构建通过，不允许跳过步骤，也不允许登录服务器复制文件或运行脚本。

要在实践中实现这一点，唯一的方法是保持 CI/CD 管道的健康和稳健，确保它们只在真正出问题时才会失败。不稳定的管道是安全和生产力的敌人。

【声明：本文由 InfoQ 翻译，未经许可禁止转载。】

原文链接：

https://www.infoq.com/news/2025/07/secure-software-productivity/