Error while uploading same SBOM Second time #2131

g-sahil22 · 2022-11-07T06:53:08Z

The defect may already be reported! Please search for the defect before creating one.

Current Behavior:

When I upload the SBOM in Dependency Track for the First time in a new project it uploads successfully without any error logs and also reports the correct number of Components, but I upload the same SBOM in the same project again it shows error logs and reports the incorrect count of components

Logs When I upload SBOM First time

Number of Components: 1686

Logs When I upload the SBOM Second time

Number of Components: 1611

Steps to Reproduce:

Step 1: Create a New project
Step 2: Upload SBOM in the New project
Step 3: Monitor the logs and Number of components shown in the Dependency track
Step 4: Again upload the same SBOM in the Same project
Step 5: Monitor the logs and Number of components shows in the Dependency track

Expected Behavior:

Environment:

Report the Same number of components without any error logs when we upload SBOM second time in same project

Dependency-Track Version: 4.6.2
Distribution: Docker
BOM Format & Version: JSON, Cyclonedx 1.4
Database Server: H2 and PostgreSQL
Browser: Chrome

jakobpinggera · 2022-11-07T13:20:56Z

We are experiencing the same issue. Interestingly, it does not seem to be deterministic whether the issue arises.

I uploaded the same BOM file twice (to a project that already had processed BOM files in the past). On the first try, the exception occurred. A minute later, the same file got processes successfully.

2022-11-07 13:14:16,580 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: 2eaa3deb-1c38-4d24-a306-4c8d3081e393 2022-11-07 13:14:22,020 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Identified 0 new components 2022-11-07 13:14:22,021 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Processing CycloneDX dependency graph for project: 2eaa3deb-1c38-4d24-a306-4c8d3081e393 2022-11-07 13:14:22,583 [] ERROR [org.dependencytrack.tasks.BomUploadProcessingTask] Error while processing bom javax.jdo.JDOObjectNotFoundException: Object with id "org.dependencytrack.model.Component:0" not found ! at org.datanucleus.api.jdo.JDOAdapter.getJDOExceptionForNucleusException(JDOAdapter.java:634) at org.datanucleus.api.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1726) at org.dependencytrack.persistence.ComponentQueryManager.recursivelyDelete(ComponentQueryManager.java:414) at org.dependencytrack.persistence.ComponentQueryManager.reconcileComponents(ComponentQueryManager.java:517) at org.dependencytrack.persistence.QueryManager.reconcileComponents(QueryManager.java:771) at org.dependencytrack.tasks.BomUploadProcessingTask.inform(BomUploadProcessingTask.java:138) at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:101) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) Caused by: org.datanucleus.exceptions.NucleusObjectNotFoundException: Object with id "org.dependencytrack.model.Component:0" not found ! at org.datanucleus.store.rdbms.request.FetchRequest.execute(FetchRequest.java:473) at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.fetchObject(RDBMSPersistenceHandler.java:354) at org.datanucleus.state.StateManagerImpl.loadFieldsFromDatastore(StateManagerImpl.java:1608) at org.datanucleus.state.StateManagerImpl.validate(StateManagerImpl.java:5570) at org.datanucleus.ExecutionContextImpl.findObject(ExecutionContextImpl.java:3446) at org.datanucleus.ExecutionContextImpl.findObject(ExecutionContextImpl.java:2928) at org.datanucleus.api.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1721) ... 8 common frames omitted 2022-11-07 13:15:01,134 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: 2eaa3deb-1c38-4d24-a306-4c8d3081e393 2022-11-07 13:15:06,350 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Identified 0 new components 2022-11-07 13:15:06,351 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Processing CycloneDX dependency graph for project: 2eaa3deb-1c38-4d24-a306-4c8d3081e393 2022-11-07 13:15:06,716 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Processed 434 components and 0 services uploaded to project 2eaa3deb-1c38-4d24-a306-4c8d3081e393 2022-11-07 13:15:13,825 [] INFO [org.dependencytrack.tasks.scanners.InternalAnalysisTask] Starting internal analysis task 2022-11-07 13:15:15,072 [] INFO [org.dependencytrack.tasks.scanners.InternalAnalysisTask] Internal analysis complete 2022-11-07 13:15:15,074 [] WARN [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] An API username or token has not been specified for use with OSS Index. Using anonymous access 2022-11-07 13:15:15,075 [] INFO [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] Starting Sonatype OSS Index analysis task 2022-11-07 13:15:17,695 [] INFO [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] Analyzing 89 component(s) 2022-11-07 13:15:19,848 [] INFO [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] Analyzing 82 component(s) 2022-11-07 13:15:21,835 [] INFO [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] Analyzing 98 component(s) 2022-11-07 13:15:23,204 [] INFO [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] Analyzing 100 component(s) 2022-11-07 13:15:23,877 [] INFO [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] Analyzing 33 component(s) 2022-11-07 13:15:23,877 [] INFO [org.dependencytrack.tasks.scanners.OssIndexAnalysisTask] Sonatype OSS Index analysis complete 2022-11-07 13:15:23,878 [] INFO [org.dependencytrack.policy.PolicyEngine] Evaluating 434 component(s) against applicable policies 2022-11-07 13:15:25,771 [] INFO [org.dependencytrack.policy.PolicyEngine] Policy analysis complete 2022-11-07 13:15:25,772 [] INFO [org.dependencytrack.tasks.metrics.ProjectMetricsUpdateTask] Executing metrics update for project 2eaa3deb-1c38-4d24-a306-4c8d3081e393 2022-11-07 13:15:28,239 [] INFO [org.dependencytrack.tasks.metrics.ProjectMetricsUpdateTask] Completed metrics update for project 2eaa3deb-1c38-4d24-a306-4c8d3081e393 in 00:02:466

