bug: libraries ignored by cve-bin-tool ?

[Virthuss]

Hi. There seems to be some libraries being ignored by cve-bin-tool at the moment. An example with the following sbom file:

    {
      "components":
      [
        {
          "type": "library",
          "name": "bzip2-rs",
          "version": "0.3.3"
        },
        {
          "type": "library",
          "name": "openzeppelin-contracts",
          "version": "4.3.0"
        },
        {
          "type": "library",
          "name": "openzeppelin-contracts",
          "version": "4.8.0"
        },
        {
          "type": "library",
          "name": "openzeppelin-contracts",
          "version": "4.8.1"
        },
        {
          "type": "library",
          "name": "openzeppelin-contracts",
          "version": "4.8.2"
        }
      ]
    }

Running cve-bin-tool --nvd json --sbom cyclonedx --sbom-file sbom.json --affected-versions --format console will simply ignore these two libraries:

╭─────────────╮
│ CVE SUMMARY │
╰─────────────╯
┏━━━━━━━━━━┳━━━━━━━┓
┃ Severity ┃ Count ┃
┡━━━━━━━━━━╇━━━━━━━┩
│ CRITICAL │ 0     │
│ HIGH     │ 0     │
│ MEDIUM   │ 0     │
│ LOW      │ 0     │
│ UNKNOWN  │ 0     │
└──────────┴───────┘
╭───────────────────────────────────────────────╮
│  Products with No Identified Vulnerabilities  │
╰───────────────────────────────────────────────╯
┏━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┓
┃ Vendor ┃ Product ┃ Version ┃
┡━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━┩
└────────┴─────────┴─────────┘

The problem is that one of these two actually has CVEs: https://nvd.nist.gov/vuln/detail/CVE-2023-26488

With most of other libraries cve-bin-tool works well. So is there a bug with the syntax or the detection of some libraries?

Thanks on advance.

[ffontaine]

The issue is that openzeppelin-contracts doesn't match any fields in the NVD NIST database. Indeed the CVE-2023-26488 is affected to the contracts package provided by the openzeppelin vendor.

Concerning bzip2-rs, again this doesn't match any product in the NVD NIST database. It should be replaced by bzip2.

The following sbom should give the expected results:

    {
      "components":
      [
        {
          "type": "library",
          "name": "bzip2",
          "version": "0.3.3"
        },
        {
          "type": "library",
          "name": "contracts",
          "version": "4.3.0"
        },
        {
          "type": "library",
          "name": "contracts",
          "version": "4.8.0"
        },
        {
          "type": "library",
          "name": "contracts",
          "version": "4.8.1"
        },
        {
          "type": "library",
          "name": "contracts",
          "version": "4.8.2"
        }
      ]
    }

This current behavior could be improved and there is already several open issues such as https://github.com/intel/cve-bin-tool/issues/2685.

I'll let @terriko provides additional feedback if needed.

[terriko]

As @ffontaine says, the problem is that the names don't match the lookups in the database. We're currently working on some ways to find and map common names and gather extra metadata in #2633, but it's still in the early stages of figuring out what data to use. If you generated your sbom from a tool, do you mind sharing which one so we can maybe investigate ways to do better for it in the future?

[Virthuss]

@terriko Currently we basically fetch information from the API provided by Github ( https://docs.github.com/en/rest?apiVersion=2022-11-28 ) from the Github repo link provided by the user. If the repo exists, we pull the component name from the link to populate the SBOM field. We also check that the name is correct. So basically, it heavily relies on the link provided by the user at the moment. In the case of open-zeppelin, our use used the name from the Github repo link provided in the CVE link, hence the openzeppelin-contracts instead of just contracts ( which is a bit confusing... if we just use contracts, how to make sure we are not actually looking for another repo using that name ? ).

I thought about this problem earlier but if we use a library that is a fork from another one having CVEs, it means cve-bin-tool won't detect it right ?

[Virthuss]

@ffontaine Are you aware of any potential ways to fetch the product name used in the CPE from the Github API? To go back to https://nvd.nist.gov/vuln/detail/CVE-2023-26488#range-9009681, Github basically uses openzeppelin_contracts as a name while on NVD it's contracts and contracts_upgradeable. Hence the issue.

Our current system heavily relies on information provided by Github so it would be truly helpful if Github provided a product name matching the CPE's ones.

[ffontaine]

No I'm not aware to retrieve the product name used in the CPE from github but product naming is a difficult issue. Indeed, there is no synchronization between upstream (github, gitlab, etc.), NVD NIST and distribution (debian, alpine, openWRT, etc.)

You could suggest upstream to rename their repo from https://github.com/OpenZeppelin/openzeppelin-contracts to https://github.com/OpenZeppelin/contracts as OpenZeppelin is duplicated. However, they will probably reject it. It would also be nice to be able to give a vendor in the SBOM file in cve-bin-tool.

[Virthuss]

I see. Hopefully this issue will be dealt with and we will have some standardization in the future. For now we will have to deal with the possibility of not finding a repo in some rare cases.

[terriko]

I thought about this problem earlier but if we use a library that is a fork from another one having CVEs, it means cve-bin-tool won't detect it right ?

With an SBOM we currently assume you've done whatever's needed to clean it up and make sure it's correct, so if you tell us something has a different name then we trust that you got it right and it's a different product.

With a binary file that's a bit more nebulous depending on the strings in the file. It depends largely on whether you changed the strings we use as a signature. So a fork with a few patches is pretty likely to still be detected, but a fork where someone changed the whole product name might not (and honestly, it shouldn't be, because after that point it's entirely possible that each one will have different CVEs. The norm at this point is that they're two "products" in the database but a single CVE might affect both.)

