dotnet-deps-cataloger cannot handler aspnet:6.0

[kaiorafael]

What happened:
Error: WARN cataloger failed cataloger=dotnet-deps-cataloger for a generic .Net6 image.

error=unable to determine root package from deps.json file: /usr/share/dotnet/shared/Microsoft.AspNetCore.App/6.0.33/Microsoft.AspNetCore.App.deps.json
error=unable to determine root package from deps.json file: /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.33/Microsoft.NETCore.App.deps.json

What you expected to happen:
I expected a cyclonedx SBOM to be generated.

Steps to reproduce the issue:

• Pulling

docker pull mcr.microsoft.com/dotnet/aspnet:6.0

• Scanning

syft scan mcr.microsoft.com/dotnet/aspnet:6.0 --override-default-catalogers "dotnet-deps-cataloger"

Anything else we need to know?:

Similar to

• .NET NuGet - dotnet-deps cataloger not working with syft v0.94.0 #2264
• Dependency parsing doesn't work on Windows OS for .Net6 #2555

Environment:

• Output of syft version:

 syft --version
syft 1.11.1

• OS (e.g: cat /etc/os-release or similar):

cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[willmurphyscode]

Hi @kaiorafael, thanks for the report.

I think the reason you are seeing no output is that you are telling Syft to use a cataloger that's not best suited to the image.

For example, scanning the image above, a package called Microsoft.AspNetCore is found:

Running:

syft mcr.microsoft.com/dotnet/aspnet:6.0 -o json | jq '.artifacts[] | select(.name == "Microsoft.AspNetCore")'

{
  "id": "891bb1b2ee10abf3",
  "name": "Microsoft.AspNetCore",
  "version": "6.0.3324.37905",
  "type": "dotnet",
  "foundBy": "dotnet-portable-executable-cataloger",
  "locations": [
    {
      "path": "/usr/share/dotnet/shared/Microsoft.AspNetCore.App/6.0.33/Microsoft.AspNetCore.dll",
      "layerID": "sha256:bd5333e4bf0936741b9f114e92eab6cdd48a34f356b2f05e27fb7595b2a4b9bb",
      "accessPath": "/usr/share/dotnet/shared/Microsoft.AspNetCore.App/6.0.33/Microsoft.AspNetCore.dll",
      "annotations": {
        "evidence": "primary"
      }
    }
  ],
  "licenses": [],
  "language": "dotnet",
  "cpes": [
    {
      "cpe": "cpe:2.3:a:Microsoft.AspNetCore:Microsoft.AspNetCore:6.0.3324.37905:*:*:*:*:*:*:*",
      "source": "syft-generated"
    }
  ],
  "purl": "pkg:nuget/Microsoft.AspNetCore@6.0.3324.37905",
  "metadataType": "dotnet-portable-executable-entry",
  "metadata": {
    "assemblyVersion": "6.0.0.0",
    "legalCopyright": "© Microsoft Corporation. All rights reserved.",
    "comments": "Microsoft.AspNetCore",
    "internalName": "Microsoft.AspNetCore.dll",
    "companyName": "Microsoft Corporation",
    "productName": "Microsoft ASP.NET Core",
    "productVersion": "6.0.33+f0f9de5692adf1c0576de062f93c6ab7b176433f"
  }
}

This is found by the dotnet-portable-executable-cataloger, which looks at compiled binaries, not the dotnet-deps-cataloger, which only parses *.deps.json files. Is there a reason you only wanted to see output from the dotnet-deps-cataloger?

[kaiorafael]

Thank you for the feedback.

I was wondering since the path /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.33/Microsoft.NETCore.App.deps.json or /usr/share/dotnet/shared/Microsoft.AspNetCore.App/6.0.33/Microsoft.AspNetCore.App.deps.json contains the dependencies from an application and it is a JSON file as well, I was thinking the dotnet-deps-cataloger would be enough without adding too much cost for reading each binary.

Also, since I have better control on which cataloger I can enable or not, I am interesting in reading only JSON files.

Thanks

[westonsteimel]

@willmurphyscode - additionally, the portable executable cataloger in the past was nearly useless for vulnerability scanning and really needed the additional information from the deps.json file to be useful. See #2637 for the details on that. Although maybe that has been addressed some since I do see that there is at least a package url being raised up by the dotnet-portable-executable-cataloger now? Perhaps some of the relationship work that @wagoodman was doing actually addressed that?

[westonsteimel]

@willmurphyscode - additionally, the portable executable cataloger in the past was nearly useless for vulnerability scanning and really needed the additional information from the deps.json file to be useful. See #2637 for the details on that. Although maybe that has been addressed some since I do see that there is at least a package url being raised up by the dotnet-portable-executable-cataloger now? Perhaps some of the relationship work that @wagoodman was doing actually addressed that?

Eh, nevermind, it still doesn't identify the expected vulns for the false negative reported in grype, so I think it is still the case that the dotnet-portable-executable-cataloger alone is going to be less reliable for vulnerability reporting.

[kzantow]

This seems to be two issues: the main thing is that we aren't parsing the v6 deps.json files properly, as is reported. And this issue in that sense is ready to be worked on, because we should be able to handle those files and are not based on my testing.

Another issue is that we should probably be using any entries we find in a deps.json BEFORE we attempt to parse the same DLLs with the PE parser and get less accurate results. This sounds like adding functionality to the PE parser to ALSO run the deps.json parsing on the file set before scanning any binaries and skipping the ones that we already found versions for. A new issue is opened for this secondary concern: #3570