Fortify SCA build on an executable or on the .o files

Question

I am trying to do fortify static analysis for C++ code written to create a binary. However, this build is taking hours - sometimes more than a day - to complete.

To workaround this, I tried doing a build of all the .o files alone by creating a fake archive to use as the target. The advantage that I see in this approach is that the code is not owned by our team need not be built and also the linking time is saved. We are seeing huge gains in terms of build time when I do this.

However, one of the guys in my team feels that this could lead to false positives and false negatives since it misses out on the interaction with code outside our ownership. An example he gave was about, shared objects between API calls to a library outside our ownership. In other words, we will not be able to know the manipulation of the object outside your domain. But wouldn't this be handled when all the file owners do the same for their code?

Please advise if my approach is correct or not.

Answer 1

Your approach could result in false positives, but more likely false negatives, which is worse, and/or too low risk ratings.

The data flow analyzer uses global, inter-procedural taint propagation analysis to detect the flow of data between a source (user input) and a sink (dangerous function call).

If the data flow analyzer cannot find the sink, then the analyzer will stop following this taint propagation and move on to another, missing the vulnerability (false negative).

The following pseudo-code is an example of both PII exposure and SQL Injection:

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);
}

The source is main->args[] and the sink is SQLInj->executeQuery().

If the function SQLInj resides in code that is not scanned (not your team's code), the SQL Injection issue will not be found because the data flow analyzer never finds the sink. The PII exposure may be found by the Semantic analyzer by looking for the word "password", but given a much lower confidence rating.