XRay fails to detect vulnerability in NuGet package dependency - jfrog-xray

I created a test NuGet package which specifies a dependency on jQuery 1.4.2. XRay correctly detects the security issues on jQuery when uploaded to my Artifactory NuGet server. However, when I upload my test NuGet package which lists jQuery 1.4.2 as a dependency, XRay does not flag my package as a vulnerable.
1) Tested that jQuery 1.4.2 Nuget package in my Artifactory server is correctly detected as vulnerable.
2) Added a dependency to my test package that list jQuery 1.4.2. (I suspected a case-sensitivity issue so I also tried a lowercase dependency as "jquery").
3) Tried other known vulnerable packages besides jQuery
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>RogerCruz.VulnerabilitiesGalore</id>
<title>VulnerabilitiesGalore</title>
<version>1.0.4.0</version>
<owners>Roger Cruz</owners>
<authors>Roger Cruz</authors>
<releaseNotes>A package that depends on known vulnerable packages. Use this to test vulnerability scanners.</releaseNotes>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Test package with known vulnerabilities</description>
<copyright>Copyright Roger Cruz</copyright>
<dependencies>
<dependency id="jQuery" version="[1.4.2]"/>
</dependencies>
</metadata>
<files>
</files>
</package>
These are the commands I am using to create my test NuGet package and to push them to the Artifactory+XRay cloud trial instances.
nuget.exe pack VulnerabilitiesGalore.nuspec
nuget push .\RogerCruz.VulnerabilitiesGalore.1.0.4.nupkg -Source Trial
Artifactory reports my test package to have one dependency. You can see the following property when browsing the package.
nuget.dependency jQuery:[1.4.2]:
In all of my test tries, XRay is not detecting my test package (RogerCruz.VulnerabilitiesGalore) as vulnerable despite having a specified dependency on jQuery 1.4.2 which is vulnerable.
My expectation is that it should have detected it because of this statement:
"Deep Recursive Scan Through All Layers of a NuGet package
Xray recursively peels away the different layers of your NuGet packages and their dependencies ensuring that every software artifact that is included in your software has been scanned for issues and vulnerabilities. "
Src: https://jfrog.com/integration/nuget-xray/

