plstudio1的博客

数据相关路径遍历在遍历过程中除了要结合路径的自有属性（比如来源，去向等）进行分析外，还要对路径所途径的数据进行处理并分析，而且，路径的自有属性可能会受到途径数据的影响。对于数据相关路径遍历来说，尽管在被分析代码结构相对简单的时候，能够实现完全的路径遍历，但对于复杂软件来说，被分析代码中往往会存在循环、递归、并发、异常处理等代码结构，而这些代码结构可能会导致路径过长、海量路径数、抽象路径数、未知路径数等情形的出现，这就使得完全路径遍历非常困难。理论上，完全路径遍历才能够确保代码安全性分析的准确性。

构建循环模型通常是以代码解析为基础进行的，代码解析的结果是代码元数据。循环定义信息可直接从代码元数据中提取。通过分析变量应用元数据可获取循环数据集合。以循环体内的元数据为基础，对循环体代码进行有效的块划分，并基于块划分结果，构建起以循环体开始行为起点，以各块的起始行为节点，并依据块类型及块间关系将各节点连接在一起，以循环体终止行为终点，可构建循环体控制流图。

在静态分析阶段，除了进行普通的静态分析，还可以进行静态缺陷检测。静态缺陷检测是一种以在传统静态分析的技术基础上，数据流分析为基础，以路径遍历为手段，以发现尽量多的“通用缺陷”为目标的技术手段。将静态缺陷检测同用例自动生成、静态仿真、自动化测试等技术相结合，“通用缺陷”同项目的具体设计无关，比如著名的除0、越界访问、缓冲区溢出等。发现通用缺陷后，结合所在模块的输入数据的取值范围，可以自动生成对应于所发现缺陷的特定用例。

分析测试过程中各个测试环节，将可web服务化的环节及不可web服务化的环节区分开，对于不可web服务化的环节还要进行可放到云服务器和不可放到云服务器区分，从而制定出更具通用性的TAAS架构。

在软件缺陷预测领域，粒度指的是缺陷库中每条样本的项目粒度.其中可以分为类粒度、文件粒度或者包粒度等。不同的开发语言有不同的层级的模块粒度，在软件缺陷预测领域，一般来说，在预测效果能够满足要求的情况下，粒度越小，预测的结果的可用性越强，可用公开训练数据越少，预测模型构建难度也越高，粒度越大，预测的结果的可用性越小，可用公开训练数据越多，预测模型构建难度也越低。

​软件特征、研发人员和研发环境三个方面相互作用，共同导致了缺陷的产生。​

既然是在单值得情况下函数返回值类型应定义为void,存在多值的时候在函数结尾处返回一个变量更为恰当，那么一般情况下，应该要求函数的返回值不能为常量。

一般来说，比较给变量赋缺省值带来的好处以及问题，不给变量赋初值是更好的选择。但在特殊情况下，如变量是逻辑类型或枚举类型，缺省值恰好是变量应用时所需要的值的概率会大幅增加，并且应用对时间成本并不敏感时，可以考虑为变量赋予缺省值。

软件代码的安全性及可靠性直接关乎相关产品的品质。为了提高代码的安全性及可靠性，各种编码规则标准应运而生。MISRA-C标准由于其起步早、应用广泛、阐述严谨、可操作性强、与时俱进等特性，在众多编码标准中具有举足轻重的地位，是没有争议的编码标准的标杆。考虑到代码安全性及可靠性的重要性，国内也定制了许多编码标准。就目前来说，还没有哪个标准能够同MISRC-C相比较。相对而言，在国内的编码标准中，GJB 8114-2013是比较完善且应用范围较广的编码标准。然而，仅就GJB 8114-2013中的规则来说，还是有部

