DevSecOps实践中的第一个错误是将“DevSec”误认为“DevSecOps”，而忽略了“ops sec”；系统不安全是常态，应急流程不完善是常态。“防微杜渐、防死”的理念已经不适应当前的行业发展，动态安全需要关注Ops领域。作者：安全乐观主义
兼顾安全性和可靠性。
业内很多关于DevSecOps实践的文章，大多是关于静态代码检查、被动扫描器、安全框架、SDK、域名在线卡点等等，无一例外地避开了软件的维护和运行阶段。DevSecOps实践中的第一个错误是将“DevSec”误认为“DevSecOps”，忽略了在Ops阶段只将安全性向左移动不是正确的事情是很简单的。
我认为是时候谈谈安全性和可靠性的集成了。这个领域将是未来5到10年DevSecOps行业的主战场，国内阿里和腾讯已经在这个领域积累了人才和技术。
错误的“开发安全”为“开发安全操作”
折腾开发人员是安全团队的传统技能。安全偏见认为运维只是申请机器和打补丁的事情。事实上，SRE现在的角色完全不同了。虽然一直没有人愿意做，但是我们不能妥协。工作怎么能不严格呢？怎样才能用善良做好一件事？改变是要付出代价的。
关注dev的sec，而不是ops的sec，主要在四个方面：
建造的想法受到过去经验的限制。对于云原生项目、微服务、大数据、IaaS项目，仅仅通过安全团队对web和移动应用的安全审查，说“安全审查通过了，可以上线发布”是不够的。说到应用安全，其实指的是狭义的研发；d安全，似乎认为主机系统安全、部署安全、运维安全、基础设施安全等领域与你无关，安全之手不能伸得太长，但现在和未来都是“基础”
选择你现在正在做的事情，不要着眼于长远。当前的问题是只在需求、设计、开发和实现阶段考虑安全性。从业务角度来看，安全本身就是一个持续的项目，这项工作永远不会随着企业软硬件的发展而完成。我们总能做些什么来降低未来漏洞的风险和影响。
投资回报率不高。注意成熟度从80%到90%的演变，而不是0到80%。我们一直认为公司的安全风险是由研发人员编写的代码引入的；d人事。实际上，对于全链路攻击来说，代码安全漏洞的利用只是入口边界，提升功率、抓取哈希、未经授权等横向渗透后果与开发者无关。目前大部分能力主要是反入侵，这是很多公司做不到的。做长尾工作的扫描、补漏洞、预警能力都耗费了大量精力，安全投入回报一直不足。为什么不真正关注建筑的缺点？
忽略人的因素。人都会犯错，我们只能减少问题的影响，永远无法彻底解决。除了关注技术和流程，人的操作因素是影响DevOps效果的最大变量。
ESG对北美私营和公共部门的IT和网络安全专业人员的调查显示，48%的组织故意将易受攻击的代码推送到产品中，这表明虽然工具过程可以被检测到，但人们却主动忽略了发布。
再举一个最近的例子，我们真的能解决“删数据库跑”的问题吗？字节最近通过了“派字节跳动实习生删除数据库，公司报为重大事故”的事件。回答：没有。
保护你的行动
数据操作、多操作和自动操作可以统称为操作(操作\操作和维护)阶段。站点可靠性工程的概念最早是由谷歌工程团队的gjdbm Treynor斯洛斯提出的。SRE可以帮助团队在发布新功能和确保用户可靠性之间找到平衡。可靠性和安全性是不可分割的。没有安全性，就没有可靠性。没有可靠性，就没有可用性。SRE(或DevOps工程师)关注的是稳定性和安全性问题，解决方案、策略、技术实现和对人的要求都是一样的，但目前的情况是，安全和SRE之间的沟通和合作远远不够。
我们永远无法理解自己的系统。安全还没有明白这个道理，我们一直喜欢规范统一。现在我们构建的分布式密钥系统已经变得非常复杂，没有人能够解释它的整个运行本质。系统不安全是常态，应急流程不完善是常态。“防微杜渐、防死”的理念已经不适应当前的行业发展，动态安全需要关注Ops领域。在安全和可靠性领域已经有了一些实践。
安全工程-安全
Chaos Engineering红蓝对抗方式是一种偏向传统的思维，显而易见其不足之处在于：一、攻击者总是能发现缺陷，蓝队总是能收到告警，说不清到底有多少工作要做；二、虽然少数优秀的执行团队可以做到以周、月度为周期演练，频度仍然严重不足；三、不透明、不可重复实验、过程不可控，缺少持续的反馈。如果说红蓝对抗的定位是“发现建设存在哪些问题”，安全混沌工程则关注“建设这些问题的优先级”。
当我们面临一个复杂规模的业务系统时，出现安全漏洞几乎是必然事件，没有安全问题是偶然现象。不管你花多少精力进行漏洞修复，出现0day几乎是必然事件；不管你组织多少安全培训，员工点击钓鱼系统几乎是必然事件；不管你做多少风险感知能力，入侵行为发生快于阻断是必然事件。
根据《IBM Security 2020 Cost of a Data Breach Report 》52%的数据泄露是因为恶意代码攻击，23%的原因是人的犯错，25%的原因是系统故障。安全混沌工程通过观测应急响应、安全控制措施验、基线监控、风险发现等技术手段解决后两类问题，占比共达到48%！
将安全视为故障需要运维和安全共同进行改善，安全混沌工程通过快速检测服务是否健壮、安全、有足够的韧性、能否容忍意外的安全事件来提高企业安全架构的实用性。
韧性-Resilience
发生安全事件的第一步应该做什么？恢复业务正常运行进行止损。组织需要建立面对性能和安全威胁时，有效保持系统弹性和恢复的能力。今年RSAC大会探讨的韧性其实已经超越了安全的范畴，是踏踏实实的软件工程。韧性要求安全工作不仅仅重视拿结果，也重视过程阶段的成熟，引入了控制降级、冗余、弹性设计、隔离、自动缓解和恢复的概念。
Zero Touch
恶意用户（或者攻击者）尝试破坏系统、中断系统来影响服务可用性，我们必须将”人的因素“装在”笼子“里。想象一下，一位研发人员通过配置管理下发了一个错误的配置引起了软件变更，但是这个时候是不是绕过了code review和代码扫描？
Zero Touch通过审核每一次变更必须通过自动化、软件校验风险因子、可审计的备用措施来实现”提高生产安全性、避免中断“，被背后代表着需要落地大量安全原则，比如最小权限、前置安全检查策略、安全代理、审核、关注人和机器之间、机器和机器之间的交互。这方面需要建设工具链很多，安全的前景很大。
对待安全的观念需要立刻改变
笔者从不相信DevSecOps，指导所在领域建设的思路只有基础设施强制安全和极致自动化两个概念，DevSecOps这个名词的作用仅仅是说服合作伙伴达成协作而已：）
不要去保证100% 安全性，而是针对安全故障做好计划并妥善应对，现在开始关注Ops安全，立即行动起来吧！
参考资料
https://www.researchgate.net/publication/335922038_Security_Chaos_Engineering_for_Cloud_Services
https://www.freebuf.com/articles/security-management/275605.html
https://security.tencent.com/index.php/blog/msg/150