Сборка Fortify SCA на исполняемом файле или файлах .o

Я пытаюсь улучшить статический анализ кода C ++, написанного для создания двоичного файла. Однако на создание этой сборки уходит часы, а иногда и больше суток.

Чтобы обойти это, я попытался выполнить сборку только из всех файлов .o, создав поддельный архив для использования в качестве цели. Преимущество, которое я вижу в этом подходе, заключается в том, что код не принадлежит нашей команде, а также экономится время связывания. Когда я это делаю, мы видим огромную выгоду с точки зрения времени сборки.

Однако один из парней в моей команде считает, что это может привести к ложным срабатываниям и ложным отрицаниям, поскольку не учитывает взаимодействие с кодом, находящимся вне нашей собственности. В качестве примера он привел общие объекты между вызовами API к библиотеке, не принадлежащей нам. Другими словами, мы не сможем узнать о манипуляциях с объектом за пределами вашего домена. Но разве это не произойдет, если все владельцы файлов сделают то же самое со своим кодом?

Посоветуйте, пожалуйста, верен мой подход или нет.


c++ fortify
person Karthick S    schedule 25.02.2013    source источник
comment
Вы используете SCA для каждой сборки? Как часто бывают сборки? Обычно сканирование с помощью SCA следует проводить чаще всего один раз в неделю.   -  person LaJmOn    schedule 02.04.2013
comment
Привет, LaJmOn, так как у нас спринт каждые две недели, еженедельные пробежки могут быть слишком поздно. Итак, мы предпочитаем более короткий цикл. Что еще более важно, мы не хотим ограничиваться скоростью Fortify при выполнении этих прогонов.   -  person Karthick S    schedule 03.04.2013

Ответы (1)


arrow_upward
1
arrow_downward

Ваш подход может привести к ложным срабатываниям, но более вероятен ложноотрицательный результат, что еще хуже, и / или к слишком низким рейтингам риска.

Анализатор потока данных использует глобальный межпроцедурный анализ распространения заражения для обнаружения потока данных между источником (пользовательский ввод) и приемником (вызов опасной функции).

Если анализатор потока данных не может найти приемник, он перестанет следить за этим распространением заражения и перейдет к другому, пропустив уязвимость (ложноотрицательный).

Следующий псевдокод является примером как раскрытия 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 может быть обнаружено семантическим анализатором по слову «пароль», но с гораздо более низким рейтингом достоверности.

person LaJmOn    schedule 02.04.2013
comment
Привет, LaJmOn, я пытаюсь понять, как именно это происходит. Пожалуйста, помогите мне разобраться / укажите мне соответствующие документы. - person Karthick S; 03.04.2013
comment
Этого объяснения было достаточно? Я также могу послать вам некоторые идеи о том, как уменьшить время сканирования C ++. - person LaJmOn; 09.04.2013
comment
Я понимаю, о чем вы сейчас говорите. Не могли бы вы прислать мне несколько идей по сокращению времени сканирования C ++? - person Karthick S; 22.04.2013