也说说从DevOps到DevSecOps
首先可以说说的是，DevOps这个说法，在被行业提出来之前，笔者已经认识到和具体实践了好久，只是形成具体理论和行动指南，还是没那个水平。
而从DevOps，发展到DevSecOps，基本上到了现在，要在开发中明确地引入安全性的要求，已经没有争议了。
笔者：国际认证信息系统审计师、软考系统分析师
本文不打算解释DevSecOps，如果还不太清楚，可以参考下面这些介绍文章：
或者微信公众号文章：
但在开发和运维的实践过程中，安全性依然存在着模糊。因为安全性并不单纯地是一个中间环节，而是同时存在于开发和运维的范畴内。
而无论开发人员或运维人员，都很容易是基于自身定位而导致对安全性要求的理解不到位。
典型如，开发人员认为安全问题可以在运维实践中预防和修补，运维人员认为安全问题只能在开发（源代码）中解决否则无法有效防御。
所以经过一段实践之后，我也在这里发表一下对DevSecOps的个人见解。由于实践规模比较有限，我的看法集中在自动化支撑、供应链安全、组件耦合细分粒度三个方面。
首先说说自动化问题。
自动化是DevOps的实现根本。在笔者之前的实践中，就是因为自己写了好多自动化辅助配套工具，才逐渐建立起DevOps的原始概念。
发展到DevSecOps的如今，整合支持安全性要素的DevOps过程自动化工具已经很多，而且一些工具之间还可以相互集成和互补。笔者在企业内，通过应用GitLab实现基于DevSecOps模式的项目管理，效果良好。
因为按笔者个人观点，对安全性提倡左移重于右移，这是基于对Sec安全性的溯源要求，以及DevOps的快速迭代要求这两点。
溯源无疑需要从源代码解决问题，而快速迭代则要避免缺陷代码不加修补地被反复使用甚至扩散。提供了安全管理功能，尤其是提供或者整合静态代码扫描检查功能，对实现安全性左移是良好的支撑。
第二个是供应链安全。
供应链安全，实质就是供应链管理问题。
经过了几次人所皆知的全球性供应链安全事件后，软件开发中的供应链安全性问题已经成了老生常谈。基本上，盲目依赖公共供应链而不进行必要的管理，等同埋下定时炸弹。
使用开源库和开源框架是当前互联网应用开发的必然行为。而这些第三方代码，在集成到自己的项目中时，必须有适当的管理过程，以确保：
1、整合进去的代码版本在当时是安全的；
2、整合的代码版本出现安全问题时，能及时从可信的源头获取更新、立即替代并执行后续的构建、发布等过程。
笔者最早期时对第三方代码是不纳入代码版本库管理的，随后在实践过程中，不断变化管理方式，在不同的情况下，选择采取第三方代码独立仓库管理，或者是直接纳入项目代码仓库管理。虽然管理上变得复杂，但另一方面是安全性、可靠性都获得了极大提高。
第三个要素是应用程序组件耦合细分的粒度问题。
这也是近年来各种各样新出现的软件架构概念相互交织的结果。DevSecOps本身是一种实践过程，和软件架构概念并没有直接冲突关系。但在实践中，软件架构的不同，会对DevSecOps三个要素产生不同的要求。
业界比较认同的是，DevSecOps的快速迭代特性，使得对项目内各应用组件是相互独立或者松散耦合模式的情况最为适用。典型如基于微服务架构的项目，项目整体或每个服务组件都可以有自己的迭代更新过程。
但松散耦合模式实际创造了更多不确定的安全性因素。就如前述供应链管理，假如某个第三方组件被不同的项目组件所使用，并且在DevSecOps过程中由于管理因素（不一定是问题）而出现版本差别，就会导致难以发现的安全性问题。
再考虑到组件越多，攻击敞口就越大，这对安全右移到Ops就是实实在在的挑战了。如果没有能和项目组件细分粒度程度相匹配的、完全自动化的安全性监控管理能力，那还是适当聚合比彻底松散要更容易确保安全。
还有一个要点，Serverless模式实际上把粒度细分到了极致（每一个函数），但对外是统一的接口。这表面上绕过了或者不存在架构组件聚合还是耦合的问题，而且云平台厂商对安全性的管理会比大多数ISV要好。
但是，凡事都有但是。Serverless并不能掩盖函数代码中存在的安全性问题，这依然是个左移问题，而Serverless需要Ops方面能和云平台厂商对接，产生了右移复杂度。Serverless平台本身也需要防护，这个防护既可能独立于ISV，也可能需要ISV协作，很多要素尚在发展过程当中。
结论：
安全和软件工程一样，都没有银弹，任何选择都是权衡和取舍。
注：本期封面图通过AI生成，来自Algolet小算法：
本页网址二维码：