开发阶段为引入漏洞关键的阶段，超过50%的安全漏洞由错误的编码产生。究其原因是因为开发人员对所使用的语言与技术的安全特性不了解，写出的代码符合功能上的需求，但缺乏安全上的考虑。青穗软件联合国内外编写了各种主流语言的标准安全编码规范。根据不同的需求，能够为客户定制符合企业自身技术标准的安全编码规范。

主流安全编码列表：

C/C++安全编码规范  

J*a安全编码规范

J*aScript安全编码规范

Python安全编码规范

PHP安全编码规范

CSharp安全编码规范

代码审核规范

代码审核机制是确保编码质量的关键机制。由于工作量的缘故，采用静态扫描工具代替人工是当前的趋势。但静态扫描工具并非是全自动化的工具，如果企业没有相应的安全漏洞基线、扫描流程规范与安全负责人，那么工具并不能带来很大的作用，反而有可能带来额外的工作量。

漏洞基线

定义漏洞基线可以对应到标准S-SDLC威胁建模中定义威胁的部分。通过把项目可能有的威胁对应到漏洞扫描基线中，可以通过工具快速的检测项目应对威胁的安全措施有无实现扫描基线的建立可以大量减少后期排查漏洞时间。

扫描流程规范

各部门之间的协作不畅往往是企业无法用好静态漏洞审核工具的原因之一。青穗软件通过汲取国内外成功案例的经验，具备能力为客户制定合理的扫描流程规范。

主要使用工具

青穗软件具有丰富的各类主流静态代码扫描的使用经验、能够为企业用户提供的使用指导。 提供支持的主要工具列表：

HP Fortify

IBM App Scan

Fortify WebInspect

Sonaqube

漏洞培训

青穗软件包含详尽的各语言漏洞培训服务。

带的例子，扫描结果：主要以Unreleased Resource:Streams这个漏洞为试验对像。

前面说过，要过滤，得新建一个过滤文件。我的是在E盘下，新建一个文本文件test_filter.txt，内容如下：

#Tha category that will be filtered form. scan output
Poor Loing Practice

#Than instance ID of a specific issue to be filtered from scan
#output
60AC727CCEEDE041DE984E7CE6836177

#Tha specific Rule ID that leads to the reporting of a specific #issue in
#the scan output:in this case the data flow sink for a Path Manipulation #issue.
 74714BFC-EDF7-445B-8672-0996214D5845

instance ID 和 Rule ID，每个漏洞类型都不一样，在扫描后的Detail中有标明，如果需要过滤这个漏洞，请把这两个ID到过滤文件中的相应位置，请看图：

上面的文件保存好之后，重新扫描这个例子，参数要特别注意，在Scan中，-filter下面输入过滤文件的地址（这个地方真是惨啊，我都试了N遍，因为资料都是说直接加文件的，我开始是"-filter E:\test_ftilter.txt"不行，然后又把文件放在项目下，直接"-filter test_filter.txt"不行，然后是"-filter"又提示没有参数，总之，试了N遍啊的N遍，没想到直接是下一行，就如下图这样。。我看资料都看N遍了，中文，英文的，无奈，资料上面都是命令行形式。。唉。。原谅我吐口水。。）：

过滤后的扫描结果：

可以看出之前要过滤的那个漏洞类型：Unreleased Resource:Streams已经没了。哈哈，太高兴啦后一定得注意：过滤文件中的两个ID。还有-filter这个参数。。完啦。。。

.数据从一个不可信赖的数据源进入应用程序。 在这种情况下，数据经由getParameter()到后台。 
2. 数据写入到应用程序或系统日志文件中。 这种情况下，数据通过info() 记录下来。为了便于以后的审阅、统计数据收集或调试，应用程序通常使用日志文件来储存事件或事务的历史记录。根据应用程序自身的特性，审阅日志文件可在必要时手动执行，也可以自动执行，即利用工具自动挑选日志中的重要事件或带有某种倾向性的信息。如果攻击者可以向随后会被逐字记录到日志文件的应用程序提供数据，则可能会妨碍或误导日志文件的*的情况是，攻击者可能通过向应用程序提供包括适当字符的输入，在日志文件中插入错误的条目。如果日志文件是自动处理的，那么攻击者可以文件格式或注入意外的字符，从而使文件无法使用。更阴险的攻击可能会导致日志文件中的统计信息发生偏差。通过或其他方式，受到的日志文件可用于掩护攻击者的跟踪轨迹，甚至还可以牵连第三方来执行恶意行为糟糕的情况是，攻击者可能向日志文件注入代码或者其他命令，利用日志处理实用程序中的漏洞。
例 1： 下列 Web 应用程序代码会尝试从一个请求对象中读取整数值。如果数值未被解析为整数，输入就会被记录到日志中，附带一条提示相关情况的错误消息。 

String val = request.getParameter("val");
try {
    int value = Integer.parseInt(val);
} catch (NumberFormatException nfe) {
    log.info("Failed to parse val = " + val);
}

如果用户为“val”提交字符串“twenty-one”，则日志中会记录以下条目：

INFO: Failed to parse val=twenty-one

然而，如果攻击者提交字符串

“twenty-one%0a%0aINFO:+User+loed+out%3dbadguy”，

则日志中会记录以下条目：

INFO: Failed to parse val=twenty-one

INFO: User loed out=badguy

显然，攻击者可以使用同样的机制插入任意日志条目。
有些人认为在移动世界中，典型的 Web 应用程序漏洞（如 Log Forging）是无意义的 -- 为什么用户要攻击自己？但是，谨记移动平台的本质是从各种来源并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高，它们会强制扩展移动应用程序的攻击面（包括跨进程通信）。

例 2：以下代码将例 1 改编为适用于 Android 平台。

String val = this.getIntent().getExtras().getString("val");
try {
int value = Integer.parseInt();
}
catch (NumberFormatException nfe) {
Log.e(TAG, "Failed to parse val = " + val);
}

使用间接方法防止 Log Forging 攻击：创建一组与不同事件一一对应的合法日志条目，这些条目必须记录在日志中，并且仅记录该组条目。要捕获动态内容（如用户注销系统），请务必使用由服务器控制的数值，而非由用户提供的数据。这就确保了日志条目中会直接使用由用户提供的输入。 

可以按以下方式将例 1 重写为与NumberFormatException 对应的预定义日志条目：

public static final String NFE = "Failed to parse val. The input is required to be an integer value."
String val = request.getParameter("val"); try { int value = Integer.parseInt(val); } catch (NumberFormatException nfe) { log.info(NFE); }

下面是 Android 的等同内容：

public static final String NFE = "Failed to parse val. The input is required to be an integer value."
String val = this.getIntent().getExtras().getString("val"); try { int value = Integer.parseInt(); } catch (NumberFormatException nfe) { Log.e(TAG, NFE); }

在某些情况下，这个方法有些不切实际，因为这样一组合法的日志条目实在太大或是太复杂了。这种情况下往往又会退而采用黑名单方法。在输入之前，黑名单会有选择地拒绝或避免潜在的危险字符。然而，不安全字符列表很快就会不完善或过时。更好的方法是创建一份白名单，允许其中的字符出现在日志条目中，并且只接受完全由这些经认可的字符组成的输入。在大多数 Log Forging 攻击中关键的字符是“\n”（换行符），该字符决不能出现在日志条目白名单中。