The analyzer found that the assemblies used in the project may contain some known vulnerabilities. Such dependencies may lead to vulnerabilities in the application.
Such problem is covered by the A6: Vulnerable and Outdated Components category listed in the OWASP Top Ten 2021.
For example, the project uses the log4net assembly of the 1.2.13 version. This is the only assembly in the log4net 2.0.3 package that contains the CVE-2018-1285 vulnerability. Therefore, when a developer uses dependency capabilities, some vulnerabilities may appear in the project that references such dependency.
The analyzer also covers transitive dependencies — dependencies of libraries project depends on.
For example, MySQL.Data (version 8.0.22 and newer) is one of the RepoDb.MySQL 1.1.4 package's dependencies. In turn, MySQL.Data 8.0.22 depends on the Google.Protobuf (version 3.11.4 and newer) and the SSH.NET (version 2016.1.0 and newer) packages.
The analyzer knows that:
Thus, any projects that use RepoDb.MySQL 1.1.4 can transitively depend on the SSH.NET and Google.Protobuf vulnerable assemblies. Vulnerabilities in such dependencies can also cause various problems in apps. Although, these problems are less likely to occur in transitive dependencies than in direct dependencies, and the certainty level of warnings is lower.
If a project dependency contains a vulnerability, it's necessary to get rid of this vulnerability or protect your project from possible risks. This will help secure the project. First, you need to determine if a project references a dependency directly or not.
If a project references a dependency directly, then you can find the dependency's name or even its version in the project dependencies list. To find package dependency, click the Installed tab in the NuGet Package Manager window. In Visual Studio, this window looks as follows:
If a project references a dependency indirectly, you can trace a package chain or a library chain that connect the project with the vulnerable dependency. You can use various software tools to do this. For example, Visual Studio 2022 provides search within external items:
This feature helps find the full chain of project dependencies up to the vulnerable package. A similar search is also available in the JetBrains Rider environment.
With the JetBrains dotPeek tool you can explore the references hierarchy for any assembly. You need to open the needed assembly and click the References Hierarchy item in the shortcut menu:
The opened panel displays the dependency tree of the chosen assembly:
Possible solutions for vulnerable dependencies are examined below.
Typically, not all versions of a package or an assembly contain a vulnerability. If a project depends on a vulnerable item directly, it's better to use another version of the dependency.
Let's consider a case when a project uses an indirect vulnerable dependency. For example, the project depends on an assembly A, and the assembly A depends on a vulnerable assembly B.
If B has secure versions, you can try one of the following scenarios:
You can deal with more deep dependencies in the same way. For example, if a project depends on an assembly A, and the assembly A depends on an assembly B, and an assembly B depends on a vulnerable assembly C.
If there are no secure versions of a package/assembly, or they cannot be updated, try to change the library.
It gets worse if a project depends on a vulnerable library indirectly. In this case, you need to change a direct dependency that is the reason why the project becomes dependent on the vulnerable library. That is, when a project depends on a library A, and the library A depends on a vulnerable library B, then you need to change the library A.
If none of the above scenarios fit, you need to understand the nature of the vulnerability in the used library, and how this vulnerability affects the app. With this information you need to fix the application code. These fixes will protect from an exploit. You can add additional input data validation or refuse to use a part of the dependency capabilities in favor of more secure methods.
Most likely, you will need to suppress the warnings of the diagnostic. Continue reading to found out the way to do it.
Since V5625 is a project-level diagnostic, its warnings are not related to any specific code fragment. That's why you can't mark the analyzer's messages as false positives by adding a comment like "//-V5625" to the code. You can't also baseline such analyzer's warnings with suppress files.
To suppress V5625 messages, use the diagnostic configuration file – a text file with the pvsconfig extension added to a project or a solution.
To add a configuration file in Visual Studio, you need to select a project or a solution and click 'Add New Item...' in the shortcut menu. Then, click 'PVS-Studio Filters File' in the appeared window.
The configuration file added to the project is valid for all files of this project. The configuration file added to the solution is valid for all projects' files added tothis solution.
To suppress the warning of the V5625 diagnostic rule to a specific library, add the following line to pvsconfig:
//-V::5625::{Google.Protobuf 3.6.1}Then the analyzer will stop issuing V5625 that contains the "Google.Protobuf 3.6.1" substring.
You can also specify the level:
//-V::5625:2:{Google.Protobuf 3.6.1}In this case, the diagnostic rule will not issue a warning if it has a second certainty level (Medium), and its warning contains the "Google.Protobuf 3.6.1" substring.
To learn more about the pvsconfig files, read the documentation.
This diagnostic is classified as: