bug: sbom scan can't detect two versions of the same package

[kzaitsu]

First, I scanned a particular json file using the command below. This json file contains two versions of openssl (1.0.2u, 1.1.1f). "cve-bin-tool --sbom spdx --sbom-file <directory/file.json> -f csv -o cve-bin-tool_sbomscan-squashfs-root-0_2" The resulting csv file did not include openssl version 1.1.1f, only 1.0.2u. Next, delete version 1.0.2u of openssl in the json file you used earlier and run the same command again, and this time version 1.1.1f, which was not displayed earlier, is now displayed in the csv file. (1.0.2u was not displayed) I don't know why the above phenomenon occurs, so could you please explain to me?

[terriko]

Sounds like a bug to me; it should display both.

[mastersans]

I'll look into this one.

[kzaitsu]

We would like to add some points that were not fully explained. The json file containing the two versions of openssl was obtained with the following command. "cve-bin-tool --offline -l debug --sbom-format json --sbom-output <directory/file.json> --detailed --report " I used the previously reported command on the json file created by this command and confirmed that the output is strange.

[mastersans]

@kzaitsu @terriko I investigated on it and turns out this is a bug in lib4sbom library we use for our sbom operation, I investigate there too the exact thing that is causing this behaviour is this: https://github.com/anthonyharrison/lib4sbom/blob/0dae9bbba17bba8149706ec7daafb3c0e4322623/lib4sbom/spdx/spdx_parser.py#L433 here the if statement is checking weather package already exists in the packages dictionary if not then only its added, since the openssl is already present in the packages it wasn't adding second one, its not a problem with some particular version whichever version in first in the file is added and the onces after that are not added thats why its not appearing in the output. here is the data that i got from a neat little print statement placed in the lib4sbom of the packages dictionary:

{
    "openssl": {
        "name": "openssl",
        "type": "LIBRARY",
        "version": "1.1.1f",
        "id": "openssl_1.1.1f",
        "supplier_type": "Organization",
        "supplier": "OpenSSL",
        "originator_type": "Organization",
        "originator": "OpenSSL",
        "homepage": "http://www.openssl.org/",
        "licenseconcluded": "LicenseRef-OpenSSL",
        "licensedeclared": "LicenseRef-OpenSSL",
        "downloadlocation": "http://www.openssl.org/source/",
        "description": "OpenSSL library version 1.1.1f",
    }
}

I'll file a issue there regarding this , btw i also checked same scernario with the cyclonedx format but its not a problem with that. but i think i am going to ping @anthonyharrison since he is the author of lib4sbom regarding this and ask can i work on it.

[anthonyharrison]

@mastersans @terriko it is a bug but appears to be limited to SPDX SBOMs in JSON format only.

[mastersans]

@mastersans @terriko it is a bug but appears to be limited to SPDX SBOMs in JSON format only.

Yes, but it may have been present in the yaml too since json and yaml both uses same _parse_spdx_data() function but should be fixed now too.

[mastersans]

@terriko @kzaitsu this issue has been addressed in PR : #34 and can be closed as complete.

[terriko]

We should probably wait to close this until @anthonyharrison gets a new release out and we bump our minimum version of lib4sbom up, just so we don't forget to do that. But thank you, I'm glad there's a fix!

[kzaitsu]

@terriko @mastersans @anthonyharrison Sorry, I am late in replying. Thank you for answering my questions. If I have any more questions, I will ask them again. Thank you in advance.

[alext-w]

I see the same problem when using CycloneDX output format as well, so it's either not limited to SPDX only as investigated previously, or that may be a format parser bug, I guess.

Particularly, I'm scanning a Linux ELF file, which is compiled with one GCC version, but has other linked pieces, compiled by an older one. cve-bin-tool seems to detect only one, but not the other.

Specifically, here's what strings returns:

$ strings src/obj-intel64/CECTraceTool.so |grep GNU
GCC: (GNU) 11.2.0
GCC: (GNU) 13.2.1 20240316 (Red Hat 13.2.1-7)

...and 11.2.0 is the only one shown by cve-bin-tool, both in the CVE list (that version happens to have a disputed CVE), and the SBOM.

This issue's name formally covers this case too (two versions, only one detected), but let me know if you want me to submit a separate one for this.

[mastersans]

@terriko the minimun version of lib4sbom can be now bumped to 0.7.1 new version by @anthonyharrison was released last month, but i haven't tracked the recent bug report here.

[anthonyharrison]

@alext-w The issue with two GCC versions not been detected in the binary is a cve-bin-tool issue and not a lib4sbom library problem. I think a separate issue for this problem would be worthwhile. If you create a small test file which exhibits the problem, that would be appreciated so that it can be added to the test suite.

Note that the generated SBOM will only take the components which are found by the cve-bin-tool. If only one version is found, the SBOM will only report this version.

cc @terriko @mastersans

[alext-w]

Sure, thank you. Let me come up with a reproducer in the next few days and put it into a separate issue.

[alext-w]

Reported separately as #4184.

[terriko]

This should be good since the latest update of lib4sbom, closing now