在CWE范畴内，讨论的核心内容是“弱点”及“不足”，而在软件静态分析范畴内，研究的核心内容是“缺陷”及“故障”，CWE已经越来越多的被静态分析用于重要参照标准。因此有必要将这几个关键概念之间的关系梳理清楚。“弱点（Weakness）”定义CWE中对弱点的定义是这样的：弱点是产品中一类错误，在特定的条件下，可能会诱发产品缺陷的发生，此术语应用于对错误的定性，并不考虑这些错误是否在软件生名周期中的设计、实现及其它阶段中真实发生。“不足(Vulnerability)”定义CWE中对...

单元测试是目前动态测试过程中的一个重要环节。在具体测试活动中，要将被测单元中所调用的其它单元进行数据模拟或者功能模拟，以使被测单元不受其它单元所影响。单元测试的后继环节是集成测试，它同单元测试的主要区别就是不对入口单元中调用的其它单元进行模拟。 然而，在测试实践中，很多测试人员抱怨单元测试没有用，或者直接省略掉单元测试环节。因为经常会发生这种情况：一个被测单元及其...

ID: 122 类型：变量 结构：简单 状态：草稿 描述堆溢出是缓冲区溢出的一种情形，分配到内存的堆部分的缓冲区被覆盖的，通常意味着缓冲区是使用malloc（）等函数分配的内存。相关视图与“研究层面”视图(CWE-1000)相关与“开发层面”视图(CWE-699)相关引入模式 阶段 ...

ID: 121 类型: 变量 结构: 简单 状态: 草稿 描述基于堆栈的缓冲区溢出是指被覆盖的缓冲区是在栈上分配的（例如，是一个局部变量，很少是函数的参数）。相关视图与“研究层面”视图(CWE-1000)相关与“开发层面”视图(CWE-699)相关引入模式 阶段 说明 ...

CWE-120: Buffer Copy without Checking Size of Input（不检查输入数据大小就复制缓冲区） ID: 120 类型: 基础 结构: 简单 状态: 不完整 描述在没有验证输入缓冲区的长度小于输出缓冲区的长度的情况下，程序复制输入的缓冲区内容到输出的缓冲区，可能会导致缓冲区溢出。扩展描述...

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer（没能将内存操作限制在边界范围内） ID: 119 类型：类 结构：简单 状态：可用 描述软件在内存缓冲区上执行操作，但它可以读取或写入缓冲区预期边界之外的内存位置。...

CWE-14: Compiler Removal of Code to Clear Buffers（编译器对清除缓冲区语句的删除） ID: 14 类型：变量 结构：简单 状态：草稿 描述源代码中存在清除存储有敏感数据内存块的语句，但是，编译器优化操作使这些语句失效，这也称为“死区删除”。扩展描述在以下时点会出现这样的编译器优化...

一 引言        在测试人员对代码文件进行静态分析过程中，数据流分析占有举足轻重的作用，很多重要的信息，比如不可达语句、DU、DD、UR…等都是基于数据流分析的结果而得出的。以往，数据流分析通常是由测试人员人工完成。测试者在理解代码逻辑的基础上，从被分析代码的起点跟踪数据的流向，直到到达被分析代码的终点。这项工作看起来简单，但是实际做起来却往往令测试人员感到非常头疼。主要原因有三点：1.数据...

  一 引言        在测试人员对代码文件进行静态分析过程中，数据流分析占有举足轻重的作用，很多重要的信息，比如不可达语句、DU、DD、UR…等都是基于数据流分析的结果而得出的。以往，数据流分析通常是由测试人员人工完成。测试者在理解代码逻辑的基础上，从被分析代码的起点跟踪数据的流向，直到到达被分析代码的终点。这项工作看起来简单，但是实际做起来却往往令测试人员感到非常头疼。主要原因有三点：1....

          在白盒测试中，测试人员重要任务之一就是查找不可达语句。很多软件相关人员尤其是开发人员都存在一种错误的观念，他们认为不可达语句对程序的质量影响不大，不可达语句仅仅增加了代码的存储容量，降低了代码的可读性而已。可他们没有想到这一点：在设计上，是不会设计出不可达语句的，所以正常的编码中是不应该存在不可达语句的，尤其是绝对不能出现路径不可达语句与逻辑不可达语句。如果存在这两类不可达语句...