Укрепление ХП. Проблемы при обработке очень больших отчетов fpr на сервере fortify

У нас есть огромная база исходного кода. Мы сканируем его с помощью HP SCA и создаем файл fpr (размер приложения 620 МБ). Затем мы загружаем его на наш сервер fortify с помощью команды «fortifyclient».

После загрузки, если я войду на сервер fortify и углублюсь в детали этого проекта, я увижу, что артефакт находится в стадии «обработки». Он остается в стадии обработки даже через несколько дней. На приборной панели нет способа, с помощью которого я могу остановить/убить/удалить его.

Вопрос 1: Почему обработка занимает так много времени (у нас есть 1 успешно обработанный отчет fpr, который занял 6 дней). Что мы можем сделать, чтобы сделать это быстрее?

Вопрос 2: Если я хочу удалить артефакт, пока он находится в стадии обработки, как это сделать?

Информация о машине: 6 процессоров (Intel(R) Xeon(R) 3,07 ГГц) ОЗУ 36 ГБ

Спасибо,

Дополнение: у нас был 1 отчет, который был успешно обработан ранее в этом месяце для той же кодовой базы. Файл FPR для этого был также такого же размера (610 МБ). Я вижу количество проблем для этого отчета. Вот:

РЕДАКТИРОВАТЬ:

Версия Fortify: Анализатор статического кода Fortify 6.02.0014

Центр безопасности ПО HP Fortify, версия 4.02.0014

Всего выпусков: 157000

Всего проверенных выпусков: 0,0%

Критические проблемы: 4306

Высокий: 151200

Низкий: 1640

средний: 100


sonarqube fortify
person pun    schedule 30.03.2015    source источник
comment
Первое, что вам нужно сделать, это убедиться, что вы используете последнюю версию Fortify (4.21). Второе, что вам нужно сделать, это определить количество проблем по категориям. Похоже, у вас может быть определенная категория, которая производит аномально большое количество проблем. Вы можете сделать это, открыв его в Audit Workbench. Разместите их здесь, и, возможно, мы сможем придумать решение.   -  person James Nix    schedule 31.03.2015
comment
Добавил еще несколько деталей выше. Спасибо   -  person pun    schedule 31.03.2015
comment
157к выпусков - это много вопросов. Разместите запрошенную информацию: Версия Fortify: {your version} Проблемы в категории [X]: {count} Проблемы в категории [Y]: {count} Проблемы в категории [Z]: {count}   -  person James Nix    schedule 31.03.2015
comment
Добавлено выше в описании.   -  person pun    schedule 31.03.2015
comment
Извините, когда я говорю «Категория», я имею в виду SQL Injection, Cross Site Scripting или Null Dereference. Также в 4.02 было несколько проблем с чрезмерным количеством проблем в нескольких категориях. Также убедитесь, что вы используете последние пакеты правил.   -  person James Nix    schedule 01.04.2015
comment
Следующие 2 типа проблем составляют большую часть (около 85%) от общего числа проблем. 1) Постоянный межсайтовый скриптинг 2) Межсайтовый скриптинг: отражено, и из этих 2 только около 10% являются критическими   -  person pun    schedule 01.04.2015
comment
Что это за приложение? Джава? Интернет? Джаваскрипт? Используете ли вы сторонние библиотеки javascript? Имея большую кодовую базу, есть ли у вас несколько копий сторонних библиотек? У Fortify есть проблемы с некоторыми сторонними библиотеками javascript, особенно если присутствует несколько копий. Можете ли вы указать количество ошибок XSS на файл (поддельные имена файлов, такие как A, B, C)? Файл A: [Count], Файл B: [Count] и т. д.   -  person James Nix    schedule 01.04.2015
comment
FILE1.java [1034 (все указывают на 4 разных номера строк)] , FILE2.java [521 все на одном номере строки ] , FILE3.java [64 все на одном номере строки ] и так далее. Означает ли это, что об одной и той же проблеме сообщается несколько раз? если да, проблема в отчете FPR или в сервере Fortify, анализирующем этот отчет?   -  person pun    schedule 02.04.2015
comment
Да, это означает, что о проблеме сообщается несколько раз. Скорее всего, это проблема с SourceAnalyzer. Я бы порекомендовал обновиться до последней версии (4.21) и повторно запустить сканирование. Двумя другими вариантами для DIAGNOSTIC PURPOSES ONLY могут быть: а) исключить затронутые файлы (используя аргумент -exclude для исходного анализатора) или б) изменить рассматриваемые файлы так, чтобы Fortify их не перехватывал.   -  person James Nix    schedule 02.04.2015
comment
Еще одна вещь, на которую стоит обратить внимание, — это предупреждения и ошибки. Они находятся в сводной информации для FPR. Вы можете посмотреть эти данные в Audit Workbench.   -  person James Nix    schedule 02.04.2015
comment
Большое спасибо за ваш вклад. Я буду работать над этими вещами и обновлять   -  person pun    schedule 02.04.2015
comment
Я просто хотел обсудить с вами этот вопрос. Удалось ли вам решить большое количество проблем? Кроме того, версия 4.30 была только что выпущена и должна иметь большие улучшения в SCA и SSC.   -  person James Nix    schedule 24.04.2015
comment
Частично. Попытка создать меньший отчет. Но отчет без исходного кода нам не подойдет. Еще одна вещь, которую я хотел спросить, это о том, где я могу найти некоторые подробности о таблицах по умолчанию в базе данных fortify? Предположим, я хочу удалить отчеты вручную. какие таблицы нужно изменить?   -  person pun    schedule 25.04.2015

Ответы (1)


arrow_upward
1
arrow_downward

Это большой файл FPR, поэтому для его обработки потребуется время. SSC в основном распаковывает огромный ZIP-файл (это и есть файл FPR), а затем передает данные в базу данных. Вот несколько вещей, которые нужно проверить:

  • Проверьте объем памяти, выделенный для SSC. Вам может потребоваться передать до 16 ГБ памяти в качестве значения Xmx для обработки FPR такого размера. Может больше. Самый простой способ узнать это — загрузить FPR, а затем посмотреть процесс Java, который использует ваш сервер приложений. Посмотрите, сколько времени потребуется для достижения максимального объема памяти.
  • Убедитесь, что база данных настроена на производительность. Наличие базы данных на отдельном сервере с файлами данных на другом жестком диске может значительно ускорить обработку.

  • В крайнем случае, вы также можете попробовать уменьшить FPR. Вы можете отключить исходный рендеринг, чтобы исходный код не был связан с файлом FPR. Вы можете сделать это с помощью этой команды:

    sourceanalyzer -b mybuild -disable-source-bundling -fvdl-no-snippets -scan -f mySourcelessResults.fpr

Что касается удаления текущей загрузки, я думаю, вы должны позволить ей закончиться. С некоторой настройкой вы сможете сократить время обработки.

person Eric    schedule 31.03.2015
comment
Спасибо за вашу помощь. Мы попробуем это с большей памятью, выделенной для SSC. А пока не могли бы вы предложить, какую конкретную конфигурацию базы данных мы должны изменить, чтобы повысить производительность. Прямо сейчас я использую базу данных, установленную на том же компьютере с настройками по умолчанию. - person pun; 31.03.2015
comment
Какую базу данных вы используете? - person Eric; 01.04.2015
comment
Мы используем Oracle DB 11. - person pun; 01.04.2015
comment
@ Эрик, я бы не стал отключать исходный рендеринг, так как это усложняет аудит. Хотя советы по настройке полезны, было бы лучше добраться до основной причины большого FPR. - person James Nix; 01.04.2015
comment
@ Джеймс Это усложняет аудит, но вы можете прикрепить исходный код обратно к FPR при открытии его в одном из клиентских инструментов. Вот почему я сказал, что это крайняя мера. Из того, что я слышал, причиной большого FPR является большая кодовая база. Чтобы уменьшить FPR, вы должны либо вырезать исходный код, либо сократить анализ. Я бы предпочел просматривать проблемы в AWB, используя локальный исходный код, чем снижать уровень анализа. @pun Это руководство может помочь: docs.oracle.com/cd/E11882_01 /server.112/e41573.pdf - person Eric; 01.04.2015