# V5625. OWASP. Referenced package contains vulnerability.

- В каких случаях появляется предупреждение?
- Что делать при появлении предупреждения?
  - Обновление зависимости
  - Замена зависимости
  - Обеспечение безопасности на стороне проекта
- Подавление предупреждений об уязвимых зависимостях

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

Данной проблеме посвящена категория A6: Vulnerable and Outdated Components из списка OWASP Top Ten 2021.

## В каких случаях появляется предупреждение?

К примеру, в проекте может использоваться сборка log4net версии 1.2.13. Это единственная сборка в пакете log4net 2.0.3, который содержит уязвимость CVE-2018-1285. Следовательно, работа с функционалом этой зависимости может привести к появлению уязвимостей и в использующем её проекте.

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

К примеру, одной из зависимостей пакета RepoDb.MySql 1.1.4 является MySql.Data версии 8.0.22 и выше. В свою очередь MySql.Data 8.0.22 зависит от пакетов Google.Protobuf (версии 3.11.4 и выше) и SSH.NET (версии 2016.1.0 и выше).

Анализатору известно, что:

- все версии пакета Google.Protobuf до 3.15.0 содержат уязвимость CVE-2021-22570;
- все версии пакета SSH.NET до 2020.0.2 содержат уязвимость CVE-2022-29245.

Таким образом, любой проект, использующий RepoDb.MySql 1.1.4, может транзитивно зависеть от уязвимых сборок SSH.NET и Google.Protobuf. Уязвимости в таких зависимостях также могут привести к различным проблемам в работе приложения. Тем не менее, вероятность этого меньше, чем в случае с прямыми зависимостями, поэтому уровень достоверности предупреждения будет ниже.

## Что делать при появлении предупреждения?

Если зависимость проекта содержит уязвимость, то для обеспечения безопасности необходимо как-то от неё избавиться или защитить себя от возможных рисков. Для этого в первую очередь необходимо определить, каким образом проект связан с уязвимой библиотекой или пакетом.

Если проект ссылается на зависимость напрямую, то её название (и, возможно, версия) будет явно прописано в списке зависимостей проекта. К примеру, в случае с пакетами такую зависимость можно будет найти в окне NuGet Package Manager на вкладке списка установленных пакетов. В Visual Studio это окно выглядит следующим образом:

Для непрямых (транзитивных) зависимостей может понадобиться отследить цепочку пакетов или библиотек, которые "соединяют" проект и уязвимую зависимость. Для этого можно использовать различные программные средства. К примеру, в среде Visual Studio 2022 есть возможность поиска среди внешних компонентов:

Используя эту возможность, можно найти полную цепочку зависимостей от проекта до уязвимого пакета. Похожий функционал поиска присутствует и в среде JetBrains Rider.

Для получения иерархии зависимостей сборок могут быть полезны такие средства, как JetBrains dotPeek. В нём нужно открыть интересующую сборку и в контекстном меню выбрать пункт References Hierarchy:

На открывшейся панели будет отображено дерево зависимостей выбранной сборки:

Ниже представлены возможные варианты решения проблем с найденными уязвимыми зависимостями.

### Обновление зависимости

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

Отдельно стоит рассмотреть ситуацию, когда проект использует уязвимую зависимость не напрямую. К примеру, проект зависит от сборки "A", зависящей от уязвимой сборки "B".

Если у "B" есть безопасные версии, то можно попробовать одно из следующих решений:

- Обновить сборку "A" – вполне возможно это приведёт к изменению используемой версии "B".
- Сделать сборку "B" прямой зависимостью проекта, указав при этом безопасную версию. Тогда и сборка "A" будет вынуждена её использовать. ВАЖНО: Используя этот вариант, нужно проверить, что зависимости проекта (включая "A") совместимы с новой версией "B". Если это не так, то можно попробовать обновить сборки до версий, которые будут совместимы с безопасной версией "B".

Похожим образом можно решать проблемы и с более "глубокими" зависимостями – к примеру, если проект зависит от сборки "A", которая зависит от сборки "B", зависящей от уязвимой сборки "C".

### Замена зависимости

Если безопасные версии пакета/сборки отсутствуют, или их обновление невозможно по каким-то другим причинам, то, возможно, стоит рассмотреть использование другой библиотеки.

Ситуация несколько сложнее, если проект зависит от уязвимой библиотеки не напрямую. В этом случае замене подлежит прямая зависимость, из-за которой проект становится зависимым от уязвимой библиотеки. То есть если проект зависит от библиотеки "A", которая зависит от уязвимой библиотеки "B", то заменить придётся библиотеку "A".

### Обеспечение безопасности на стороне проекта

Если предыдущие варианты решения не подходят, то необходимо понять, в чём состоит уязвимость используемой библиотеки, и как она может повлиять на работу приложения. Используя эту информацию, нужно внести в код приложения правки, защищающие от эксплуатации уязвимости. Например, можно добавить дополнительную валидацию входных данных или отказаться от использования части функционала зависимости в пользу более безопасных методов.

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

## Подавление предупреждений об уязвимых зависимостях

Так как V5625 является диагностикой уровня проекта, то её срабатывания не связаны с каким-то конкретным фрагментом кода. Поэтому предупреждения этой диагностики нельзя пометить как ложные с помощью добавления в код комментария типа "//-V5625". Также на данный момент отсутствует возможность baselining-а (подавления) таких срабатываний с помощью suppress-файлов.

Для подавления сообщений V5625 используйте файл конфигурации диагностик – текстовый файл с расширением pvsconfig, добавляемый в проект либо solution.

Например, в Visual Studio для добавления файла конфигурации нужно выделить проект или solution и в контекстном меню выбрать пункт 'Add New Item...'. В появившемся окне нужно выбрать 'PVS-Studio Filters File'.

Файл конфигурации, добавленный в проект, действует на все файлы данного проекта. Файл конфигурации, добавленный в solution, действует на все файлы всех проектов, добавленных в данный solution.

Для подавления срабатывания диагностики V5625 на конкретную библиотеку можно добавить в pvsconfig строку следующего вида:

    //-V::5625::{Google.Protobuf 3.6.1}

Тогда анализатор перестанет выдавать срабатывания V5625, содержащие в сообщении подстроку "Google.Protobuf 3.6.1".

Также есть возможность указать уровень:

    //-V::5625:2:{Google.Protobuf 3.6.1}

В этом случае диагностическое правило не будет выдавать срабатывание, если оно имеет второй уровень (Medium), и его сообщение содержит подстроку "Google.Protobuf 3.6.1".

Более подробное описание pvsconfig файлов приведено в документации.

Данная диагностика классифицируется как:

CWE-1035 CWE-1352 OWASP-9.1.3