Fortify SCA基于可执行文件或.o文件构建

我正在尝试强化静态分析以编写用于创建二进制文件的C++代码。但是，这个构建需要花费数小时 - 有时甚至超过一天 - 才能完成。Fortify SCA基于可执行文件或.o文件构建

为了解决这个问题，我尝试通过创建一个伪归档文件来作为目标来单独构建所有的.o文件。我在这种方法中看到的优点是代码不属于我们的团队，不需要构建，并且链接时间也可以节省。当我这样做时，我们看到构建时间方面的巨大收益。

但是，我的团队中的一个人认为这可能会导致错误的肯定和错误的否定，因为它错过了与我们所有权之外的代码的交互。他给出的一个例子是，在我们所有权之外的API调用之间共享对象。换句话说，我们将无法知道您的域外对象的操作。但是，当所有的文件所有者为他们的代码做同样的事情时，这不会被处理吗？

请告知我的方法是否正确。

来源

2013-02-25 Karthick S

您是否在每个构建版本上运行SCA？构建的频率如何？通常每周一次是您应该使用SCA进行扫描的最常见次数。 – LaJmOn 2013-04-02 17:43:51

Hi LaJmOn，因为我们每两周都有一次冲刺，每周跑步可能为时已晚。所以，我们更喜欢更短的周期。更重要的是，我们不希望被Fortify的速度所限制。 – 2013-04-03 04:51:05

您的方法可能会导致误报，但更可能出现漏报，这更糟糕，和/或风险评级太低。

的数据流分析器使用全局，过程间污点传播分析来检测数据的源（用户输入）之间的流动和水槽（危险函数调用）。

如果数据流分析器找不到接收器，那么分析器将停止在这种污点传播之后移动到另一个传感器，并漏掉漏洞（错误否定）。

下面的伪代码既是PII曝光和SQL注入的示例：

public static void main(String args[]) throws Exception { 
    ResultSet results = SQLInj(args); 
    System.out.println(results.Password); 
} 

public static ResultSet SQLInj(String args[]) { 
    String query = "SELECT * FROM user_data WHERE last_name = '" + args[1] + "'"; 
    Statement statement = connection.createStatement(); 
    ResultSet results = statement.executeQuery(query); 
}

源是main-> ARGS []和宿是SQLInj-> executeQuery（）。

如果函数SQLInj驻留在未扫描的代码中（而不是您团队的代码），将无法找到SQL注入问题，因为数据流分析程序从未找到接收器。语义分析器可以通过查找“密码”一词找到PII的暴露，但给出的置信度低得多。

来源

2013-04-02 17:43:55 LaJmOn

嗨LaJmOn，我想了解这是怎么发生的。请帮我理解/指向相关文件。 – 2013-04-03 04:52:10

那足够的解释了吗？我也可以给你一些关于如何减少C++扫描时间的想法。 – LaJmOn 2013-04-09 17:58:18

我明白你现在所说的话。你可以给我一些关于C++扫描时间减少的想法吗？ – 2013-04-22 08:08:58

Fortify SCA基于可执行文件或.o文件构建

回答

相关问题