The package RogerCruz.VulnerabilitiesGalore doesn't include jQuery:1.4.2 in it. It`s related to it as a direct runtime dependency as shown in the .nuspec descriptor file.
Deep Recursive Scan means the relation of the package physically inside another package.
for example: if the RogerCruz.VulnerabilitiesGalore package would include jQuery:1.4.2 in it, then JFrog Xray would detect it as vulnerable and recursively scan it by opening package by package like peeling an onion.
A proper use case in the scenario above is building the RogerCruz.VulnerabilitiesGalore by itself or use it as a dependency of another project. At build time the direct dependency jQuery:1.4.2 will be resolved from the remote repository and JFrog Xray will be able to scan it.
In order to achieve full scanning of NuGet projects and it`s transitive dependencies, I would recommend building your project with JFrog CLI
JFrog Xray will know how to analyze the build-info produced by it, scan the project and its dependencies (include transitive)

Related

NuGet does not download exact dependencies if other version is found in the cache

Problem:
NuGet refused to install a package into an empty folder after running nuget install "MyPackage" -Version "1.2.3.4" -OutputDirectory "foo". It complained that the version of a dependency was not the expected one.
It was true that MyPackage required a dependency with an exact version, of which only a slightly lower version was in my local cache. Problem is that the dependency was existing on the server and NuGet could see it. I would expect that NuGet just downloads the correct version from the server, but it didn't.
I could workaround this by adding the -NoCache option to the command, but this disables the cache completely, so that much more is downloaded than actually needed. Is there a better way to solve this?
Additional Details:
The dependency of MyPackage was defined like this:
<dependencies>
<dependency id="MyDependency" version="[5.0.2.1]" />
</dependencies>
The version of MyDependency in my local cache was 5.0.1.2. As said, NuGet complained that this is not exactly the required version ans cancelled the installation, even though 5.0.2.1 was on the server. After adding -NoCache to the command, NuGet downloaded the correct version. After that, -NoCache was not needed anymore to install MyPackage. Version 5.0.2.1 of MyDependendy was then taken from the cache as expected.
My NuGet version is: 6.2.1.2
Side note: using the exact version is important, i.e., a less strict rule for the dependency is no option.

Automating .net framework package installation: resolving package dependency on other packages

Long story short: I am trying to automate package .net framework nuget updates in a solution via VS2019 package manager console and i can't get a package dependencies on other packages (Though i know the data is available because you can see it in the UI).
Long story long: I am trying to automate nuget installation for .net framework and i chose to use the package manager console in visual studio (If there is a preferred option i would love to hear about it). The problem i am trying to solve is this:
Problem input: Package A: version 1, has dependency on package B version > 1. version 2 has a dependency on package B version > 2. Package B: version 1. version 2 has a breaking change. Package C: version 1, has dependency on package B version > 1.
Problem I am trying to solve: I have these 3 packages referenced by the same project. I want to upgrade package A to version 2. Its dependency is package B version > 2. Running package A update to version 2 (via package manager UI or console) will update package B to version 2. Boom! - package C will detect it is missing a method it requires from B version 1 only at runtime!
What i am trying to do - Scripting the installation process prompting the user for these type of dependencies.
My problem - For that i want to get a package dependencies and i can't find the way to do it using the package manager console.
Appreciate some help :)
For that i want to get a package dependencies and i can't find the way
to do it using the package manager console.
We cannot use nuget manage console to get the package dependencies.In addition to UI viewing nuget package dependencies, we can get the dependencies from csproj file in the nuget project A. This is the related content in A.csproj file:
<ItemGroup>
<PackageReference Include="Antlr">
<Version>3.5.0.2</Version>
</PackageReference>
<PackageReference Include="Microsoft.Extensions.Logging">
<Version>3.0.0</Version>
</PackageReference>
</ItemGroup>
Another is that you can view package dependencies is through the nuspec file which is created by command nuget spec (if you use nuspec files to enforce dependencies), which are the documentation you use before packaging the project.
Scripting the installation process prompting the user for these type
of dependencies.
Note: In view of your situation, you cannot use two versions of the nuget package in the same project which will cause version conflict.
Suggestions:
I wonder why you deleted the method required by C when you upgrade B. Basically, when we upgrade and modify the package, we will new features to it without removing the original data and methods to prevent references to other dependent packages in the project from using the corresponding methods.
So you could restore the methods required by the C package in the Package B version two.
If you make a major change to package B version2 and the steps of restoring the method are a bit complicated, I suggest you can make a copy of package B specifically for C packages.
Just rename the Package B version 1 and referenced by Package C to distinguish it from the second version of the B package.
Hope it could help you.

Microsoft.Data.Services.Client Nuget package trying to install wrong dependencies

In Visual Studio 2017 Update 3 (15.3), with latest Nuget (4.3.0.4339), I am trying to upgrade Microsoft.Data.Edm from 5.6.4 --> 5.8.2.
Attempting to gather dependency information for package 'Microsoft.Data.Edm.5.8.2' with respect to project 'ConsoleApps\FeedProvider', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.98 sec
Attempting to resolve dependencies for package 'Microsoft.Data.Edm.5.8.2' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Data.Edm.5.8.2'
Resolved actions to install package 'Microsoft.Data.Edm.5.8.2'
Time Elapsed: 00:00:02.0136869
========== Finished ==========
On Nuget site Edm package does not list any dependencies. When confirmation window shows up it lists dependencies under installing section, which seem to be pulled from Microsoft.Data.Services.Client .NETStandard 1.1 list of dependencies:
I am clearly not using .NETStandard 1.1 for the project in question (nor any other project in this solution), as you can see if you scroll top log to the right with respect to project 'ConsoleApps\FeedProvider', targeting '.NETFramework,Version=v4.6.1'
Does anyone know what's up, or how to get around this problem?
Does anyone know what's up, or how to get around this problem?
Update answer according to the CrnaStena`s comment.
This package should be a problematic package. According to the Dependencies of the package Microsoft.Data.Services.Client:
We can notice that the dependencies Microsoft.Data.Edm has no framework specific. In this condition, NuGet will install the dependencies in the framework .NET Standard, Version=1.1. That why we got that confirmation window shows up the error dependencies.
In order to track this issue, I have create a new issue on GitHub:
NuGet install the wrong dependecies
To resolve this issue, I downloaded this package and add the dependence Microsoft.Data.Edm in to the .net framework 4.0 by NuGet Package Explorer.
Update:
Since there is a new version released:https://www.nuget.org/packages/Microsoft.Data.Services.Client/5.8.3
I have verified it, and it works fine.
Then save this package to the local feed, install the package from local feed.

