就这项工作来说，构建高效的软件安全开发框架是非常重要的，目前国际上较为知名的模型框架有微软的SDL、OWASP的CLASP和SAMM、新思的BSIMM等。SDL和CLASP是规定性框架，强调如何做；而BSIMM和SAMM是描述性框架，强调实际发生的内容和记录观察结果。

目前，国内绝大多数开发企业的安全能力处于建设阶段，因此更适合前者。国内普遍对SDL较为熟悉，一来它是微软提出的，知名度较高；二来其描述的逻辑较为清晰，按照软件开发的7个阶段进行17项安全措施的贯穿。但是SDL是重量级框架，较为严格，适合于成熟大型组织，对于现在普遍使用的快速开发、持续迭代的组织来说并不好用。

CLASP的设计目的是为了方便地将安全相关的活动集成到应用程序开发过程中，从现实软件安全开发工作总结出的安全需求集构成了CLASP最佳实践的基础，可以让组织系统地处理那些一旦被用就可能导致基本安全服务（如保密性、身份验证、授权）失效的漏洞。

CLASP的过程组件包括：CLASP视图、CLASP最佳实践、24个CLASP活动、CLASP资源、CLASP分类法。

1、CLASP视图

CLASP视图包括了5类用来呈现CLASP过程的高层次视角。便于用户理解过程组件间的交互及将它们用于特定软件开发生命周期的方法，它们之间关系如图1所示。

• 概念视图：对CLASP基本概念和基本知识的直接描述，如最佳实践、分类法等。
• 基于角色的视图：包含角色介绍的CLASP过程，包括项目经理、需求描述者、架构师、设计者、开发人员、测试人员、安全审计员等角色。
• 活动评估视图：帮助项目经理评估24个活动，并选择一个适用的子集。
• 活动实现视图：将评估和接受的24个安全相关活动的子集，集成到软件开发过程中，转换为可执行软件。
• 漏洞视图：包含5大类别104个基本问题类型，构成了应用源代码安全漏洞的基础。与该视图关联的是CLASP漏洞用例，描述了安全服务在应用层容易受到攻击的条件。用例使用易懂的实例说明了不安全的源码和基本安全服务中可能产生的漏洞之间的关系。

图1.  5种视图之间的关系

2、CLASP最佳实践

CLASP的最佳实践是所有与安全性相关的软件开发活动的基础，包括7条：培养安全意识、执行应用程序评估、获取安全需求、执行安全开发实践、构建漏洞修复过程、定义并监控度量、发布操作安全指南。

3、CLASP活动

每个CLASP活动被划分为离散的具体工作，并链接到一个或多个特定的项目角色，以此为项目参与者(项目经理、安全审计员等)提供相应的安全指导。表1是24个CLASP活动及其对应的最佳实践、具体工作、相关项目角色。

表1  24个CLASP活动

4、CLASP资源

CLASP资源能够帮助计划、实现和执行CLASP活动。示例编码指南工作表资源（资源E）可以帮助项目经理理解104个CLASP问题类型中的哪一种可能对构建特定的软件系统造成安全风险。反过来，这些知识可以用来帮助确定应该如何执行CLASP活动。CLASP资源及详细内容如表2所示。

表2  CLASP资源

5、CLASP分类法

CLASP分类法是为了更好的评估和解决源代码中的安全漏洞而进行的CLASP过程的高级分类。具体包括以下内容，它们之间的关系如图2所示。

• 安全相关漏洞的问题类型。CLASP给出了104个问题类型。

• 为诊断和解决目的而将问题类型划分成的类别。104个问题类型划分为5个类别：

1）范围和类型错误；

2）环境问题；

3）同步和时间错误；

4）协议错误；

5）一般性逻辑错误。

• 曝光时间(SDLC某阶段)，该阶段中，漏洞可能会不经意地引入到应用程序源代码中。
• 为基本安全服务利用漏洞的后果。
• 可能受漏洞影响的平台和编程语言。

• 漏洞攻击所需的资源。
• 对于可被利用/已利用漏洞的评估。
• 避免及缓解期(SDLC某阶段)，其间可使用预防措施和对策。

图2  CLASP分类法各类间关系

