devsecops建设之规划

一、前言

　　入职一年，一个人扛所有安全，杂事不断，无暇将精力集中在应用安全，所以devsecops建设是一拖再拖，目前也仅实现上线前渗透测试和安全卡点工作。现在总算有精力践行devsecops，所以思考下如何因地制宜的落地devsecops，做个规划。

二、现状、原则和目标

　　2.1 现状

　　　　目前公司应用安全还处于起步阶段，总体现状如下：　　

1. 1. 建设阶段安全介入少，未实现基于业务需求，提出安全需求和安全设计方案
   2. 测试阶段依靠人工进行，效率低、质量不可控
   3. 未建立响应安全知识库和标准，如威胁场景库、基线标准
   4. 防护手段较为基础，运营阶段不够，且缺少对抗和防护工具
   5. 未建立针对应用安全全生命周期的流程管控

　　2.2 原则

　　　　鉴于人力和预算资源有限，故devsecops建设的总体原则是：

1. 1. 安全左移
   2. 因地制宜、抓住要点
   3. 使用成熟方案、小步快跑
   4. 安全是所有人的责任、人人都需要参与
   5. 建立和提升安全文化

　　2.3 目标

　　　　本轮建设方案的目标主要有如下四点：

　　　　　　提升安全测试自动化水平

• • • 常见漏洞通过工具进行识别和验证，减少人工参与时间
    • 提升对依赖库漏洞检测的自动化水平
    • 提升漏洞通报和响应水平，避免邮件、人工等方式费时费力

　　　　　　提升漏洞识别率和准确率

• • •  通过工具提升识别率和准确率，避免人工测试严重依赖人员水平。确保线上尽可能不再出现常见和低级的安全漏洞

　　　　　　提升应用安全覆盖度

• • • 安全人员从繁重的测试和漏洞通报中解放出来，将尽力放到安全左移中无法用工具替代的部门
    • 提升各参与方安全水平，从源头减少安全问题

　　　　　　建立合理的安全全流程管控

• • • 在应用安全全生命周期中进行安全工作，避免专注某一个点忽略其他点，导致预期外的安全问题
    • 建立安全预案和应急工具，避免出现安全问题后，无处置流程或无法处置

 三、规划方案

　　3.1 业内方案

　　　　　

 　　　　上图是gartner给出的一个安全工具链，结合目前国内较为普遍使用的方案，简单做了一个转化，如下图

　　

　　3.2 计划方案

　　　　　结合公司实际情况，主要从方案成熟度和投入产出比的角度，选择部分方案作为本次devsecops计划建设内容。　绿色部分是目前已开始建设或建设完成，红色部分是计划建设模块，黑色部分为暂不考虑或尚未考虑如何建设的模块。　　　　　

 　　　　　

　　　　转化为公司内部开发流程如下，各方案需在devops的各阶段进行介入和运行，确保各阶段均有安全参与，保障整体安全性。

　　　　将安全切入到devops，转变为devsecops后的整体流程如下。总体还是结合人力和预算投入情况，拟定一个可落地和较为有效提升应用安全水平的方案。

 　　3.3 差距分析

 　　　　差距分析主要便于大领导们直观的了解devsecops的现状和完成如上建设后取得的效果。结合各方案可能带来的效果，进行一定的赋权，测算出目前devsecops的分数和建设完成后的devsecops的分数。当然实际赋权存在一定主观性，仅作为参考。

　　总体来说，通过1到2年的建设，可以将目前的应用安全分数从48.5分提升到80分，总体能达到业内标准水平。

　　　　

　　3.4 资源投入

　　　　资源投入测算也需要结合公司实际情况进行，此处就不贴出具体的测算细节。总体如下：

　　　　

四、评价指标

　　基于拟定的目标，也简单制定了一些可衡量的评价指标，以便评估是否达到预期的建设目标。

　　

　　备注：

　　　　1. 0day不在范围内

　　　　2. CWE TOP 25不包含5个溢出或空指针漏洞

 五、结束语

　　　总体上说，devsecops是个很大的模型。实际建设中，必须因地制宜的制定适合自己的建设方案。在人员和资源投入有限的情况下，最好遵循循序渐进的原则，逐步覆盖各阶段。并且，优先考虑在各流程上先将安全介入，随后再逐步优化介入的内容。

例如，安全设计的标准和威胁库先制定基础版本，就可以将安全设计节点先切入到设计环节，随后再逐步增加设计标准和威胁库内容。这样做的好处是，可以提前逐渐和架构、开发、项目经理等进行磨合，在后续提出更多安全要求时，将会更容易接受。

最重要的一点是：必须有CIO/CTO等高层领导支持，否则将很难落地。对PM和开发来说，安全是他们额外的投入，故必须由高层领导从总体投入产出比等推进安全工作。