朱啸虎|7个关于DevSecOps的认知错误 许多企业都在犯

朱啸虎|7个关于DevSecOps的认知错误 许多企业都在犯

长期以来 , DevOps 团队和安全团队在软件交付上存在一定分歧 , DevOps 团队历来将安全团队视为软件发布的“预防”角色 , 采用过于保守的方法来降低威胁 。 同时 , 安全团队认为加速软件发布给治理、安全和监管控制带来了太大的风险 。 为了调和这两者 , 许多组织试图通过在开发过程的早期就实施安全措施来改变软件的安全性和合规性 。
虽然这种有限的 DevSecOps 方法确实提高了软件的交付质量 , 但它不足以解决全部问题 。 一些具有前瞻性思维的企业已经意识到 , 仅仅将安全性和合规性左移是不够的 , 他们需要将其转移到任何地方 。

通过在端到端的自动化过程中嵌入安全和合规流程 , 企业可以保护整个软件供应链 , 显着改善开发人员体验 , 并加快更安全的交付 。 为了实现这一目标 , 企业需要认识到并克服一系列阻碍他们做出转变的DevSecOps误区 。
误区1:安全性和合规性是软件交付过程中的一个环节 。
现实:许多企业将安全和合规要求视为单独的事件 , 因此会将整个开发团队从原本连贯的项目中抽出来 , 专门去应对审计需求 , 这种方法会显着增加企业的合规成本 。 如果从一开始就没有考虑到安全性 , 那么安全团队就会花费更多时间回过头来解决问题 , 而这些时间不会为组织增加生产价值 。 当安全性和合规性贯穿整个开发流程时 , 它们才是最有效的 。
误区2:添加更多工具将有助于解决安全性和合规性挑战 。
现实:虽然工具肯定可以帮助提高安全性和合规性 , 但通常还需要更多的人来操作这些工具并分析结果 , 然后 , 项目经理凭借这些结果来为开发人员拟定工作优先级 。 更多的工具意味着复杂性的增加 , 通过分析评估并提供企业安全和风险状况的整体视图 , 选择一个恰当、全面的解决方案 , 而不是一组缺乏连贯性和逻辑的工具 , 将会更有效 。
误区3:为开发人员提供安全和合规培训就可以防止违规 。
现实:开发人员绝对应该关注安全性 , DevSecOps 一直强调安全是每个人的责任 , 但是 , 术业有专攻 , 开发人员更专注的是创新和研发 , 而不是运行测试或拆解监管框架 , 期望开发团队在本质工作之外同样高标准地处理安全问题容易扼杀创新和滋生抱怨 , 并且安全效果令人担忧 。
误区4:让安全专家加入 DevOps 团队就可以应对挑战 。
现实:在开发流程闭环内有专门的安全专家有助于让开发人员自由地进行创新 , 但是 , 这种方法仍然会对开发人员造成干扰甚至中断 , 并持续加深两个团队之间的裂痕 。
误解5:我的公司太小不起眼 , 不会成为网络攻击的目标 。
现实:数据泄露给企业机构造成的平均成本高达数百万 , 并且还在迅速上升 。 在这样的暴利面前 , 没有哪家企业会感到高枕无忧 。 所有规模和行业的企业都会面临风险 , 需要认真对待安全问题 。
误区6:如果实现了自动化 , 就是安全且合规的 。
现实:自动化是安全性和合规性的关键 , 但许多自动化工具是过程点位的解决方案 , 而不是端到端的自动化 。 如果企业部署的工具实现了部分环节的自动化 , 那么这些部分将更加安全 。 但是如果自动化的是整个流程 , 那么整个流程将更加安全 。
误区7:拥抱 DevSecOps 就足够了 。
【朱啸虎|7个关于DevSecOps的认知错误 许多企业都在犯】现实:要解决开发团队和安全团队之间的隔阂和屏障 , 不仅仅需要彻底检查软件生产交付的流程 , 整个组织的文化也需要彻底改革 。 是的 , 安全需要成为每个人的关注点和义务 , 但创新和生产力也需要成为所有团队的优先事项 。
端到端的安全通过端到端的软件交付解决方案将安全性转移到任何地方 , 让组织从一开始就嵌入安全性 , 并贯穿于整个流程 。 高级的DevSecOps 支持自动化安全和合规性测试 , 同时强制使用经批准的组件 。
端到端自动化能够限制由于人为错误而引入的安全漏洞 , 而且如果确实出现了问题 , 将更容易在交付受损代码之前找到并修复问题 。 访问控制也是自动化的 , 可以管理谁可以进行更改以及何时进行更改 , 确保没有人在不被注意的情况下意外更改关键组件 。
启用渐进式交付端到端软件交付解决方案允许逐步交付软件 , 以加速安全可靠的发布 。 渐进式交付以滚动方式引入新代码 , 而不是通过瀑布流方式发布 。 这种方法通过小规模测试代码来降低风险 , 并能够快速回滚出现的任何问题代码(功能管理) 。 这种模式将软件发布转变为具有可信治理的渐进式低风险过程 , 并在生产中发生严重事件时提供“终止开关” 。