Environment:

Dependency-Track Version: 4.6.1
Distribution: Docker
BOM Format & Version: JSON, Cyclonedx 1.4
Database Server: PostgreSQL
Browser: Chrome

valentijnscholten · 2022-11-07T20:53:10Z

I am seeing the same exception in my logs from time to time. I haven't been able to reproduce it.

2022-11-05 00:22:26,676 ERROR [BomUploadProcessingTask] Error while processing bom
javax.jdo.JDOObjectNotFoundException: Object with id "org.dependencytrack.model.Component:0" not found !
        at org.datanucleus.api.jdo.JDOAdapter.getJDOExceptionForNucleusException(JDOAdapter.java:634)
        at org.datanucleus.api.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1726)
        at org.dependencytrack.persistence.ComponentQueryManager.recursivelyDelete(ComponentQueryManager.java:414)
        at org.dependencytrack.persistence.ComponentQueryManager.reconcileComponents(ComponentQueryManager.java:517)
        at org.dependencytrack.persistence.QueryManager.reconcileComponents(QueryManager.java:771)
        at org.dependencytrack.tasks.BomUploadProcessingTask.inform(BomUploadProcessingTask.java:138)
        at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:101)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

nscuro · 2022-11-09T18:09:32Z

FWIW this is happening when the BOM includes duplicate components. The reconcileComponents method is relying on the persistence layer to determine whether two components are equal. It's possible that >1 components in Java end up being mapped to the same database row. When deleting such a component in Java, the backing DB row is deleted by the ORM, but the other Java component instances that mapped to the same row are not. When trying to delete those too the exception Object with id ... not found will be thrown.

Another symptom of this is a decrease in component count when uploading the BOM multiple times. Upon every upload, more and more of those duplicate components are removed.

g-sahil22 · 2022-11-14T05:47:32Z

Hi @nscuro, Thanks for the information, I have one question is this issue related to SBOM?

ariyonaty · 2022-11-18T17:32:26Z

We're noticing similar behavior to @nscuro mentioned when uploading the same BOM multiple times. The first upload to Dependency Track matches the number of components listed in the BOM. However each upload of the same BOM after that (to the same project name/version) results in a decreased count.

In particular, this only occurs with merged BOMs (using cyclonedx-cli), such as when merging a language-specific BOM with a container image BOM. A manual inspection shows duplicate components in the BOM.

Environment:
Dependency-Track Version: 4.5.0

g-sahil22 · 2022-11-28T11:14:38Z

Hi @nscuro, when I delete all the components and then re-upload the SBOM then Its works, Yes the previous Project contains Number of Duplicates entries

flemminglau · 2022-12-06T09:02:21Z

I attempted to delete all components but get left with one or two that cannot be deleted. Not the same ones at each attempt.

