Syft generates incorrect CPEs which leads to issue when scanning for vulnerabilities

[wenoukiz]

What happened:

I am testing Syft and Grype together to see if it could be a good software scanning tool chain. I generated a fake and incomplete CycloneDX SBOM with Syft in which I purposely put packages with known vulnerabilities to see if Grype would pick them up. This is the SBOM :

{
  "$schema": "http://cyclonedx.org/schema/bom-1.4.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:4394449d-0e02-454a-91f4-becdea229a1f",
  "version": 1,
  "metadata": {
    "timestamp": "2023-11-02T09:46:40+01:00",
    "tools": [
      {
        "vendor": "anchore",
        "name": "syft",
        "version": "0.94.0"
      }
    ],
    "component": {
      "bom-ref": "af63bd4c8601b7f1",
      "type": "file",
      "name": "."
    }
  },
  "components": [
    {
      "bom-ref": "pkg:conan/ffmpeg@4.2.8?package-id=740a866f696987ae",
      "type": "library",
      "name": "ffmpeg",
      "version": "4.2.8",
      "cpe": "cpe:2.3:a:ffmpeg:ffmpeg:4.2.8:*:*:*:*:*:*:*",
      "purl": "pkg:conan/ffmpeg@4.2.8",
      "properties": [
        {
          "name": "syft:package:foundBy",
          "value": "conan-cataloger"
        },
        {
          "name": "syft:package:language",
          "value": "c++"
        },
        {
          "name": "syft:package:metadataType",
          "value": "ConanMetadataType"
        },
        {
          "name": "syft:package:type",
          "value": "conan"
        },
        {
          "name": "syft:location:0:path",
          "value": "/conanfile.txt"
        }
      ]
    },
    {
      "bom-ref": "pkg:conan/glibc@2.30?package-id=76a789fd74c696fc",
      "type": "library",
      "name": "glibc",
      "version": "2.30",
      "cpe": "cpe:2.3:a:glibc:glibc:2.30:*:*:*:*:*:*:*",
      "purl": "pkg:conan/glibc@2.30",
      "properties": [
        {
          "name": "syft:package:foundBy",
          "value": "conan-cataloger"
        },
        {
          "name": "syft:package:language",
          "value": "c++"
        },
        {
          "name": "syft:package:metadataType",
          "value": "ConanMetadataType"
        },
        {
          "name": "syft:package:type",
          "value": "conan"
        },
        {
          "name": "syft:location:0:path",
          "value": "/conanfile.txt"
        }
      ]
    },
    {
      "bom-ref": "pkg:conan/libxml2@2.9.9?package-id=d7ddfedafaf62d61",
      "type": "library",
      "name": "libxml2",
      "version": "2.9.9",
      "cpe": "cpe:2.3:a:libxml2:libxml2:2.9.9:*:*:*:*:*:*:*",
      "purl": "pkg:conan/libxml2@2.9.9",
      "properties": [
        {
          "name": "syft:package:foundBy",
          "value": "conan-cataloger"
        },
        {
          "name": "syft:package:language",
          "value": "c++"
        },
        {
          "name": "syft:package:metadataType",
          "value": "ConanMetadataType"
        },
        {
          "name": "syft:package:type",
          "value": "conan"
        },
        {
          "name": "syft:location:0:path",
          "value": "/conanfile.txt"
        }
      ]
    }
  ]
}

As you can see, the three packages in this SBOM are ffmpeg 4.2.8, glibc 2.30 and libxml2 2.9.9. But there is the issue : the generated cpes are incorrect. When scanning this SBOM with Grype, it would only output ffmpeg vulnerabilities but not the others. With some research I found that this is probably because the cpes for the two other packages are wrong.

• cpe:2.3:a:libxml2:libxml2:2.9.9:*:*:*:*:*:*:* should be cpe:2.3:a:xmlsoft:libxml2:2.9.9:*:*:*:*:*:*:*
• cpe:2.3:a:glibc:glibc:2.30:*:*:*:*:*:*:* should be cpe:2.3:a:gnu:glibc:2.30:*:*:*:*:*:*:*

It seems that Syft assumes that the package vendor is the same as the package name which is not always the case

What you expected to happen:

I imagine this issue happening on much more than those two packages, which is a big problem when trying to scan a SBOM for vulnerabilities later on. Syft could use a fix for that

Steps to reproduce the issue:

Just by generating a SBOM with Syft there is a probability that there is one or more incorrect cpes. On very large SBOMs you wouldn't even notice unless you would check them one by one

Environment:

• Syft version 0.94.0
• OS Ubuntu 22.04.3 LTS

[tgerla]

Hi @wenoukiz, we know that CPE generation/guessing can be inaccurate, and we generate them in such a way to reduce false negatives at the expense of more false positives. You can read more about some of our decisions around CPE generation and matching here: https://anchore.com/blog/say-goodbye-to-false-positives/

That being said, I am a bit confused--the example you pasted, this is the output of Syft, right? What did you scan with Syft to generate this SBOM? I understand you're "faking" but I'm confused as to where the faking starts. Thanks!

[wenoukiz]

Hi @tgerla, thank you for your response. Firstly, to answer your question, yes this SBOM is the output of Syft. I made a "fake" conanfile.txt because that's the environment I'm interested in. In this file, I manually entered the following content :

[requires]
glibc/2.30
ffmpeg/4.2.8
libxml2/2.9.9

Then Syft generated the SBOM you saw above.

Now about the blog post you mentionned, it seems it's rather about CPE matching in Grype than CPE generating in Syft. I understand the decision of not using CPE matching to reduce false negatives but what I didn't understand is what is used to replace that ? How does the matching work ? Other than that, I'm more curious about how Syft generates CPEs and if there is any kind of verification performed to check if it's valid. Also, by modifying the SBOM above with the correct CPEs and feeding it to Grype again, it returned all the vulnerabilities I expected. So, does Grype still rely on CPE matching in a few cases ?

[wagoodman]

I'm pretty certain there isn't any information about package dependencies from a conanfile.txt (as you mentioned), there might be good data for this for each package in the conan registry (I haven't verified this) in which case this might be a good candidate for the use-network / online features that we're exploring (#1115).

A short-term workaround would be to add exceptions to https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/common/cpe/candidate_by_package_type.go while we find a better place to source this information from.

[wenoukiz]

You are right, a conanfile does not provide information about package dependencies. Unfortunately, the Conan registry is missing a lot of packages and versions which doesn't make it a good option for now I think.

Looking on the link you sent, I find this could be a solution in the meantime. I understand this is some kind of manual matching between a package name and a vendor but is it active by default in Syft ? Because as you can see above, the generated CPE for glibc is incorrect although the correct vendor for glibc figures in this code

[wagoodman]

CPE generation logic is always provided in syft. In grype conan packages are matched with the stock matcher (there is no custom matcher used) which means that it should search by CPE by default for those packages.