I do hope that github will one day allow teams to associate their CPE ids with their repos to facilitate lookup. We're already seeing this as possible in some other packaging ecosystems. In the meantime, I expect we'll be crowdsourcing giant lookup tables to make things work better. 🤷 We've got some discussion of how to associate metadata for repos in #2633 and I think github urls will likely be one of the things we allow as indices for lookup, but I'm not sure what the solution will look like yet since it depends on who applies to work on that project.

[terriko]

Shorter term: we've been talking about annotating sboms directly -- I wonder if we also need some sort of annotation-triage option so you could save your own list of stuff like "when github said openzepplin-contracts, look up {openzepplin, contracts}" (or contracts_upgradeable, or both. whatever is actually correct behaviour.). I don't think VEX is really designed with that kind of triage in mind but maybe we could extend it. @anthonyharrison have you seen any standards on disambiguation-type triage? This might be something we should just design for our own use if no one's started on it yet. I know Anthony and I have talked about the gaps in SBOM management and quality control tools already...

[anthonyharrison]

@Virthuss It looks like the sbom is rather minimal with the level of detail provided (how was it produced?). I would expect either CPE or PURL references to be added as this would also provide additional information to help with the identification of the component. The minimum el;ements needed for a component include the supplier, component name, version and other information (e.g. CPE or PURL are examples). CPE ids are often inconsistent which is why alternative approaches are being considered to try and result in consistent naming.

CVE-BIN-TOOL looks for matches against the CPE product and supplier names. It isn't perfect but we are always looking at improving this e.g. #2685 but we can only work with the metadata which is available. The introduction of SBOMs should heopefully result in improved data quality but thjis will clearly take time.

[terriko]

This has been really useful discussion. Thinking about what we can do going forwards:

Some documentation/tutorial stuff we could probably provide:

1. Update the docs for SBOM scanning to make sure that users understand that we're currently expecting an exact match in NVD or it just won't work.
2. Add instructions to the doc for how to annotate records so that they can be scanned. I think that's "how to look up your components in NVD manually and change the name field" for a first pass
3. @anthonyharrison should we also be recommending people manually add a CPE or PURL entry and use that as the next step?

I think 1 and 2 can be done right now, I'm not sure what the right path/expectation for CPE/PURL entries should be.

Code changes:

1. Continue the work on metadata, multiple names, de-duplication we already have in progress
2. Make the sbom scans generate more output when an item isn't found, pointing at the documentation. a. e.g. "This component was not found in NVD with the productname $foo. If you were expecting it to be found see $link on how to annotate your SBOM to look up the correct product name"
3. Improve our guesswork algorithms based on the metadata, etc. found in step 1.

If those sound reasonable, I'll start filing separate issues.

[anthonyharrison]

@Terri Oda @.***> There is already an issue (currently allocated as a potential GSOC project) project to add support for PURL and CPEs within a SBOM. Adding support for PURLs will be a big step forward at matching product names if and when NVD or other sources start supporting them.

Adding CPE or PURL references manually to an SBOM at this stage won't help cve-bin-tool until we have the GSOC project implemented.

On Wed, 29 Mar 2023, 19:58 Terri Oda, @.***> wrote:

This has been really useful discussion. Thinking about what we can do going forwards:

Some documentation/tutorial stuff we could probably provide:

1. Update the docs for SBOM scanning to make sure that users understand that we're currently expecting an exact match in NVD or it just won't work.
2. Add instructions to the doc for how to annotate records so that they can be scanned. I think that's "how to look up your components in NVD manually and change the name field" for a first pass
3. @anthonyharrison https://github.com/anthonyharrison should we also be recommending people manually add a CPE or PURL entry and use that as the next step?

I think 1 and 2 can be done right now, I'm not sure what the right path/expectation for CPE/PURL entries should be.

Code changes:

1. Continue the work on metadata, multiple names, de-duplication we already have in progress
2. Make the sbom scans generate more output when an item isn't found, pointing at the documentation. a. e.g. "This component was not found in NVD with the productname $foo. If you were expecting it to be found see $link on how to annotate your SBOM to look up the correct product name"
3. Improve our guesswork algorithms based on the metadata, etc. found in step 1.

If those sound reasonable, I'll start filing separate issues.

— Reply to this email directly, view it on GitHub https://github.com/intel/cve-bin-tool/issues/2846#issuecomment-1489138801, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAID27SFOOBTDRNDNFS43LW6SA4HANCNFSM6AAAAAAWFBKA7E . You are receiving this because you were mentioned.Message ID: @.***>