这是鼎叔的第一百零八篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），文末有链接。
鼎叔曾经花了一年多的时间组建了一个安全工程师团队，并系统化地学习了安全技术理论和实践方案，借着 DevOpsSec 的东风，聊聊测试（质量）与安全的关系，以及如何在持续测试中落实安全检测能力。
部分图片来自赖东方同学的分享。
测试（质量）与安全
从大的质量角度来定义，质量是包含功能，性能，安全，合规，兼容，易用性等多个维度的，所以安全类测试也是测试体系中的一个类型。
受限于安全意识和安全技术的专业门槛比较高，大多数测试工程师非常缺乏安全测试的能力，本质上，这类能力是可以刻意练习的。
先来理解一个问题，安全工程师和其他开发工程师有什么不同？
最大的区别，是对于引入风险的敏感度。安全工程师优先关注漏洞和被利用的可能性，而不是关注便利性。比如缓存的设计，业务开发用缓存来提高响应性能和用户满意度，安全工程师一看见 “缓存” 眼睛就亮了，眼里马上浮现出各种利用缓存的漏洞。
另外一个例子是对 “客户端的不信任”，不盲目相信客户端的提交，对涉及权限的信息要有不可猜测性。比如有的用户可以通过遍历链接中的 ID 号，可以查看其他用户的交易记录。
专业的安全高手（白帽子）从大学开始就参加各种安全比赛（挖洞），并对各种最新的威胁漏洞和安全检测工具非常敏感。
优秀的测试工程师不也是应该这样么？——对于各种缺陷非常敏感，形成直觉。安全缺陷也是缺陷中的一类，优先级通常很高。
安全和其他测试一样，也很容易成为软件发布的瓶颈，团队经常为了达到安全标准，安排特定的评审和测试验收环节。
但如果安全流程严苛，安全技术人员人手不足，安全检测自动化水平低，整个业务的发布节奏都会被影响。
助力安全左移的 DevOpsSec
敏捷团队经常强调质量内建，安全也同样要内建，内建的意思就是业务研发和安全团队责任共担。
关于安全内建和安全左移，微软有一套著名的 SDL(应用安全开发生命周期) 实践方案：
如何快速内建，降低安全评审依赖，缩短交付周期？解法和持续测试是一样的，在 DevOps 闭环中赋予安全能力和安全工具，同时解决快速交付和信息安全的难题，即业界热门的 DevOpsSec。
DevOps 引入安全能力面对的通用挑战是：引入成本和工具误报，弱化安全设计带来的风险，以及如何真正做到快。
那什么是 DevOpsSec 的指导原则？
安全左移
默认安全
运行时安全
安全服务自动化/自助化
IaC-基础设施即代码，制品库安全等
利用好 CI/CD
组织和文化建设。对于产研团队，最重要的就是意识和技术两方面的安全培训，相关内容可以看看下面。
工欲善其事，必先利其器。融合安全的持续交付必然离不开常见的持续集成安全工具，如：
静态应用安全测试工具 (SAST)
第三方安全扫描工具
动态安全测试（DAST）工具，模拟黑客的攻击行为
交互式安全测试工具 (IAST)，通过在测试环境插桩或端口截流的分析方式。
日志安全分析工具
制品管理安全工具
信息安全自动化工具对于开发和运维工程师来说最好是 “透明无感知” 的，这样才能保证 DevOps 的敏捷。
类似鼎叔在持续测试提到的成熟度概念，DevOpsSec 也是可以定义成熟度的，需要明确哪些指标纳入成熟度考核，并进行合理的分级。比如下面几个成熟度的参考维度：
安全工具链的建设，集成和使用的情况
团队敏捷工作方式和团队的组织架构情况
人员的安全能力：知识经验和问题解决能力
产品交付的质量数据和安全水平
安全团队在干什么
回忆一下，鼎叔在组建安全团队期间具体做过哪几件事。
安全渗透测试。给公司的数据资产做深度检查。入职的第一位安全工程师，就在第一周发现了后台数据库的一个重大漏洞，导出了所有员工的登录账号密码并暴力破解，让技术部门吃了一惊。渗透测试怎么展开，可以看看这张思维导图
安全自动化扫描能力，和前面提到的 DevOps 工具链的聚合。发布了多端产品（H5 官网，App 端，后端等）的扫描安全问题分析报告。
业务安全，分为业务架构的安全评审，以及用户可疑操作行为的风控等两大类工作。
对于 APP 羊毛党用户，我们能够从登录地点，登录 IP，登录频率，登录时间，交易操作频次，以及第三方登录方式等信息，判断其对业务带来的风险。我们甚至为此建设了异常登录规则库。
安全团队可以把需求安全评审的关注点做成 checklist，具体考虑这些维度：信息安全资产的机密性，完整性和可用性；针对安全控制设计与变更，基础设施的变更，合规性的变更，给出具体的控制评审清单。
对 GitHub 上的公司敏感代码泄露进行监控，落实管理办法。
给公司员工赋能安全能力和安全意识。安全是质量的一个维度，这句话类似 “培养员工的质量能力和质量意识”，让全员重视安全，远比一个小团队辛苦救火要好。
安全赋能 - 意识
安全防范体系的四部曲：让坏人进不来，看不到，改不了，赖不掉。
鼎叔曾经花了四个月的时间（每天一个小时），看完了 CISSP 考试教程的内容，里面提到了十大安全设计原则，可以用来避免 90% 的安全问题：
简单易懂
最小特权
故障安全化 - 即使发生故障，也能安全处理业务
保护最薄弱环节
纵深防御。多层次地防御攻击
隔离原则
总体调节
默认不信任
保护隐私。包括脱敏和加密，明确禁止的数据不要采集
公开设计才是安全的设计。
一张很有趣的图片，开着这辆车去街上溜达一圈，就可能入侵各个摄像头网络的数据库：
为了提升员工安全意识，安全团队会联合 IT 做一些安全演练，最常见的就是发钓鱼软件，看看哪些人会上当。
对于灰产羊毛党最喜欢的大规模自动化恶意操作，如撸羊毛和撞库，也有不少的图片资料，提升员工的直观感受。
安全赋能 - 技术能力
安全技术能力主要包括这么几大类：
Web 安全漏洞挖掘能力
APP 安全漏洞挖掘
隐私合规能力
安全编码能力。最突出的是输入输出参数处理不当产生的漏洞。大公司都会搞一个安全编码规范，注意：如果安全人员做的规范不太考虑编码语言，不考虑开发人员的视角，会给开发人员带来较多的负面体验。
框架安全，安全函数库和安全组件。直接提供一系列的安全函数，或者内置了安全特性的组件，对开发人员的帮助会更有效。
源代码安全管理。代码安全管理允许开发人员协作处理并跟踪更改。源代码属于公司的敏感数据，对其访问控制也需要遵循最小权限原则。
编译环境和开发环境安全。第三方提供的构建依赖包等，可能会成为安全隐患的源头。如 2015 年的 XcodeGhost 事件，受影响的用户数量超过了一亿。
构建基本的自动化攻防能力。一旦树大招风，被黑产盯上还是很要命的，基本能力需要日常演练。
数据安全，本质上是保障存储，传输，使用的安全。传输要看签名完整性，使用上要看操作和日记记录。
安全团队的新挑战
自动化时代的低代码平台在前些年挺火，但是对于 DevOps 公司很难深度使用，低代码平台始终不能缓解自动化焦虑，长期看也不能提高效率，开发团队也不愿意接手低代码遗产。
对于当前普遍上云和微服务的业务而言，面临更多具体的新安全挑战：
对于云和微服务，攻击面小很多，边界不清晰，审计困难。
容器的安全技术和以往不同，要考虑资产的销毁，兼容性等新风险。
云原生的安全也有所不同，它包括代码安全，镜像安全，编排系统安全，容器运行时安全。这四种安全分别对应着代码，容器，集群和云这四个层级。
结语
安全团队投入的成本很高，不要指望 100% 的安全，安全工作的本质就是尽可能降低风险，积极攻防实践，尽量借助自动化机制快速验证，并对一线工程师赋能。
