MSBuild analyzer could (should?) check for props files as well

[GeertvanHorrik]

Is your feature request related to a problem? Please describe.

With the new msbuild stuff (core sdk project style), dependencies can also be put into .props and .targets files in the root of the solution.

Describe the solution you'd like

Please also scan the following files:

• .props
• .targets (e.g. Directory.build.targets)

I hope it's as easy as adding the extensions to this line:

https://github.com/jeremylong/DependencyCheck/blob/master/core/src/main/java/org/owasp/dependencycheck/analyzer/MSBuildProjectAnalyzer.java#L75

Describe alternatives you've considered

Additional context

Let me know if you need more info.

[dsmailys]

Any news on this? We get incorrect scan results due to versions being specified within the .targets file instead of the .csproj

[jeremylong]

Can you provide an example project?

[GSDragoon]

I'm running into the same issue. The scan isn't picking up dependency packages specified in the Directory.Build.props file. Microsoft has them documented here.

[bcowdery]

We see this as well in our repo using an external props file to define nuget versions. We have a large collection of shared libraries and use properties files to control shared dependencies (Microsoft themselves use the same technique in the dotnet runtime repo).

As a simple example, add a Directory.Build.Props file to the root of your repo with named properties, then use the property values in the csproj PackageReference tags.

Directory.Build.Props

<Project>

  <PropertyGroup>    
    <Product>Shared Packages</Product>
    <Copyright>Copyright © 2020</Copyright>
   </PropertyGroup>

  <PropertyGroup Label="nuget dependency versions">
     <NodaTimeVersion>3.0.0</NodaTimeVersion>
     <EntityFrameworkCoreVersion>5.0.0</EntityFrameworkCoreVersion>
  </PropertyGroup>

</Project>

Library.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="NodaTime" Version="$(NodaTimeVersion)" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="$(EntityFrameworkCoreVersion)" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="$(EntityFrameworkCoreVersion)" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="$(EntityFrameworkCoreVersion)">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

</Project>

Ideally the OWASP dependency check should be looking at the resolved version numbers, not parsing the XML from the csproj files,

[h3ko]

Will be this ever implemented?

[arvped]

Ran into a similar problem when trying to add Dependency Check to our build pipeline.

Our solution uses nuGets Central Package Management, as described here: https://devblogs.microsoft.com/nuget/introducing-central-package-management/

All packages with version numbers are collected in one Directory.Packages.props file. Only package names (but no package version numbers) in the .csproj files.

Example:

Directory.Packages.props:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="System.Security.Cryptography.Xml" Version="6.0.0" />
  </ItemGroup>
</Project>

xyz.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>
  
  <ItemGroup>
    <PackageReference Include="System.Security.Cryptography.Xml" />
  </ItemGroup>
    
</Project>

Would greatly appreciate this being implemented!

[emboss64]

Another vote over here
We had implemented the use of dependency-check within our pipelines but we recently bumped into a solution which uses cpm to manage dependencies. So right now we are either going for another tool that supports cpm or at least "translating" the Directory.Packages.props into either a valid csproj or json that dependency-check would be able to analyze