实验二 电子公文传输系统安全——读书笔记

《The.Security.Development.Lifecycle.CN.软件安全开发生命周期》

第一部分 对SDL的需求

隐私与安全：

隐私可以看作是遵守策略的一种方式，安全则看做是一种执行策略的方式。隐私问题的核心是符合监管部门的要求、公司策略和客户期望。关于安全还需要考虑的一个因素是与客户签订的服务水平协议（SLA）和维护时间。安全与可靠性存在显著差别，但有时候可能会产生冲突。微软可信计算最初关注四个方面，其中三个是技术方面：安全、隐私和可靠性。下图为质量、安全、隐私和可靠性之间的关系
image

影响SDL成本的因素：

1.从最初就实施SDL是成本最低的。选择语言、编码标准以及中医的攻击，尽量避免出现错误。
2.对大量“遗留代码”应用SDL的成本是高昂的。
3.同等条件先，在C#、VB.NET或Java等托管代码环境中应用SDL，相比于在C或C++等未托管代码环境而言，更为容易。
4.彻底移除某一特性总会比不断地修复更安全，成本更低。
5.工具通常情况下总是比人工查找漏洞更有效。

当前的软件开发方法不足以生成安全的软件，主要有以下四种不行的原因

“只要给予足够的关注，所有的缺陷都将无处遁形”不行的原因：大多数人并不喜欢审核代码中的bug和漏洞，因为过程缺乏创新性且缓慢枯燥令人厌烦。有一个简单的原则：代码审核的质量，完全取决于待审核的代码的多少；必须有足够多的具备相关知识的人员才能够对代码进行充分的审核；“关注越多”越容易失去要点。

  • 专利软件开发模式不行的原因：现在有许多开发模式，没有任何证据表明，这些模式中的任何一种能比其中的另外一种缔造出更安全的软件。多数软件开发模式在文档中很少提及“安全”和“质量”。
  • 敏捷开发模式不行的原因：安全最佳实践不够深入。
  • 通用评估准则不行的原因：CC所提供的知识表明安全相关的特性已经按照预期执行的证据，他的目标并不是确保监控程序不出现任何实现上的安全bug。

第二部分 对SDL的需求软件安全开发生命周期过程

第0阶段：教育和意识

  • 微软的bug bush本身是为了找出安全bug，但他的娱乐性远远高于其本身涉及的技术。奠定了微软整个安全教育的根基。还有安全意识演讲，应包含可信计算概述、SDL简介、安全设计基础、威胁建模、模糊测试介绍、安全编码最佳实践。微软所有工程人员每年必须至少参加一次安全培训，也可将在线培训拍下来放到公司内网中。成功的安全教育与意识培训需要三点:
    • 管理层明确支持
    • 富有经验演讲者
    • 持续进行的教育

第1阶段：项目启动

  • 首先判断软件安全开发生命周期是否覆盖应用。原则上来说，所有的软件都能从SDL过程中受益。接着指定一个在SDL过程中指引开发团队安全活动的安全人员，其主要职责是确保最终安全审核能够完成。这个员工叫做安全顾问。安全顾问是开发团队与安全团队之间沟通的桥梁，安全顾问需要召集开发团队举行SDL启动会议，对开发团队的设计与威胁模型进行评审，分析并对bug进行分类。接着是组建安全领导团队，确保在bug跟踪管理过程中包含有安全与隐私类bug。最后建立“bug标准”。

第2阶段：定义并遵从设计最佳实践

  • 常见安全设计原则：
    • 经济机制：保证代码与设计尽可能简单、紧凑。
    • 默认失效保护：对任何请求默认应加以拒绝。
    • 完全中介：每一个访问受保护对象的行为都应当被检查
    • 公开设计：与“不公开即安全”的原则相对而言，认为设计本身不应具有神秘感。
    • 权限分离：切勿允许基于单一条件的操作过程
    • 最小特权：只授予执行操作所必需的最小特权
    • 最少公共机制：使诸如文件以及变量等类似的共享资源尽可能少。
    • 心理可接受程度
  • 进行受攻击面分析与降低，不仅要理解应用的受攻击面组成，而且还要理解如何才能有效地降低受攻击面，从而阻止利用潜在的缺陷代码进行攻击的攻击者。ASR主要有一下几步：确定该特性是否真的很重要、谁需要从哪里访问这些功能、降低特权。

第3阶段：产品风险评估