Updating Pre-release dependencies using nuget

I'm currently develop a set of libraries that progressively add more features.
For example, in my solution, I have a Foo project which defines some basic feature set, an additional project, Foo.Web, for web specific implementations and Foo.Web.Tokens for even more specific features. Foo.Web.Tokens depends on Foo.Web which depends on Foo.
I'm attempting to build separate nuget projects so a user only needs to reference those dependencies they need. I'm versioning the assemblies with GitVersionTask, so after build, they all get the same version number and I'm using the replacement tokens for nuget when building from a project so that the nuget packages all have the same version number.
My problem is that when I try reference a prerelease version of either Foo.Web or Foo.Web.Tokens nuget is unable to resolve the dependency on Foo. If, for example, I have published a 1.1.0.0-alhpa0001 package for each of the assemblies, when I try and update Foo.Web, nuget shows this error:
Install-Package : Unable to resolve dependency 'Foo (≥ 1.1.0.0)'.
Using the -Pre argument doesn't change this. A Foo.1.1.0-alpha0001.nupkg does exist but I feel like nuget won't resolve it because it's not a stable version, and I'm letting nuget automatically detect the dependencies from the solution using the following command:
.\.nuget\NuGet.exe pack source/Foo.Web/Foo.Web.csproj -Build -Version 1.1.0.0-alpha0001 -symbols -IncludeReferencedProjects
How do I properly allow the Foo.Web prerelease package reference the Foo prerelease package of the same version?
The IncludeReferencedProjects option seems to pull the version from the assemblyinfo.cs of the referenced project.
setting the AssemblyInformationalVersion attribute to the desired nuget package version seems to work as you want it to.
eg
[assembly: AssemblyInformationalVersion("1.1.0-alpha0001")]

Installing self-created Nuget package forces use of latest version of a dependency,

I have created a nuget package for a library we use at my company. The library uses both Fluent NHibernate 1.3.0.717 and Structure Map 2.6.2.
Because some folks are using StructureMap 2.6.3, I created the dependencies of the package as:
<dependencies>
<dependency id="FluentNHibernate" version="[1.3,)" />
<dependency id="structuremap" version="[2.6.2,)" />
</dependencies>
And when the package shows up in NuGet it says that Structure Map >=2.6.2 is required. So far, so good.
Here's the issue:
When I go to add this library to my project, it always installs Structure Map 2.6.3. It even uninstalls 2.6.2 from my project in order to do so.
I don't see any sign that structure map 2.6.3 is a dependency of FluentNHibernate (or any of its dependencies) so I am absolutely baffled as to why it will not simply add my library with the FluentNHibernate dependencies and leave my StructureMap 2.6.2 alone.
I don't know if this would have anything to do with it, but we host the packages on a UNC share.
Read David Ebbo's blog series on NuGet Versioning and dependency resolution.
In short, we always pick the dependency with the lowest major and minor and highest build and revision number (based on the dependency's constraints). This is so that you automatically get bugs fixes (non breaking) when using a package as a dependency.