Separation of Component and ProjectComponent

[CBerndt-Work]

While looking into the source code, I noticed that while the a component should look the same independently of the project in which it is used every project has its own instance of the component.

I propose to split the information that is purely dependent on the component from the information that describes the component in the project context.
Information like CPE, PURL, Swid, ... would live in the Component and
ProjectComponent would hold a reference to the Project and the Component as well as context information (The only context information I found was BomRef).

The goal and benefit of this would be to have a single instance of a component. This single instance would aggregate all information known about this component.
If for example different sboms provide different subsets of information on the same component (e.g. one has PURL and CPE, the other PURL and SWID) this information could then be merged and concentrated in this single instance to provide a more detailed set information and thereby a better basis for analysis.
It would also make it easier to work with components, as components would not have to be updated once for each project they are included in.

[stevespringett]

Originally, DT 1.0-3.8 had a global component model. It was easy to manage, easy to audit, but obviously had a lot of limitations and lacked project-specific nuance. A global model also made it difficult to prevent duplicates, so a lot of synchronization logic was necessary to prevent duplicates from occurring, which had a performance penalty for orgs ingesting lot of boms from different projects simultaneously.

Moving from a global object model to a hybrid model, similar to what you suggested, was the plan. However, it was incredibly difficult to move to a hybrid model due to the complexity of the upgrade/migration logic that would have been required. The migration from 3.x to 4.x , which has a project-centric model, was already extremely difficult. A hybrid model would have added additional complexity.

I'm certainly open to finding a solution to separate out component identity. DT does this transitively today, but there may be a better way, and I'm not convinced that database changes are the key. We might want to look to see if Lucene can help us with the model. One use case that complicates things a bit is the manual use case where a user (person or api) can modify the identity of a component.

[CBerndt-Work]

I would have, perhaps naively, used the same test as in ComponentQueryManager.matchIdentity(final Project project, final ComponentIdentity cid) for matching. That identity match is already performed when reading a sbom, so there wouldn't be a performance penalty. The quality of the results of this are of course limited by the input provided.

It also seems counterintuitive to me that the global component model would result in a higher load on the system, as vulnerabilities are matched to the components. Analysis could attach found vulnerabilities to components and would only have to match them once per component. This should reduce load especially in high throughput scenarios, as each component only has to be analyzed once. Audit findings would have to be attached to the hybrid part, as the relevance of the vulnerability depends on the project.

I don't really see a use case where a user would need to modify the identity of a component, if that component is decoupled from the project. The user might change which component is referenced, because e.g. they want to reference a more specific variant of the component or noticed that a wrong component was referenced. But the identity of the component itself should be unchanging or in case of additional information become more detailed.

As I have not yet worked with Lucene I cannot really say anything on the matter. Do you have an idea how it might help?

I'm still at the beginning of getting into this project and might have made some assumptions or oversights that seem obvious to you. If that is the case I'd appreciate feedback on them.
I do intend to contribute, once I feel confident in my understanding of the project and your vision for it. Although I certainly won't start with this topic ^^