安全风险评估被用于判断系统中易受攻击的漏洞级别。需要考虑以下几个问题：安装问题、受攻击面问题、移动代码问题、安全特性相关问题、常规问题、分析问卷。
隐私影响分级是产品风险评估的第二部分，这个分级包括三个策略值：隐私分级1，隐私分级2和隐私分级3。如果应用满足以下任何一项，就具有最高可能性隐私分级，因而要求具有最高隐私保护职责。
应用传输匿名数据给软件开发人员或者第三方，则被划分为隐私分级2.如果应用不包含1和2中任何一种行为，则被划分为隐私分级

隐私分级1 满足：
image

隐私分级2：应用传输匿名数据给软件开发人员或第三方。

隐私分级3：应用不包含隐私分级1、2中的任何一种行为。

统一各种因素

第4阶段：风险分析

1 威胁建模产物

  • 威胁建模产物是描述应用背景信息并定义高层应用模型的文件，通常包括：应用场景、外部依赖性、安全假设、外部安全备注。威胁建模过程如下：
    • 定义应用场景
    • 收集外部依赖列表
    • 定义安全假设
    • 创建外部安全备注
    • 绘制数据流图
    • 确定威胁类型
    • 识别系统威胁
    • 判断风险
    • 规划消减措施
  • 威胁模型可以用来辅助代码评审和测试。
  • 威胁建模过程的主要输出成果就是描述应用背景信息并定义高层应用模型的文件，通常情况下使用数据流图（DFD）；需保护的资产清单；依等级划分的系统威胁以及消减威胁 的措施清单（可选）等。
  • 一旦威胁模型完成之后，文档就应该被纳入普通文档控制策略之中。
  • 一个威胁模型应随着威胁的演变至少保证每六个月更新一次。

2 对什么进行建模

  • 大型软件产品通常由较小的模块组成，而且对较小的模块进行建模相对于针对整个产 品进行建模，一般效率更高一些。
  • 一个系统即使在微观层面表现得非常安全，如果对于其他功能组件的安全假设存在失误，那么在两个功能组件交互时也会导致不安全的情况发生。

3 创建威胁模型

  • 建模过程包括：
    • 准备：系统设计人员负责准备过程，并从开发团队中得到输入以绘制数据流图。
    • 分析：整个分析过程中发现的威胁都应被记录在威胁模型文档中。
    • 定义消减措施：团队应仔细分析模型以决定最适宜的消减措施。

4 威胁建模过程

定义应用场景
  • 团队需要明确关键威胁场景是什么，还应该考虑内部威胁场景。
收集外部依赖列表
  • 我们设计的应用一定难以做到自给自足：其一定运行在操作系统中，并且可能用到了数据库、 Web服务器或者高级应用框架。
  • 记录应用所依赖的所有其他代码也是相当重要的。应当考虑到默认的系统加固配置。
定义安全假设
  • 这是至关重要的一步。如果对应用所依赖的系统环境做出不准确的安全假设，应用可能就被陷于极度危险之中。
  • Linux中存放的敏感文件通常以限制仅root访问方式加以保护。
创建外部安全备注
  • 如果使用SELinux，可能就不会出现这种情况，因为SELinux可以对访问控制强行施加策略管理，以阻止信息被泄露。
  • 微软Windows Vista就带有相当充分的完整性控制措施。
  • 安全假设是你从外部依赖中希望获得的一种保证。
  • 威胁模型需要帮助终端用户至少了解、明确如何确保功能正常运转无误的安全相关信息。
绘制待建模应用的一个或多个数据流图（DFD）
  • 最高级别的数据流图是场景图，其集中展现了开发中的系统以及与系统发生交互的外部实体。场景图有助于理解与代码发生交互的对象。
  • 信任边界是用于表现数据在低特权向高特权移动时应用中的分水岭。这些边界有助于在应用中定位那些有待于进一步分析数据正确与否的区域，但它们也可能成为敏感数据泄漏之处。
