Repository navigation
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 33 |
🟢 Coverage 90.24% diff coverage · +0.01% coverage variation
Metric Results Coverage variation ✅ +0.01% coverage variation (-1.00%) Diff coverage ✅ 90.24% diff coverage (70.00%) Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (feba327) 46217 40694 88.05% Head commit (4b973c3) 46258 (+41) 40734 (+40) 88.06% (+0.01%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#6935) 41 37 90.24% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
| /** | ||
| * Resolves the organization that manufactured the BOM document itself | ||
| * (CycloneDX {@code metadata.manufacturer}), as opposed to the manufacturer | ||
| * of the project/subject component described by the BOM. | ||
| * <p> | ||
| * A manufacturer captured from a previously imported BOM for this project | ||
| * takes precedence over the system-wide default configured in Admin > General. | ||
| */ | ||
| private static OrganizationalEntity resolveBomManufacturer(final Project project, final QueryManager qm) { | ||
| if (project != null && project.getMetadata() != null && project.getMetadata().getManufacturer() != null) { | ||
| return project.getMetadata().getManufacturer(); | ||
| } | ||
| return manufacturerFromConfig(qm); | ||
| } |
There was a problem hiding this comment.
Always falling back to a global default is not safe.
This assumes all projects in the portfolio are your own, which in many cases they aren't. For example if you consume BOMs from your vendors, or you monitor other OSS projects, and so on.
Even if all projects were strictly internal, you could still have multiple sub-organizations / departments with different logical business entities, also making a single global default impractical.
Regardless of the global default, import and export of manufacturers data is something we should support. So perhaps it's worth decoupling the two things.
There was a problem hiding this comment.
But does it really matter who owns the project? The manufacturer in question here is the manufacturer of the SBOM itself and not the project/component described by the SBOM. In my opinion a global default makes sense in this case, since whoever operates the DependencyTrack instance is de-facto the manufacturer of all SBOMs exported from it.
Alternatively, I could also make the SBOM manufacturer configurable at a project level, maybe in the Identiy tab. This way individual projects could overwrite the global default, without having to alter the SBOMs they import.
There was a problem hiding this comment.
@nscuro Did you have time to consider my suggestions? How should I proceed with this PR?
There was a problem hiding this comment.
The manufacturer in question here is the manufacturer of the SBOM itself and not the project/component described by the SBOM.
Ah, yes you're totally right: https://cyclonedx.org/docs/1.7/json/#metadata_manufacturer
My bad for mixing that up.
In my opinion a global default makes sense in this case, since whoever operates the DependencyTrack instance is de-facto the manufacturer of all SBOMs exported from it.
Split on this. It's possible that a single operator provides a DT instance to multiple departments or business units. Presumably those (sub-) organizations would lead to different metadata.manufacturer values.
But this more granular option can likely be added later, given the global option introduced in this PR is optional. So I guess the proposed change makes sense as is.
Unfortunately the PR has accumulated some merge conflicts now. If you're still interested in getting this merged, please resolve them. Otherwise let me know if you want this closed instead.
There was a problem hiding this comment.
I rebased onto current main. Most conflicts were due to the reformat, but there was a genuine conflict in createMetadata. I fixed it by using JDBI to read the global defaults.
I also fixed a bug in my JSONB mapping and added the manufacturer to R__clone_project.sql.
Persists manufacturer of imported SBOMs. Adds setting for instance wide default for manufacturer. Export uses either the saved manufacturer of the import or the instance wide default. Signed-off-by: Patrick Schmitt <patrick_98@t-online.de>
Signed-off-by: Patrick Schmitt <patrick_98@t-online.de>
Declare the DataNucleus cast functions for the JSONB manufacturer column, since the JDO mapping otherwise binds a text parameter that Postgres rejects; add MANUFACTURER to the clone function, which copies PROJECT_METADATA by explicit column list and so dropped it; and restore the metadata.manufacturer import mapping. Signed-off-by: Patrick Schmitt <patrick_98@t-online.de>
b924efc to
4b973c3
Compare
Description
This adds support for the SBOM manufacturer field (author of the SBOM).
If an imported SBOM contains the manufacturer field, it is persisted.
Additionally a new instance setting can be used to provide a default manufacturer, which is used if the imported SBOMs do not contain a manufacturer.
Addressed Issue
fixes #3935
related to #6852
Additional Details
Note that the CycloneDX manufacturer field is only available from v1.6 onward, therefore the manufacturer is not included in the SBOM downloaded via the UI (hardcoded to v1.5).
If requested it would also be possible to enhance this feature with a per-project manufacturer setting, so projects could deviate from the instance default or override the imported SBOM's manufacturer.
Related PRs: DependencyTrack/frontend#1737 DependencyTrack/docs#215
Checklist
- [ ] This PR fixes a defect, and I have provided tests to verify that the fix is effective- [ ] This PR is a substantial change (per the ADR criteria), and I have added an ADR underdocs/adr/