☰

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

tag-icon • tag-icon security vulnerabilities
Сортировка по шкале BDBA (бинарный анализ Black Duck) вводит в заблуждение

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

Из справки:

Область применения сортировки

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

Счет: Применяется ко всем случаям использования компонента в рамках учетной записи компании.

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

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

Имя приложения: Применяется к использованию компонента в сканируемых приложениях, имеющих то же имя приложения.

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

Я хочу сортировать 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 будет необходим, а product является синонимом (в текущем контексте) загруженного архива с вашими бинарниками. Таким образом, каждый продукт имеет один и только один "хэш файла" - хэш загруженного архива. Что делает эту опцию совершенно бесполезной, потому что, я предполагаю, не загружается 100 файлов по отдельности, а загружается archive\zip\tar.gz с программным обеспечением, содержащим несколько бинарников. И очевидно, что хэш архива будет меняться при каждой переупаковке, даже если были изменения в файле readme.

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

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

Результат

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

Имя файла

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

Группа

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

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

Счет

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

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

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

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

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

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

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

Связанный контент