确定威胁类型
  • 微软使用STRIDE威胁分类法来识别各种威胁类型。STRIDE从攻击者的角度考虑威胁。
  • STRIDE的组成部分如下：
    • 假冒ID(Spoofing Identity)：假冒威胁允许入侵者伪装成某对象或某人
    • 篡改(Tampering)：篡改威胁包含对于数据以及代码的各种恶意修改。
    • 抵赖(Repudiation)：一个入侵者通过拒绝执行一个其他团队既无法证实也无法反对的行为而产生抵赖威胁。
    • 信息泄漏(Information Disclosure)：信息泄露威胁包含将信息泄露给那些未经授权获得访问的个体。
    • 拒绝服务(Denial of Service)：拒绝服务(DoS)攻击通过使得Web服务器临时性不可用而使有效用户提供的服务被拒绝或降低级别。
    • 特权提升(Elevation of Privilege)：特权提升(EoP)通常发生在一个用户获得更高的能力场景之下。
  • CIA定义了如下的安全属性：
    • 私密性：确保信息不被未授权用户访问。
    • 完整性：确保信息不被未授权用户以一种授权用户无法检测的方式随意更改。
    • 可用性：确保主体(用户或计算机)拥有适宜的资源访问。
识别系统威胁

  • 一旦完成数据流图，就需要列出所有的数据流图元素(通常也就是资产)，因为需要保护这些元素免受攻击。

  • 几乎所有的数据流都是双向的，应当以分离的眼光审视。

  • 一旦数据流图元素的清单完成，就可以将STRIDE模型与数据流图元素类型之间的映射关系用于清单中的每一元素。

    数据流图元素类型 S X R I D E
    外部实体 X X
    数据流 X X X
    数据存储 X + X X
    过程 X X X X X X

  • 显而易见，==数据流图中的任何元素会成为攻击的对象，潜在攻击的具体类型取决于数据流图元素类型。

    第四行的+代表：如果存储的数据中包含日志或审计数据，抵赖就成为一种潜在的威胁，因为如果数据被以其他方式恶意修改之后，入侵者就可以掩藏自身的踪迹或者某一罪犯就可能清除一项交易记录。

  • 绝大多数，但并非全部，针对数据存储以及数据流的拒绝服务攻击是旨在于攻击某一剑数据流终点或者为数据存储提供服务过程。

  • 许多假冒类威胁事实上是一种篡改类威胁。术语假冒（Spoofing）通常会被滥用。

    • 假冒web服务器：入侵者可以通过cache或者DNS欺骗等方式假冒web服务器。
    • 拼写误导：入侵者可以创建一个注入 MicrosOft.com （留意数字0替代了原本的字母o）有效的域名，并构建一个与Microsoft内容几乎可以乱真的页面。
判断风险

  • 安全专家通常使用数值计算判断风险高低。

  • 可以使用此公式进行风险计算： 风险=受攻击的几率 × 潜在伤害

    由于使用数值进行风险计算很难确保其稳定性与准确性，所以谨慎使用数值计算方法。

  • 微软创建了一个bug Bar来定义威胁的特征以及风险的级别。与简单使用数值不同的是，风险评级被置换为来自微软安全响应中心（MSRC） 的安全公告评级。风险级别1最高，而4则最低。

  • 假冒威胁风险评级如图所示：

    image

    篡改威胁风险评级如图所示：

    image

    信息泄露威胁评级：

    image

    DoS威胁评级：

    image

    EoP威胁评级：

    image

  • 在风险识别阶段的最后，应当按照风险级别从高到低，对威胁进行评级。

    • 风险级别为1、2的通常应该在开发过程中就被处理。
    • 风险级别为3的威胁应当在产品成为预发行版本之前修复。
    • 风险级别为4的威胁仅在时间允许的情况下应修复。
规划消减措施

  • 通常我们提到的是对策或者保护措施、消减措施用于降低或消灭威胁所带来的风险。

    • 保持现状：对于低风险的威胁来说，保持现状可能是一条行之有效的策略。
    • 移除该特性：这是唯一一种将风险降低为0的方法。
    • 关闭该特性：仅适用于降低该风险发生的几率。
    • 警告用户：提醒绝大多数用户，尤其是非技术型用户避免做出不可信的决定。
    • 采取针对性技术措施：釆用诸如认证、加密之类的安全机制以解决特定问题。

    对于每一种消减机制，可以使用一个或多个具体的技术来实现目标。

  • 对付威胁的下一步就是在威胁模型中找出所有威胁，寻找相应的消减机制并判断最适用的消减技术。

  • 传输层协议通常通常因为已得到证实和易于实现而成为消减威胁的首选方式。

    • SSL/TLS通过加密解决了保密性问题。
    • SSL/TLS通过消息认证代码 MAC 解决了篡改类威胁。
    • SSL/TLS通过提供认证服务解决了针对Web应用的假冒威胁。

  • 从Pet Shop用户到Web应用之间的双向数据流

    数据存储是篡改、信息泄露、DoS以及潜在的抵赖攻击的目标。

    篡改威胁通常可采用访问控制列表、哈希函数加密(Hash)、数字签名或者物理地址等类似完整性技术来消减。

  • 针对处理过程的篡改威胁可以采用类似针对日志类威胁的措施消减，这些通常被用于保护代码。

    • 访问控制列表
    • 物理地址
    • 数字签名

  • 针对EoP威胁的两个措施

    • 一是授权仅有合法用户可以访问代码
    • 二是尽可能以最小特权运行代码

5 利用威胁模型辅助代码评审

  • 威胁建模过程中的交付物之一就是一个系统输入点清单。

6 利用威胁模型辅助测试

  • 针对特定的威胁类型（如：假冒和篡改）应有特定的消减措施。
  • 这些措施本身也可能遭受攻击，应明确如何构造攻击进行渗透测试。

9.7关键成功因子和指标

  • 最低限度，威胁模型也应被评为“OK”，而且用于渗透测试的部分至少也应为“好" 或者以上。
分级 评论
无威胁模型（0） 没有相应的威胁模型很显然是不能被接受的，因为这标志着根本没有考虑威胁
不可接受（1） 威胁模型过于陈旧：
当前设计与威胁模型中所定义的有明显差异
文档中的日期显示其已经过期超过12个月
OK（2） • 一个数据流图或者以下清单：
＞资产（过程、数据存储、数据流、外部实体）
＞用户
＞信任边界（机器到机器，用户态到内核态，反之亦然；高权限到低权限，’反之亦然） •至少为每一个软件资产详细分析一个威胁
•对所有风险级别1、2、3的威胁提供消减措施
•模型保持最新
好（3） •威胁模型符合所有“OK”威胁模型定义
•数据流图中匿名、身份认证、本地和远程用户均有所展现
•所有的S、T、I和E威胁都已被识别并按照消减或接受进行分类
优秀（4） •威胁模型符合所有“好”威胁模型定义
•所有STRIDE威胁都已被识别并且具备消减措施、外部安全备注或者承认依赖性
•每种威胁都已采取消减措施
•外部安全备注包括创建面向客户的文档（来自外部安全备注）的规划，该文档用于解释如何安全地 使用技术以及如何取舍

第5阶段：创建安全文档、工具以及客户最佳实践

创建指导性安全最佳实践文档，主要包括以下几类：安装文档、主线产品使用文档、帮助文档、开发人员文档

第6阶段：安全编码策略

  • 使用编译器内置防御特性，这些保护性的代码是由编译器自动添加，无需开发人员进行干预，主要的防护选项：
    • 缓冲区安全检查：/GS
    • 安全异常处理：/SAFESEH
    • 数据执行防护兼容性：/NXCOMPAT
  • 使用源代码分析工具本身并不能使软件变得更安全，很容易落到陷阱中。但源代码分析工具也有益处。切勿使用违禁函数，减少潜在可被利用的编码结构或设计，使用安全编码检查清单。

第7阶段：安全测试策略

  • 模糊测试最初用于发现可靠性bug，后来证明其也可以发现某类安全bug。模糊操作旨在通过反复解释代码分析数据结构，也可称之为解析器，有三种：文件格式解析器、网络协议解析器、API和其他零散解析器。渗透测试是一个用于在信息系统在中发现脆弱性的测试过程。还有一种测试方式就是运行时验证。

第8阶段：安全推进活动

  • 一次成功的推进活动需要周密的计划以及从一开始就被列入日程计划中的时间投入。软件开发团队最低程度也需要接受专门的培训，以使其对安全推进活动的期望值以及推进流程等有所了解。计算机上运行的所有代码或成为你软件的一部分的代码都必须被评审，而且该评审与代码年限没有关系。

架构师和程序经理们需要对威胁模型进行不止一次的评审。在安全推进活动期间的程序化管理方式推动重估受攻击面的任务完成，会获得两个主要的收益：好的安全习惯和有助于推动代码评审任务的优先程度评级。最终，编写终端用户文档的作者和编辑们都应当对他们所有的草稿文档进行评审，以验证安全最佳实践是正确无误的，且文档中没有述及潜在有危害的实践。

第9阶段：最终安全评审

  • 完整的最终安全评审过程有四个步骤，一是产品团队协调，这一部分不是纯技术性的活动，团队必须填写一个调查问卷。二是再次评审威胁模型，三是未修复的安全bug评审，验证那些标记为“暂不修复”的安全bug是否可真正对其不予理睬。四是工具有效性验证。
    这些内容不只是读书笔记，还让我对自己的大学学习生活进行了反思。