可以看出，CLASP从较为广泛的角度处理安全性，它以安全作为核心，定义为一组独立的活动，并且活动必须集成到开发过程及其操作环境中，使用较为灵活。CLASP基于角色，每个角色在其中做什么工作都有指定。具备丰富的资源，特别是104个问题类型的归纳。

但是，CLASP也有其自身的不足，首先，CLASP更多关注白盒测试，24个活动中，都是规范性活动，而缺少攻击性评估活动，如渗透测试；其次，没有对这些活动按重要性进行分类，以便用户在选择时有所侧重，也便于最小集的选择；再次，对于开发团队来说，除了固有角色，需要增加一个安全顾问/安全审计员的角色，可能会带来成本的增加；最后，供应链方面，虽然有对供应商和产品的评估，但是对开源软件风险的识别方法未提及。

2、CLASP与DevSecOps的契合点

首先，理念契合。DevSecOps一个核心的理念是协同工作，开发、安全、运维团队互相参与，而CLASP中指定了每个角色应该完成的安全工作，实际上就是把安全划分到每个角色的日常工作中，让安全与开发、设计、运维等融合。并且CLASP作为轻量级过程，具有灵活性，满足DevSecOps持续快速交付的需要。但是活动(20)管理安全问题揭露过程，应该由运维人员作为主责角色，当然由项目经理/产品经理来统一协调也没有问题。

其次，内容契合。DevSecOps的要求包括：持续监控、将安全融入开发部署中、进行风险分析和威胁建模、扫描源代码和API等、扫描代码漏洞并修复等，而CLASP的活动(22)、(18)、(2)、(3)、(17)、(3)、(4)、(20)、(21)等正是规定的这些内容，只是侧重点可能要根据具体的系统来确定。

最后，对象契合。DevSecOps虽然动作是检测开发中的安全问题并修复，但其最终目的还是在快速持续开发的方法下如何保护系统资源、资产和数据的安全性，而这一点在CLASP中似乎体现的更加直接，如活动(5)、(8)、(9)、(12)、(16)、(23)，以及(2)中的“识别资产/功能上的威胁”等都明确说明了对资源或数据的保护动作。

3、使用CLASP进行DevSecOps的几点思考

虽然两者之间有许多契合点，但直接将CLASP应用于DevSecOps中并不合适，可以考虑从以下五个方面改进CLASP：

1). 增加重要活动

在CLASP中增加活动“开源组件安全分析”和“安全性黑盒测试”两个活动，并且都属于“执行应用程序评估”的最佳实践。前者用于分析开发系统中的开源成分，并扫描其中的漏洞、后门、恶意代码等安全风险和开源许可证使用问题的知识产权风险。后者用于对系统进行模糊测试、渗透测试等黑盒测试。

2). 自动测试工具

测试评估中尽量使用自动化工具（每个活动对应的工具将在后期专题中归纳），并将工具集成到开发部署流程中。例如，针对最佳实践2中的威胁建模、源码安全审查、安全测试等活动均可借助自动化辅助工具实施。对于符合性验证评估工作，如活动(5)、(7)、(11)、(17)、(23)等，可使用该方面的通用工具或编写专用工具进行辅助验证。另外，与开发过程的融合，即活动(18)也可以自动化实现。

3). 安全需求列表

活动(7)-(15)是关于安全需求和安全设计的。开发前，架构师、需求描述者、设计者应当与安全人员、开发总责人等进行深入讨论，通过评审等方式形成安全需求列表，并与开发人员进行充分沟通确认。每次迭代开发时快速更新需求列表（内容尽量少）。还要制定相应的评估列表，以便于对每次开发完成的系统进行对照评估。当然，这些评估项能够自动化测试的应尽量使用工具实现。

4). 自主适应框架

对CLASP中的活动按照适用性进一步分类，并根据待开发软件的严重程度的等级，确定所需的最小安全活动集和活动执行的深度，并选取对应的自动化工具和安全需求设计列表，将时间花费降至最低水平。

5). 增强优势活动

CLASP中对于业务、资产、资源、数据等的安全相关的活动应予以保留和加强，能够发现针对用户核心资产的安全威胁，才是最有意义的。