【SDL最初实践】安全开发

在确定产品原型与功能之后，便交由开发负责推进。然而关注点大多仅在于业务流程与功能点的实现，具体使用的技术决定于公司技术栈和个人能力，对于带着安全意识去编码这件事儿，大多都没太在意。

01

—

安全目标

通过提供公共安全组件、制定安全开发规范、提供静态代码审计系统给业务方，从基础安全服务提供者、安全规范制定者和安全质量把关者角度出发，对开发进行赋能，想办法让其按照安全开发规范进行编码，并提供一套强有力的代码安全检测系统，把控代码安全质量，从而减少或消除因编码而产生的安全漏洞。

02

—

安全活动

在代码编写阶段，安全活动主要围绕安全开发规范、安全组件接入和静态代码扫描开展。

1）安全开发规范

从隐私和安全角度两方面出发，结合当前发现的高危问题；参考业界的安全开发规范，融合公司当前的技术栈；站在开发视角，进行安全开发规范的编写。规范项不在多，关键是需要清晰、易懂、针对性强、易判断是否违规。

2）安全组件接入

分析企业中存在的常见安全漏洞，来源可能是内部安全测试结果、外部漏洞收集（SRC、第三方漏洞平台、CVND等），并结合漏洞影响、开发难易程度、加固效果，对业务部门输出统一的安全组件，快速、高效、低成本解决普遍存在的安全问题。常见的可能有：统一登录安全网关、短信安全网关、CSRF-token组件、XSS过滤器（适用于非富文本框场景）等。

3）静态代码扫描

代码的白盒测试，最好是嵌入到发布流程中。一方面对源代码起到保护作用，不用另辟蹊径存放源代码，打破源代码统一管控的好局势；另一方面可以在流程中设置卡点，形成强有力的抓手。不少人对代码分析存在恐惧，觉得是效率低并且要求高的工作，但是在代码层面找出问题对于整个SDL都是十分必要、有效的一环。市面上的代码审计工具不少，商业的包括checkmarx、fortify、coverity，开源的有check style、findbugs、cobra、Rips等，需要从语言的支持、误报率、购买以及维护成本等不同维度进行综合评估。

03

—

安全实践

1）开发安全规范

• 开发语言：随着技术的不断更新与发展，公司中必然会出现不同的开发语言，按照先cover住公司主流语言的思路，确定Java安全开发规范的编写工作。
• 编写内容：比较快速的一种方法是引入外部优质资源，现网上公开的优质资源有阿里的安全开发规范、华为早期的安全开发规范，参考其内容与格式，针对公司主流语言系统常见高中危漏洞进行编写。
• 规范框架：包括漏洞描述、检测方法、代码示例（不合规代码示例、合规代码示例）及修复方案。

• 架构评审：安全人员有时不禁仅从安全的角度来编写规范，如果没有专业的开发技术和对漏洞足够的了解，预期的产物与效果往往会大打折扣。邀请架构组和业务线上的开发参与规范评审，不仅会从专业的技术角度提出建议，还会从实际可落地性和开发容易理解的视角进行完善。
• 发文上线：发文之前有一必备的步骤就是会签，找各业务线的领导和大老板会签，让他们知道有安全开发规范的存在，对日后可能产生的违规处罚进行声明。

2）代码审计系统

• 代码扫描工具选型：以来自互联网上的一张改编图进行说明，对主流的扫描工具进行对比。

本文中的示例，以fortify为例。（网上出现不少带license的破解版本，有兴趣的自寻查找）

• 嵌入系统发布流程：将代码扫描工具集成到系统发布流程，是安全开发阶段最重要的步骤。在发布系统中加入静态代码扫描按钮，开发创建项目并提交代码后，触发fortify在扫描服务器上进行扫描，扫描结束后以邮件的方式告知开发。大体流程如下：

• 提供代码扫描服务：以安全服务提供给业务方，除了代码扫描的能力外，还有安全扫描的流程与使用方法介绍、扫描出的漏洞解读与技术支持、总结常见问题并归档对外输出。比如往期的文章中，将fortify汉化版漏洞说明，统一放到内部技术平台以供学习。

3）输出公共安全组件

• 现状分析：针对普遍存在于业务线或高频出现的高危漏洞，结合不同的场景进行分析，衡量是否有输出公共安全组件的必要性。别让开发花大量时间在修复漏洞上，解放他们，回归系统功能的开发与实现。
• 协作部门：单靠安全部门，在一般的公司难以做起来，尤其是缺少安全开发或开发能力不强的团队。比较好的一种方法便是拉上中间件等中台部门进行合作，优势互补输出公共安全组件。
• 安全评估：针对公共安全组件的安全评估，包括功能设计、实现逻辑以及最后的安全测试，都需要安全人员的重点关注，避免安全组件出现绕过的场景，杜绝因为安全组件而引入新的安全隐患。比如使用已知的成熟算法，切勿私自发明创造。

04

—

持续优化

安全运营的思想，也同样适合在SDL的各个阶段，即：在推行中发现问题，解决问题，优化功能。在安全开发阶段，安全开发规范需要优化，代码扫描系统也需要优化，覆盖率需要考虑，准确率也需要琢磨。简而言之，大致可以从以下三个方面进行考虑：

1）安全开发语言覆盖面

开发技术栈的多元化，带来最直接的问题便是覆盖面。安全开发规范、静态代码扫描都需要由最开始的cover主流语言，扩展到公司第二、第三…主流语言。在资源受限的情况下引入一些开源工具应对不同的语言审计，或许是个必要的选择。

2）静态代码审计系统误报

几乎所有的互联网公司都是追求“宁可漏报，不可误报”，由于发布量特别大不得不这样。然而在传统行业里，开发模式可能还是瀑布模式，对各个环节的误报要求难以媲美互联网公司，但是减少误报率也是十分必要的。对于使用商业版（破解了也算）的代码审计工具而言，其规则难以调整，故可以在扫描的结果上进行优化，比如要求开发仅解决Critical、High级别的漏洞，甚至是可以具体到两种级别中的具体漏洞类型。

3）第三方开源组件技术检测手段

使用已知漏洞的组件，在最近两次的OWASP Top 10中均上榜，由此见得其重要程度。目前在市面上还很少出现专门的检测工具，商业版的几款静态代码扫描器有所涉及，但未能试用对比。目前而言，稍微较好一点的方法可能是使用OWASP提供的Dependency-Check，有如下特点：

• 支持Maven、Jenkins等集成
• 支持Java、.Net
• 漏洞信息来源于nvd
• 检测规则为特征匹配（类似工具基本都是该原理）

05

—

安全招聘

团队招人，希望有想法的小伙伴，一起共创未来。希望你是：

• base：北京
• 具备：一定的SDL经验，并想在该方向深究与沉淀
• 联系：欢迎微我，更多细节详聊

06

—

安全交流

近来发现SDL越来越“火”，于是产生了创建微信群、专门交流SDL的想法。

• 入群请加我：姓名-公司（甲方）-SDL
• 入群请须知：仅讨论SDL相关话题、仅分享SDL相关材料
• 拒绝伸手党、斗图党、开车党以及抱着心态进来学习（潜水）党