第10阶段：安全响应规划

  • 为什么准备响应？因为开发团队一定会出错，新漏洞一定会出现，规则一定会发生变化。准备安全响应包含两个过程，第一是建立一个安全响应过程，第二就是每一个产品开发团队的责任，组建一个安全响应中心

  • 产品团队有效的执行响应过程是十分必要的，有两个指导原则，一是准备安全响应的时间应位于漏洞被上报之前；二是每一个软件团队都必须做好安全响应准备。主要步骤：组建相应团队、支持全线产品、支持所有客户、使产品具备更新能力、在研究人员之前找到漏洞。

第11阶段：产品发布

  • 如需软件被签字通过，安全与隐私团队就必须认可以下事实：SDL过程被正确无误地贯彻落实了。

第12阶段：安全响应执行

  • 遵从你的计划，如果有新上报的漏洞，保持冷静，记住欲速则不达，留意可能改变计划的事件，遵从你的计划；尽你所能补救，深谙取舍之道

Core.Software.Security.Security.at.the.Source.CN.软件安全.从源头开始

第2章 安全开发生命周期

安全开发生命周期（Secure Development Lifestyle，SDL）是软件开发生命周期（Software Development Lifestyle，SDLC）的关键组成部分。

本书的目标是基于最少的资源和最佳实践创建SDL，而不是所需资源超出大多数软件安全团队所能接受的范围。

2.1 克服软件安全中的挑战

SDL是软件安全演化的关键步骤，有助于人们重视构建安全的软件开发生命周期。

SDL拥有开发行业、政府标准和最佳实践强化软件所需的所有活动与安全控制，它们也是SDL的基本组件。

SDL程序的实现，能够保证良好的企业软件设计和开发固有的安全，而不是在产品发布后。

最著名的SDL模型是可信计算安全开发生命周期（或SDL），微软已经将它应用到需要承受恶意攻击的软件开发中。微软的SDL已经发展了十多年，被认为是排名前三的成熟模型。其他受欢迎的SDL模型有Cigital公司的软件安全触点模型（Software Security Touchpoints model）、OWASP SDL和思科的安全开发生命周期（Cisco Secure Development Lifecycle，CSDL）。

2.2 软件安全成熟度模型

BSMM是一项面向真实软件安全措施的研究，帮助你确定软件安全措施和如何组织工作时间。

  • 策略和度量标准
  • 符合性和政策
  • 培训
  • 攻击模型
  • 安全特征和设计
  • 标准和要求
  • 架构分析
  • 代码审查
  • 安全测试
  • 渗透测试
  • 软件环境
  • 配置和漏洞管理网


1. 安全评估 (A1)

安全评估是安全开发生命周期的第一个阶段，在这个阶段中，要解决四项原则问题：

  1. 软件满足客户任务和关键程度如何？
  2. 软件所必需的安全目标是什么？
  3. 哪些法规和政策是适用于确定需要保护的内容？
  4. 在软件运行的环境中可能存在哪些威胁？

在这一阶段，软件安全团队提早参与项目并主持发现会议，创建SDL项目计划。启动隐私影响评估（PIA），PIA主要包含以下要点：

  • 立法摘要
  • 所需的工艺步骤
  • 技术和技巧
  • 其他资源

安全评估成功的关键因素和度量标准包括：

  • 软件安全团队循环的时间
  • 参加SDL的利益相关者的百分比
  • SDL活动映射到开发活动的百分比
  • 安全目标满足的百分比

2. 架构（A2）

在安全开发生命周期的第二阶段，安全方面的考虑被带入软件开发生命周期，以确保所有的威胁、要求、功能和集成方面的潜在制约因素均被考虑到。

威胁建模五个步骤：

  1. 确定安全目标
  2. 调查应用程序
  3. 分解它
  4. 识别威胁
  5. 确定漏洞

DREAD模型：

DREAD模型包括潜在损害、可重复性、可利用性、受影响的用户和可发现性，使用1-10建立风险评级，数字越高，风险越严重。DREAD算法用来计算风险值，是DREAD类别的平均值。

成功的关键因素和度量标准：

  • 业务微威胁、技术威胁和威胁参与者的列表
  • 这个阶段之后不满足的安全目标个数
  • 遵守公司政策的百分比
  • 软件入口点的数量
  • 风险接受、减轻和容忍的百分比
  • 重新定义的初始软件需求百分比
  • 产品中计划的软件体系结构的变化数量
  • 根据安全要求所需的软件体系结构更改数量


