今年我们也尝试了SDL威胁建模，设计了适合我们的建模规则，包括重点关注的数据安全需求、审计需求等。这部分工作目前还在小规模试点、探索阶段，从流程到工具都还有很多要解决和优化的事情，等到实际成熟，我们再考虑投入更多的安全测试、安全服务人员在公司大范围推广。
3.4 SDL白盒扫描
在白盒代码审计方面，我们也投入了少量的资源进行尝试，封装了代码审计平台，核心依赖于Sonarqube和Findbugs Security，也支持自己编写规则，实现了触发扫描、上传源码扫描等方式，自动提交漏洞。但是这部分最大的消耗还是对规则的运营、对误报的消除等，目前也没有找到更优的解决办法，听到比较多的思路也是简化规则，初期“宁可漏报，不要误报”。目前主要的使用方式：安全人员临时任务需要上传源码进行扫描、对一些接入的项目每周扫描发送检测报告。
3.5 SDL被动扫描
SDL的另外一个尝试是在被动扫描，基于流沙平台收集的测试环境流量进行回放。大致的思路之前很多人都分享过，通过替换cookie、request-param重点用于测试发现未授权访问、垂直越权、水平越权等安全问题。难点也是优化规则、整理收集公司业务的共性（比如错误页提示等）。之前利用这个扫描发现过几个高危的问题，投入产出比还是挺高的。但是想做到较高的扫描准确率、提高自动化程度、达到可持续运营的效果，要投入的人力就比较大了。具体看团队的取舍吧，最近也看到一些国内外利用AI来提高安全测试效率、甚至替换人来进行手工安全测试的项目，不评判短期内是否能很好的落地，但是认同一句话“人是会疲劳的，但是机器却不会”。
3.6 SDL漏洞管理
漏洞管理主要依赖于洞察平台，包括应用资产系统的管理、漏洞生命周期的管理、安全知识库的管理。洞察平台在去年进行了开源，用户比我们预期的要多，从社区微信群平时的交流咨询来看，使用者多是1-5人的安全团队，并且有互联网、制造、物流等多个行业。每次有人加我们微信寻求洞察平台部署配置以及功能使用上的帮助时，虽然占用了我们一些工作的时间来解答或者解决问题（我们会检讨软件质量问题），但还是很开心能够真正帮助到安全同行。
这件事也让我有些反思：
其一很多企业在安全上的投入有限，的确需要好的开源解决方案；
其二产品落地需要一些乙方的思维，产品有时候需要做减法，大而全未必是每个人都需要的，而且好用的前提是好部署好配置。
洞察insight开源地址：https://github.com/creditease-sec/insight
四、洞察2.0今年我们将开源洞察的2.0版本。
第一会优化之前的交互、功能、业务逻辑等提高易用性；
第二完善漏洞运营的数据，加强报表功能来关注整体的安全状况；
第三也是最大的更新，合并了SRC前、后台的功能，让企业可以自定义地来建立自己的安全应急响应中心，并且统一了各个来源的漏洞管理。
上图展示的是原型图，目前正在开发的过程中，有需要的安全同行们可以期待一下。
五、流沙平台另外一个最近一年听到比较多的各甲方团队在讨论的就是SOC和SIEM，有商业化的安全大数据产品、也有类似Splunk这样的平台（Splunk Enterprise Security）、还有基于ELK的开源方案。我们选择的是第三种，当前阶段比较好地实现了数据的采集、存储，以及一些不是非常复杂的计算。
数据来来自交换机的流量镜像、日志文件、各安全设备的syslog等。架构师设计实现了一套预处理程序，进行数据的接入配置、过滤、格式化、组装、打标、脱敏等，核心代码部分用go来编写，来提升处理性能。
