-
-
Notifications
You must be signed in to change notification settings - Fork 590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SBOMs from Ubuntu with purls seam not to work with Google OSV #4445
Comments
The correct link (I assume) is: google/osv.dev#2842 :-) |
I updated to Version 4.12.2 but still the same |
While looking for a solution i found #1374. Also this problem is caused by a insuffient regex in version parsing. While fixing this bug i developed a theory about how to parse versions, including semantic versioning 2.0.0 and debian versions in general (also see in the issue). My plan is to develop an enhanced parsing algorithm based on the current one. For testing I thought about picking random version pairs (because there are so many) from a list of all ubuntu version numbers (they are a superset of debian version numbers and are ~130000 single entries so ~8.5 billion possible pairs), compare each with the enhanced algorithm and dpkg --compare-versions and check if the verdict is in all tested cases the same. From the most representative samples i want to create unittests. Same i want to do with semantic version pairs (but from what list?) and with a "offical" (which one?) comparing tool. Further it would be great if this could be done also with version numbers from other ecosystems on Google OSV. But also here would be the question from which version lists and with what offical comparision tool. |
Hi @ALL, It works in following steps:
which equivalent to ~ < # = "" < \d+ < [a-z]+ < + < - < . < :, and what the debian version algorithm does: https://salsa.debian.org/dpkg-team/dpkg/-/blob/main/scripts/Dpkg/Version.pm?ref_type=heads#L351
3.Compare one-by-one: First check priority, then check value. if value is a numeric add leading zeros that both strings got same length. Stop on first difference:
|
The algorithm it tested with the mentioned testdata set with 130000 version pairs and i discovered some corner cases which are not covered by other implementations:
To circumvent these problems i did the design as followed:
|
In the next days i will create an fork and add my algorithm. For who's interessted, the algorithm so far:
|
👋 We're very much enjoying DT. Thanks for your efforts in building such a great tool! We're also experiencing issues with identifying vulnerabilities against Ubuntu packages and it'd be great to see this issue addressed as it'd allow us to move entirely to DT to provide vulnerability detection. Tangentially, during our investigations that have lead us to this issue, we've identified an upstream issue here relating to invalid PURLs being published to OSV from Canonical. These look like they'll be addressed quickly. |
@nickrmc83 I think this effort could be greatly accelerated by assisting @Andre-85 in reviewing and testing their implementation against realistic datasets. Waiting for me to have capacity to do so will delay this, I fear. @Andre-85 Once you have something you're comfortable with sharing, we could ask others in the community (i.e. via Slack) to help here. We could publish container images to Docker Hub to make it easier for folks to kick the tires. Let me know if I can help facilitate anything. |
I'm happy to provide some test cases and real-world data that can be used to verify @Andre-85's changes. It's unlikely I'll be able to commit to thoroughly testing a new version outside of a quick validation for at least a couple of months. |
Hi @ALL, @nickrmc83 What kind of test data can you provide and for which ecosystem? Right now my testdata are random version numbers picked from a file (one per line in a file ubuntu_versions.txt). With these random version numbers I run the algorithm (right now its not in the unittest format of course) and compare it with the official tool.
But a testset with a file with version1 RELATION version2 per line would also be ok. |
@Andre-85 the relatively simple test data I can provide would be a real-world SBOM and associated PURLs and a list of CVEs we'd expect to see. This may allow for confirmation for end-to-end functionality as opposed to your Debian and Ubuntu version parsing logic. |
@nickrmc83 This would great if you could send this testdata to me. Even more interesting it would be to have testdata which is for other Ecosystems than Debian or Ubuntu. The issue you filed (canonical/ubuntu-security-notices#4) affects also DependencyTrack abilities i guess? |
I can share an SBOM for Debian and Ubuntu only. Whilst the SBOMs I'll share are non-sensitive and will have any redactions made, I'd prefer to DM them to you. You can compare the SBOMs I provide against findings identified by other tools using the same input. We've been using I'm not sure how impacted dependency-track is by the Canonical issue, I didn't dive in deep on the impact, but I imagine if DT depends on qualifiers from OSV-published PURLs, there's a chance it would include either false-positive or false-negatives as a result. |
Hi @ALL, So running a test on the implementation requires now only picking a version from the list, pick a second one more down in the list and compare them (https://github.com/Andre-85/dependency-track/blob/feature/improved-version-compare/src/test/java/org/dependencytrack/util/ComponentVersionTest.java). The result needs to be always <0. For the ones interested how i did the bubble sort:
|
@nickrmc83 It would be interesting to convert the SBOM entries and the CVE entries to expect in a unittest (https://github.com/Andre-85/dependency-track/blob/feature/improved-version-compare/src/test/java/org/dependencytrack/util/ComponentVersionTest.java). Then just a run of mvn test -Dtest=ComponentVersionTest should be suffient to see if your SBOM purl versions will be processed correctly. DM the SBOM to me is ok. But howto do it github without posting my email address here in public? You said you were using grype before. What was your reason to switch to DependencyTrack? And how to grype compare to here? |
Current Behavior
Hello together,
I've noticed that in DependencyTrack in version 4.12.1 supports fetching vulnerabilities from Google's OSV service. So wanted to test DependencyTrack with an SBOM containing PURLs i can also use for CVE-fetching via Google API. As example i choose the ubuntu package atftp in version 0.7.git20120829-3.1~0.18.04.1 which has the known CVE'S CVE-2020-6097, CVE-2021-46671 and CVE-2021-41054. But DependencyTrack reports no issues at all.
Since i was a bit unsure about the supported debian/ubuntu PURL format, i made different variants containing arch and/or distro and completely without arch/distro:
purl_test_name_version.json
purl_test_name_version_arch_armhf.json
purl_test_name_version_arch_armhf_distro_bionic.json
purl_test_name_version_arch_src.json
purl_test_name_version_arch_src_distro_bionic.json
purl_test_name_version_distro_bionic.json
Steps to Reproduce
Upload the SBOMs which i uploaded to this ticket and you will find no vulnerabilities.
Expected Behavior
Just last week Google closed issue #2842 (reported by me) on OSV services and made CVE-fetching via purl possible.
So right now it is possible to fetch the CVE's (CVE-2020-6097, CVE-2021-46671 and CVE-2021-41054) belonging to atftp for the given version from Google OSV with:
curl -d '{"package": {"purl": "pkg:deb/ubuntu/[email protected]~0.18.04.1"}}' https://api.osv.dev/v1/query
I would be great if DependencyTrack could fetch the CVE's with a SBOM with this PURL in it.
Let me know how I can help to figure this problem out.
Dependency-Track Version
4.12.1
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
No response
Browser
Mozilla Firefox
Checklist
The text was updated successfully, but these errors were encountered: