Issues with importing multiple sboms

[prabhu]

TIL that multiple BOM files could be zipped and imported to a single product. This is cool! So I created a zip file for the dotnet-podcasts dataset and imported.

sboms.zip

1. Components count is less than what I anticipated. Is it possible that dejacode filters out components without a version number and so on?
2. Vulnerabilities count is significantly less than anticipated. Is it due to a lack of OS vulnerabilities in my dejacode setup?

Below is the report from depscan.

depscan.pdf

Thanks in advance!

[tdruez]

1. Components count is less than what I anticipated. Is it possible that dejacode filters out components without a version number and so on?

Short answer: DejaCode does not filter out anything but it does not create duplicated package entries. If a package with the same exact PURL appears many times in the provided SBOMS, it will exist only as a single package record in DejaCode.

Looking into the content of those SBOMS:

• sbom-build-dotnet.cdx.json: 274 components
• sbom-container-dotnet1.cdx.json: 454 components
• sbom-container-dotnet2.cdx.json: 454 components
• sbom-container-dotnet3.cdx.json: 454 components
• sbom-container-dotnet4.cdx.json: 454 components
• sbom-container-dotnet5.cdx.json: 454 components
• sbom-postbuild-dotnet.cdx.json: 324 components
• sbom-prebuild-dotnet.cdx.json: 274 components

A quick look into sbom-container-dotnet1.cdx.json, sbom-container-dotnet2.cdx.json, etc... shows that the component list is identical.

Adding the unique list counts we should expect 1,052 packages to be imported on the DejaCode side: 274 + 454 + 324

We can confirm this looking at the underlying load_sbom pipeline run in the SCIO instance, we can see that 3,142 packages where created, including a lot of duplicates.

>>> from scanpipe.models import Project
>>> project = Project.objects.get(name="5df8cbdf-f5a4-42b4-9413-d1707a35ba00")
>>> project.discoveredpackages.count()
3142
>>> len(set(package.purl for package in project.discoveredpackages.all()))
1052

Only 1,052 PURLs are unique across the SBOMS.

---

I've run the import using the provided sboms.zip and I end up with the expected 1,052 packages in my product:

@prabhu Could you provide the log content in the "Imports" tab? It should look like this:

- Imported 1042 packages.
- 2100 packages skipped: already available in the dataspace.
- 320 dependencies skipped: already defined on the product.

[prabhu]

@tdruez thank you so much for your help. The contents of the import tab.

Import type	Status	Input	Log
Import SBOM
1 day ago by appthreat
Completed
File: sboms.zip	- File submitted to ScanCode.io for inspection
- Imported 750 packages.
- Imported 320 dependencies.
- 2392 packages already available in the Dataspace.

[prabhu]

Wanted to clarify the semantics regarding duplicate components. The BOMs represent different lifecycles and container vs software SBOMs. They will vary in properties, evidences, and other attributes. The new version of depscan can track them all without filtering out merely based on purl or bom-ref.

We built a library to understand the semantic differences. It would be super cool if you could use it or provide feedback.

[tdruez]

2. Vulnerabilities count is significantly less than anticipated. Is it due to a lack of OS vulnerabilities in my dejacode setup?

@prabhu could you clarify what you mean by "a lack of OS vulnerabilities in my dejacode setup"? The vulnerability data are pulled from VulnerableCode.

[prabhu]

Getting just 3 debian CVEs. Expecting many more.

[pombredanne]

@prabhu Hey! Nice you to see the depscan author there! ❤️

We checked your pdf above and I am looking at one of the line. If I read this correctly, "coreutils@8.32-4" is vulnerable to "CVE-2024-0684"

Now if we dig deeper, this is the Debian tracker entry for this CVE:
https://security-tracker.debian.org/tracker/CVE-2024-0684

For bulleye, (e.g., coreutils@8.32-4 ) we have:
[bullseye] - coreutils <not-affected> (Vulnerable code not present)

This is further confirmed by looking at which version has the vulnerable code based on the introducing and fixed commits:

• Fixing commit in 9.5 and up at coreutils/coreutils@c4c5ed8
• Introducing commit in 9.2 at coreutils/coreutils@40bf159

So I feel that reporting that coreutils@8.32-4 is vulnerable to this CVE may not be correct?

We could dig further, and I am sure there are cases where vulnerablecode is not correct too. All in all, this means we should work together to get better quality data for vulnerabilities!

[prabhu]

depscan results indeed has too many false positives for this project. Let me work on the obvious issues a bit more before revisiting this discussion.

[prabhu]

Second attempt:

I have removed a number of false positives (actually moved them behind a --fuzzy-search flag) and improved the fix version detection. Getting 66 vulnerabilities now.

https://huggingface.co/datasets/AppThreat/ukaina/tree/main/dotnet/dotnet-podcasts
depscan.txt

[prabhu]

CVE-2022-3715 and CVE-2021-33560 are ignored by depscan in the new mode since they have no-dsa comment.

Any ideas why vulnerable code is flagging only 3 debian packages, even though this image is quite old so must have many more CVEs?

[pombredanne]

Any ideas why vulnerable code is flagging only 3 debian packages, even though this image is quite old so must have many more CVEs?

What about starting instead by defining what is the true packages inventory on a well defined input and thoroughly cross validate that?

[prabhu]

Any pointers to defining this ground truth?