3. 设计和开发（A3）

设计和开发是软件最终用户最为关心的部分。在这个阶段你会做策略一致性分析，创建测试计划文档，更新威胁模型(根据需要)，进行安全性设计分析和总结，以及做隐私实施评估等，帮助你安全地部署软件、建立开发最佳实践，从而在开发阶段的早期消除安全问题和隐私问题。你将会在SDL的设计和开发(A3)以及发布(A4)阶段进行静态分析。

安全测试的通用步骤：

  1. 定义测试脚本
  2. 定义用户社区
  3. 识别项目障碍物
  4. 识别内部资源
  5. 识别外部资源

测试技术主要分为：

  • 白盒：从内部的角度测试软件，包括源代码分析、基于属性、源代码错误注入。
  • 灰盒：设计测试用例的目的是分析源代码，同时也使用黑盒技术，包括源代码错误注入、动态代码分析、二进制错误注入。
  • 黑盒：从外部的角度测试软件，没有关于软件的任何知识，包括二进制错误注入、模糊测试、二进制代码分析、字节码分析、黑盒调试、漏洞扫描、渗透测试。

成功的关键因素和度量标准


4. 设计和开发（A4）

A4阶段是A3阶段策略依赖检查的延续。在这个阶段，任何存在于SDL域之外的策略都要被检查或重新检查。安全测试是一个耗时的过程，需要适当的准备，确保前后一致，并协调所有利益相关方，以及对真正测试内容的深刻理解。安全测试贯穿整个SDLC过程，在典型的SDLC周期中，软件需要通过QA（质量保证）测试，包括单元测试、性能测试、系统测试和回归测试。安全测试用例执行主要从两个方面开展：安全机制和安全测试。对软件产品和相关系统采取的三种特定的测试类型：基准测试、预定测试和探索测试。

代码审查对于发现软件开发过程中的安全缺陷非常有效。代码审查可以让我们在代码测试或安装之前就找到和修复大量安全问题。有四种分析软件应用安全性的基本技术：自动扫描、人工渗透测试、静态分析、人工代码审查。

安全分析工具包括静态分析、动态分析、模糊测试和人工代码检查。每种方法各有优缺点。静态分析是在计算机软件实际上不执行的情况下进行的测试，也称为静态应用程序安全分析（SATA）。动态分析是通过在真实或虚拟处理器上运行程序进行计算机软件分析的方法，也称为动态应用软件安全检测（DAST），用于确认应用软件产品中的漏洞。模糊测试是一种自动化或半自动化的黑盒软件测试技术，为计算机软件输入提供非法的、非预期的数据或随机数据。必须嵌入在SDL中。人工代码审查是通常对软件产品进行逐行检查以发现安全漏洞的方法，具有更高的精确性和质量，但是最耗费资源。

成功的关键因素和度量标准待补充。

5. 发布（A5）

在软件开发生命周期的最后阶段，需要确保软件在发布时是安全的，隐私问题已经被解决到可以接受的程度。以下是A5阶段的关键活动和度量标准：

关键活动：

  1. 漏洞扫描和确认： 对应用程序和数据库进行漏洞扫描，并尝试确认应用程序缺陷的存在。
  2. 渗透测试： 模拟黑客行为对软件系统进行白盒安全分析。
  3. 开源审查： 对开源软件进行资产管理，并确保遵循许可证，满足安全需求。
  4. 最终安全性审查： 对所有安全活动进行重新评估，以确认软件产品是否为发布做好准备。
  5. 最终隐私性审查： 确保隐私问题已经得到妥善解决，并符合相关法律和政策要求。

度量标准：

  1. 遵守公司策略的百分比： 衡量软件发布过程中遵守公司安全策略的程度。
  2. 安全漏洞扫描和渗透测试发现的安全问题的数量、类型和严重性： 评估安全测试活动的效果。
  3. 发现的安全问题的修复数量： 衡量发现的安全问题得到了多少修复。
  4. 发现的严重问题的数量、类型、严重性： 统计发现的严重安全问题，以便进一步分析和解决。
  5. 遵守安全和隐私需求的百分比： 评估软件产品在安全和隐私方面的整体符合程度。

成功的关键因素和度量标准将有助于确保软件在发布时达到预期的安全和隐私标准，提高用户信任度和软件质量。

posted @ 2024-05-12 19:56  20211309宁心宇  阅读(17)  评论(0)  编辑  收藏  举报