之前已经聊过在甲方团队做DevSecOps能力建设的零碎轨迹，但是针对项目级安全治理的关键细节，我们还不曾详述，那么接下来简单讲一讲。

安全合规评审

对于重要的基础系统或者服务，我们如何做好完整的评审闭环呢？

这里我们分三个阶段去达成这个目标：

信息采集阶段

• 问卷和自查

首先，最了解系统的人肯定是相关开发人员和产品经理。那么整个企业或者整个业务线，拥有相似的研发习惯或者通病的话，批量进行问卷和自查能帮我们解决掉很多事情。

当然，很多人可能会说，这种东西业务方不一定会配合你去做，安全人员在大部分企业内的地位是相对低的。

好一点的可能是独立出来，直线向CTO汇报；次一点的挂在强势的运维总监下面，好赖能在平时做做事务推动。再次的话，就是那种一个人的安全部，除了怼二开/购置商业产品，还有日常和业务线撕逼外，其实存在感不是很大。

但是话又说回来，做不做是一回事，如何去达成是另一回事。

能用点手段，自上而下去推动自然是最好的。

• 文档发掘

如果是规范完备的研发线，通常会存在相关的研发说明和产品文档。

我们做风险评估之前，也会从大量的信息中主动提取疑似脆弱点，作为后面评估的参考依据。

后面的工作中，我们能通过对比记录，更加快速的定位到风险点。

同时也能在一定程度上，避免在过长的评审时间跨度之后，产生不必要的风险遗漏。

主动评估阶段

在这个阶段，我们主要会对下面三个风险点进行分析。

• 接入风险：

在使用某个系统的时候，可能系统本身是不具有高风险的。

但是由于业务方操作不当，或者配置失误，有可能会导致产生接入性风险。

所以这块儿的治理，一般是针对中台或者基础服务，需要提出规范制度进行管控。

• 架构风险：

在架构设计之初，很多产品的安全评审是不足的。所以在架构设计中会出现潜在的风险。

在设计逻辑架构时，我们会考虑到数据流转和业务场景转换，在关键流程节点上往往需要制定审计策略。

在设计系统架构时，我们需要考虑到是否接入了安全能力组件或者安全服务中台；是否符合固有安全架构设定；是否符合冗余灾备法则。

在设计网络架构时，我们需要考虑是否进行了线上线下隔离；所在网络区域是否对外开放；如果接入了外网，是否接入了SSO+IAM+VPN；是否会留存重要的操作日志；是否能做流量安全审计。

• 基础风险：

运行时系统评估：WEB层面主要针对OWASP TOP风险进行核查；系统本身层面会审计是否引用了不安全的第三方服务（组件）；主机层面是否对基线（端口、配置、内核等）的进行了加固核查。

代码评估：分析代码中是否存在硬编码和配置风险；是否引用了不安全的第三方包；是否存在常见的漏洞；是否存在明显的逻辑链路失误。

数据评估：是否存在未脱敏数据的批量开放展示；是否存在敏感数据存储未加密，是否存在第三方数据不合规引用，是否接入了数据溯源和加密分发等措施。

自动化覆盖

在完成风险评估后，我们需要有一套完整的风险验收的闭环。

在我们完成主动评估阶段的工作后，通过紧急程度分级进行修复推进。

而后，我们再结合基础CMDB的数据，借助自动化能力，进行定期巡检复核。

• 接入风险覆盖：

可以通过注册依赖和代码层面，进行特征对比检查，校验是否存在接入失衡导致的风险。

• 架构风险覆盖：

自动化核查供应链，实现第三方对接监测，枚举安全中台能力覆盖，枚举边界兜底措施覆盖等等。

• 基础风险覆盖：

接入黑盒漏扫、基线、白盒规则，后期通过自动化观测，进行变更管控和风险复核。

基础能力兜底

对于整个企业、业务线、乃至具体到单个系统。除了本身固有的风险以外，我们更需要从宏观的架构出发，使用基础安全的能力进行兜底。

组件管理

首先，企业的研发线通常会引用开源组件，这批组件相对固定，所以维护起来有一定价值。

从安全的角度来讲，我们可以通过接入CMDB库来管理组件版本，引入对CVE官方或者开源组件官方的漏洞舆情感知，方便我们在紧急情况进行有序的版本推修。

当然，我们也可以通过脚手架的形式，把常用的组件进行打包，进行统一的版本升级管理。

其次，我们还可以对于常见的开源组件做二改加固，单独维护一套相对安全的组件版本。

能力引入集成

这个也是老生常谈了，对于安全能力的引入和集成，可以分为下面几个点去实施。

• 安全组件：

如果我们拥有维护安全组件的能力，要么指望通过规范，推广让研发线做引入。要么就直接在流水线中进行默认集成，如果上线出现问题再做版本回退。

• 黑白盒：

在流水线发布的时候，会自动化进行增量的黑白盒扫描，此时的优先级调度，建议排在队列前面。

然而这时候如果测出问题，并不建议直接阻断构建，因为我们一切的工作都是为了保障业务稳定性而服务的。

如果出现高危漏洞，可直接推送告警给安全人员，审核确认后可以跟研发人员沟通紧急修复。如果紧急程度不高，我们可通过邮件或者工单沟通好，徐徐图之。

• IDE插件

在代码交付之前，业务方使用IDE安全插件，能很好的对代码做预修正。

常见的问题，能在自核验的过程中解除，减少其他环节的耗时。

• 代理插件

在质量测试和开发中，一般会在本地PC进行调试，也会访问一些搭建好的新服务。

这时候如果本地agent（浏览器）设置了相关代理，将测试流量转发到安全中心。就能很好的对增量的服务和接口进行风险确认，及时防患于未然。

当然这个需要配置代理白名单，区分测试环境和线上环境，避免流量互串。

底层服务化

除了必要的安全检测能力，其他底层支撑能力也需要实现服务化。

很多企业目前的安全建设进度，其实还处在做二开或者怼商业产品的节点，不定时做做渗透和众测，但自身并没有精力把底层的安全能力树立起来做支撑。

因此，我们需要根据企业目前的情况进行分期建设，针对各个产品线进行安全缺失度评测和适度补全。

首先，我们需要强化底层的认证机制，借助内部的证书分发中台，将鉴权认证细粒度到业务方的IDC、服务、接口，尽可能实现非敏感区域全覆盖。

其次，需要实现存储能力的标准化，自适应调整敏感数据和文件的存储结构。将失衡的加密手段，以及错误的存储桶访问配置，实现无感知的安全强化加固。

此外，我们还需要对业务容器化的流程做融合，把相关能力嵌入到云管平台及配套体系中，在企业“云化”的发展中形成安全助力。