Replies: 7 comments
-
|
Should say that both are running 4.13.6 of DT so not quite the latest. |
Beta Was this translation helpful? Give feedback.
-
|
Hi it took about 10 hours for all 45 of the OSVs to sync. Seems a little excessive. Any known reason as to why it takes so long and there such time gaps between one and the next? Some are together, but then a big gap. |
Beta Was this translation helpful? Give feedback.
-
|
It does seem a little flakey as on another new system I have set up 18 hours ago, none of them have downloaded. :-( |
Beta Was this translation helpful? Give feedback.
-
|
Likely related to #5934. |
Beta Was this translation helpful? Give feedback.
-
|
Yup the last one all my systems did this morning was Ubuntu. Since then the have been doing other things. The main one I was interesting did eventually finish, but they took a long long time, |
Beta Was this translation helpful? Give feedback.
-
|
Hi I've been tracking it and this is what I am seeing for one of the servers You can see there is an 8 hour gap between the Ubuntu one and the Bitnami, There is a 13 hour gap on one of the other systems and a 7 hour gap on the last one. Power of the last two should have been identical and first should have been the most powerful. |
Beta Was this translation helpful? Give feedback.
-
|
So I have been running a test over the weekend on three systems to see how the syncing fares. SLS Server DD Server New DT Server As you can see the Ubuntu bug is having a significant impact on the Sync time and in some cases it not syncing within the 24 hour period. This does mean that I am getting slightly different results in the 3 servers which is a real pain. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Since the Sonatype fun, we are thinking of moving to using the internal analyser with NVD and OSV data sources.
The two servers I have are giving vastly different results for the same SBOM even though they appear to have identical set ups.
One is showing ~900 vulnerabilities and the other ~500
I started looking at the logs and the larger number has a vulnerability index of 4.1m vulnerabilities and the other 2.8m vulnerabilities. I have no idea why.
They have both been setup in the same way, just the larger set one has been running a year or so longer than the other.
Another thing I noticed was that the larger one was parsing the 45 OSV data sources, but the other only 25 out of the 45 that are available.
I deleted all the OSV data sources on the smaller set system, restarted DT on it and it started pulling them again, but this time only 21 of them. It has also not regenerated the vulnerabilities index since restarting. a couple of hours ago.
These are the ones that it has done:
[EMPTY]
AlmaLinux
Azure Linux
CleanStart
CRAN
Debian
GHC
GitHub Actions
Go
GSD
Mageia
MinimOS
openEuler
openSUSE
Packagist
Pub
PyPI
SUSE
Ubuntu
UVI
Wolfi
A colleague of mine made the same changes on his server and his is showing around ~600 vulnerabilities for the same SBOM.
Is there any way of forcing DT to delete the current index and sources so they can be rebuilt? We do not want to delete the overall volumes.
I have even gone so far as to create a new system to see what I would get on that and it has been running about 4 hours and downloaded the 2002-2026 NVD vulnerability items but none of the OSV ones.
Am I missing something really simple? We do not feel that we can trust this until multiple people can get the same results from the same SBOM.
Many thanks :'(
Beta Was this translation helpful? Give feedback.
All reactions