Is there a workaround for this?
Something I can do to my CDX file to prevent this from happening?
(Except removing all duplicates :-( )

flemminglau · 2022-12-06T13:28:29Z

Edited: My original suggestion to do unique in purl did nothing and only seemed to work due to the apparent randomness of the issue.

So instead:
Which can by the way be done via:

jq   '.components |= unique_by([.name, .version]) '  bom.json  > bom-unique.json

This seems to work around the problem.
(Original files failed 5 out of 9 attempts uploading the same file. The deduplicated one was successful 9 out of 9 attempts.)

rkg-mm · 2022-12-12T16:05:13Z

Since we ran into the same issue with #2265 we did some further analysis.

The issue seems to be following:
First Upload:
Every component entry from BOM is thrown into the database 1:1, no deduplication

Second upload (same or different BOM):

For every component, the method matchSingleIdentity does search an equivalent in the database. It always finds the first match for duplicates
Multiple entries of the same component in the new BOM file will all be matched to the first existing equivalent component, ideally the same one
All other duplicates already in the DB will be deleted, since those are not flagged to be kept
Since the components in new BOM file are known already, they are not persistet but all mapped to the same one in DB now
During the deletion then somehow the references to the duplicates are messed up since they might be deleted already. Not 100% sure whats going on there then, that seems to be persistence layer specifics

Therefore, it makes sense that some reported the problem here only with merged BOMS (can merge duplicates into one, since merge tool does not deduplicate either) and me having the issue with @cyclonedx/cyclonedx-npm, since that tool generates a ton of duplicates (which have different ref-entries in the XML but the data used by matchSingleIdentity is identical for all of them (which makes sense in my opinion).

Basically I see this issue here:

First upload does not deduplicate
Further uplaods DO deduplicate but can't handle existing duplicates well.

We would provide a fix (this is affecting many of our projects since i switched to the new NPM cyclonedx module, as I just noticed) but I am unsure how to fix. In my opinion, during every upload we should FIRST deduplicate the BOM before hitting the database. That would eliminate the issue, ensure every upload has the same result and not different component counts after a second upload, and also fix the issue that component show up X times for the same project.
Is this what others would expect too?

Then it's just the question how to fix existing data....

nscuro · 2022-12-13T13:57:28Z

Doing the de-duplication upfront should definitely solve this.

But de-duping components can be complex, as evident by the thought work that @jkowalleck has been doing in CycloneDX/cyclonedx-node-npm#307. For DT specifically, when de-duplicating 2 or more components, the dependency graph needs to reflect this, otherwise it will have broken edges.

The golden question is: "When are two components identical?"
At the very least, for DT purposes, the following properties should match:

Type
Group (if exists)
Name
Version
CPE (if exists)
PURL (if exists)
SWID Tag ID (if exists)
Hashes (if exists)

But even those don't cover the whole picture. License, dependencies, supplier/author/provider, etc. are all things that could make a component "different".

jkowalleck · 2022-12-13T14:03:44Z

re: #2131 (comment)

the point of view that DependencyTrack might have is dependency-focused. Therefore, it could be acceptable to de-dupe on a handful of properties, and apply this result on the dependency graph, too.

flemminglau · 2022-12-13T14:25:00Z

Also consider on de-duplication:
Different instances of the exact same component used in multiple places may need to receive different Audit Treatment.
The dependencies may come from completely different transient dependencies which makes it unreasonable to only apply a single Audit treatment for a single common instance. (One may be a "False-Positive" while the other is a "Not-Affected".)

But maybe that is going too far.

(There is as far as we can see in general a challenge when trying to apply (multiple) non-deduplicated VEX data to a deduplicated project. I don't see a logical solution to this.)

rkg-mm · 2022-12-13T14:31:30Z

re: #2131 (comment)

the point of view that DependencyTrack might have is dependency-focused. Therefore, it could be acceptable to de-dupe on a handful of properties, and apply this result on the dependency graph, too.

I also would take the purpose of Dependency-Track into account here. We use PURLs etc. to find vulnerabilities. If those are equal, there is no point in keeping 2 instances. License information is the 2nd use case. So possibly take license-ID into account, too. I don't see a big chance the license will differ, but who knows.

Regarding @flemminglau comment:
I see your point, but thats nothing Dependency-Track supports today either. You don't really see the difference between components in the audit views. Possibly in the new dependency-graph you can see it, but that gets difficult. I'd rather have one instance of the component and then see all occurances in the graph at once, not having 5 instances and having to open the graph 5 times to see the occurances, then trying to figure out which graph is which entry in the audit view.

And yes, in any case the graph also needs to reflect the deduplication. All instances in graph must be redirected to the one instance that is kept.

edit:
When adding components manually we should also ensure no duplicates are added then to prevent further errors.

rkg-mm · 2022-12-13T14:51:11Z

Current logic for matching on re-upload seems to be:

"project == :project && ((purl != null && purl == :purl) || (purlCoordinates != null && purlCoordinates == :purlCoordinates) || (swidTagId != null && swidTagId == :swidTagId) || (cpe != null && cpe == :cpe) || (group == :group && name == :name && version == :version))"

valentijnscholten · 2022-12-13T14:55:45Z

Seems like this is quite a common error. So for 4.7 it might be could to at least add a try-catch around the delete statement. If something we want to delete is already deleted, it's probably, at least for now in this specific case, OK to ignore that exception.

rkg-mm · 2022-12-13T17:28:37Z

Workaround PR is created, that would fix the failing of BOM processing.
Nonetheless, we should consider the deduplicating I think. Could be made optional (default active maybe?) for someone who explicitly does not want this during upload via parameter.

syalioune · 2022-12-13T17:46:06Z

My two cents : since the deduplication logic performed on second upload does not seem to question anyone, I would apply the same filter on the first upload as a first approach. From then on, it can surely be improved with additional fields.

jonny64 · 2023-02-27T12:17:30Z

#2131 (comment)

same situation, SBOM, component cnt decreased, cannot delete those two

Caused by: org.datanucleus.exceptions.NucleusObjectNotFoundException: Object with id "org.dependencytrack.model.Component:81" not found !
        at org.datanucleus.store.rdbms.request.FetchRequest.execute(FetchRequest.java:473)
        at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.fetchObject(RDBMSPersistenceHandler.java:354)
        at org.datanucleus.state.StateManagerImpl.loadFieldsFromDatastore(StateManagerImpl.java:1608)
        at org.datanucleus.state.StateManagerImpl.loadUnloadedFieldsInFetchPlan(StateManagerImpl.java:3931)
        at org.datanucleus.state.StateManagerImpl.isLoaded(StateManagerImpl.java:4135)
        ... 74 common frames omitted

what shoud we do to clean out those components from database?

rkg-mm · 2023-02-27T13:18:46Z

@jonny64 there should be a workaround in place since 4.7., which version are you on?

jonny64 · 2023-03-03T13:28:45Z

@rkg-mm 4.6.2, update to 4.7 and re-upload BOM to fix ?

rkg-mm · 2023-03-03T13:30:11Z

@jonny64 yes 4.7 should fix this.

nscuro · 2023-07-05T10:11:11Z

I am working on this area of the code right now, and I am confident that I have a fix at hand for this problem.

What the persistence layer does today is basically de-duplication based on ComponentIdentity. I have shifted this logic so it now happens before we even touch the database. It also handles re-wiring of the dependency graph so that de-dupe'd components to not break the graph.

I'd love to test this with BOMs that are known to be problematic. Anyone in this thread willing to share some with me? If you're uncomfortable sharing publicly, you can also DM them to me in the OWASP Slack (my name there is nscur0), or email them to me (address is in my GitHub profile).

melba-lopez · 2023-07-28T19:37:10Z

@nscuro has this been addressed per DependencyTrack/hyades-apiserver#218? and would this be a 4.10 potential fix?

github-actions · 2024-03-26T10:05:28Z

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

g-sahil22 added the in triage label Nov 7, 2022

nscuro added defect Something isn't working p2 Non-critical bugs, and features that help organizations to identify and reduce risk and removed in triage labels Nov 9, 2022

valentijnscholten mentioned this issue Dec 11, 2022

Incompatibility with SBOM from @cyclonedx/cyclonedx-npm #2265

Closed

2 tasks

rbt-mm mentioned this issue Dec 13, 2022

Workaround for deleting duplicate components when uploading a new BOM #2278

Merged

1 task

syalioune mentioned this issue Dec 18, 2022

Component count not reflecting correctly #2304

Closed

2 tasks

rkg-mm mentioned this issue Feb 24, 2023

Believe this is an issue ... findings change with each scan of same SBOM #2519

Closed

2 tasks

syalioune mentioned this issue May 15, 2023

DependencyTrack hangs when uploading a large SBOM to a project a second time #1905

Closed

nscuro mentioned this issue Jul 3, 2023

Profile and optimize BOM ingestion performance DependencyTrack/hyades#635

Closed

nscuro mentioned this issue Jul 5, 2023

Improve BOM processing performance DependencyTrack/hyades-apiserver#218

Merged

2 tasks

melba-lopez assigned nscuro Jul 28, 2023

melba-lopez added the pending release label Jul 28, 2023

nscuro mentioned this issue Jan 7, 2024

Refactor BOM upload processing for better efficiency, correctness, and consistency #3357

Merged

3 tasks

nscuro added this to the 4.11 milestone Jan 7, 2024

nscuro closed this as completed in #3357 Feb 24, 2024

github-actions bot locked as resolved and limited conversation to collaborators Mar 26, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error while uploading same SBOM Second time #2131

Error while uploading same SBOM Second time #2131

g-sahil22 commented Nov 7, 2022

jakobpinggera commented Nov 7, 2022 •

edited

Loading

valentijnscholten commented Nov 7, 2022

nscuro commented Nov 9, 2022 •

edited

Loading

g-sahil22 commented Nov 14, 2022

ariyonaty commented Nov 18, 2022

g-sahil22 commented Nov 28, 2022

flemminglau commented Dec 6, 2022

flemminglau commented Dec 6, 2022 •

edited

Loading

rkg-mm commented Dec 12, 2022 •

edited

Loading

nscuro commented Dec 13, 2022

jkowalleck commented Dec 13, 2022

flemminglau commented Dec 13, 2022

rkg-mm commented Dec 13, 2022 •

edited

Loading

rkg-mm commented Dec 13, 2022 •

edited

Loading

valentijnscholten commented Dec 13, 2022

rkg-mm commented Dec 13, 2022

syalioune commented Dec 13, 2022

jonny64 commented Feb 27, 2023

rkg-mm commented Feb 27, 2023

jonny64 commented Mar 3, 2023

rkg-mm commented Mar 3, 2023

nscuro commented Jul 5, 2023

melba-lopez commented Jul 28, 2023

github-actions bot commented Mar 26, 2024

Error while uploading same SBOM Second time #2131

Error while uploading same SBOM Second time #2131

Comments

g-sahil22 commented Nov 7, 2022

Current Behavior:

Steps to Reproduce:

Expected Behavior:

Environment:

jakobpinggera commented Nov 7, 2022 • edited Loading

valentijnscholten commented Nov 7, 2022

nscuro commented Nov 9, 2022 • edited Loading

g-sahil22 commented Nov 14, 2022

ariyonaty commented Nov 18, 2022

g-sahil22 commented Nov 28, 2022

flemminglau commented Dec 6, 2022

flemminglau commented Dec 6, 2022 • edited Loading

rkg-mm commented Dec 12, 2022 • edited Loading

nscuro commented Dec 13, 2022

jkowalleck commented Dec 13, 2022

flemminglau commented Dec 13, 2022

rkg-mm commented Dec 13, 2022 • edited Loading

rkg-mm commented Dec 13, 2022 • edited Loading

valentijnscholten commented Dec 13, 2022

rkg-mm commented Dec 13, 2022

syalioune commented Dec 13, 2022

jonny64 commented Feb 27, 2023

rkg-mm commented Feb 27, 2023

jonny64 commented Mar 3, 2023

rkg-mm commented Mar 3, 2023

nscuro commented Jul 5, 2023

melba-lopez commented Jul 28, 2023

github-actions bot commented Mar 26, 2024

jakobpinggera commented Nov 7, 2022 •

edited

Loading

nscuro commented Nov 9, 2022 •

edited

Loading

flemminglau commented Dec 6, 2022 •

edited

Loading

rkg-mm commented Dec 12, 2022 •

edited

Loading

rkg-mm commented Dec 13, 2022 •

edited

Loading

rkg-mm commented Dec 13, 2022 •

edited

Loading