BDBA (бинарный анализ Black Duck) вводит в заблуждение

В инструменте Black Duck Binary Analysis (он же Protecode) есть несколько вариантов триггинга уязвимостей.

Из справки:

Сфера Triage

Вы можете применить область действия к уязвимой триггеру в стороннем компоненте. При обработке известных уязвимостей вы можете выбрать один из следующих вариантов:

Учетная запись: относится ко всем видам использования компонента в учетной записи компании.

Группа: относится ко всем видам использования компонента в группе.

Приложение: относится к использованию компонента только в одном приложении.

Имя приложения. Относится к использованию компонента в отсканированных приложениях с одинаковым именем приложения.

Хэш файла: применяется к использованию компонента в отсканированных приложениях, имеющих тот же хэш файла

Я хочу сортировать CVE в моей библиотеке, чтобы результаты сортировки переносились на следующие сканы. Я ожидаю, что опция "File hash" должна делать именно это, однако, когда я загружаю свой архив в следующий раз, я все равно вижу тот же CVE, что и не тригированный. В чем дело?

1 ответ

TL;DR - использовать область действия "Группа".

подробности

Документация API делает это немного более понятным

PUT /api/triage/vulnerability/

component - Component name
version - Component version
vulns - List of vulnerability ids
scope - Scope in which the triage affects. Possible values:

- CA - Account wide
- FN - Filename
- FH - File hash
- R - Result
- G - Group

product_id - In FN, FH and R scopes the related product

group_id - In G scope the related group

Таким образом, на самом деле сортировка в инструменте выполняется не против файлов, а против версий библиотеки (компонент библиотеки === в контексте). Нет даже теоретической возможности сортировать файл, потому что вы сортируете версии. Имея это в виду, остальные мысли просты.

Что такое "хэш файла"?

Четко написано, что если вы используете "FH", то product_id потребуется, и продукт является синонимом (в текущем контексте) для загруженного архива с вашими двоичными файлами. Таким образом, у каждого продукта есть один и только один "хэш файла" - хэш загруженного архива. Что делает эту опцию совершенно бесполезной, потому что, я полагаю, один загружается не 100 файлов отдельно, а загружает архив \zip\tar.gz с программным обеспечением, содержащим несколько двоичных файлов. И очевидно, что хэш-архив будет меняться при каждой переупаковке, даже если в файле readme было изменение.

Я хочу сортировать CVE в моей библиотеке, чтобы результаты сортировки переносились на следующие сканы.

Поскольку "файловый хеш" не подходит для этой цели, давайте рассмотрим другие доступные параметры области действия, чтобы увидеть, что мы можем сделать здесь:

Результат

Самый простой и стандартный вариант. В то же время большинство бесполезно. Карты непосредственно на Application область, упомянутая в справке: Applies to uses of the component within the same application only, Короче говоря - никакого переноса.

Имя файла

Я лично нахожу "имя файла" более понятным, чем соответствующий Application name строка в справке. Несмотря на это, это также довольно ясно - сортировка будет перенесена, только если имя архива будет одинаковым. Когда он каким-то образом решает проблему, он вводит новую проблему - проблему дифференциации различных сборок. Обычно мы называем наши молнии как MyCoolBuild_942_ab4e3f так что легко найти и проверить результаты прошлых сборок. Если вам все равно, эта область может быть вариантом, если вы называете ваши молнии как MyCoolBuild.zip,

группа

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

В моем случае вся компания загружает файлы в одну группу, поэтому у нас могут возникнуть некоторые конфликты, однако в руководстве к инструменту сказано, что вы должны использовать суффиксы версий, если вы делаете пользовательские сборки этой библиотеки (для например, исправить некоторые CVE самостоятельно). Если все следуют этому правилу, то именование пользовательских библиотек не 1.0.2 но 1.0.2_company_build тогда не будет конфликтов между сортировками разных команд.

учетная запись

Я не знаю, потому что у меня нет этой опции в нашем экземпляре BDBA -_-

Проверка правильности допущений выше

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

Хэш файла - загрузите один и тот же файл дважды под разными именами и выполните сортировку CVE с областью "FH" - тогда сортировка будет перенесена.

Имя файла - загрузите архив один раз, затем немного измените архив (добавьте пустой текстовый файл внутрь) и загрузите его снова. Triage будет перенесен.

Группа - загрузить одну библиотеку с автоматически определяемой версией, затем изменить двоичный файл и загрузить его под другим именем - Triage будет перенесен.

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

Другие вопросы по тегам