Add Dependency-Track as default project

[AbdelHajou]

Current Behavior:

When starting a fresh instance of Dependency-Track, there are no projects in the portfolio.

Proposed Behavior:

Add Dependency-Track as default project to every new portfolio, with the SBOM that has been generated during the build (should be in the resources folder).

When a new critical CVE-vulnerability is reported, companies want to know whether any of the applications within their application landscape are affected by this vulnerability. Dependency-Track is part of this application landscape, so I think it should be part of the portfolio.

This project can also be used as an example project for users who want to quickly try out Dependency-Track without generating an SBOM themselves.

Maybe the project can be made read-only, but this would take more effort to implement. I’m also not sure whether the front-end and API server should be added as separate projects, or all components should be added to the same project.

[stevespringett]

Thanks for the suggestion. Its a great idea. Will see what it will take to implement.

[AbdelHajou]

@stevespringett May I work on this?

[stevespringett]

Sure, absolutely. Ideally, there would be two projects:

1. Dependency-Track API Server
2. Dependency-Track Frontend

The BOM for the API Server is produced from the build.

There's also a BOM containing only the services used. https://github.com/DependencyTrack/dependency-track/blob/master/src/main/resources/services.bom.json

Both of these BOMs need to be merged together using the CycloneDX CLI. However, I ran into an issue with the CLI in which metadata was lost. See: https://github.com/CycloneDX/cyclonedx-cli/issues/153

The final BOM for the API Server would then contain all the components and services, which would be ideal as a default project for all new DT installations.

[AbdelHajou]

Using the merge command requires the CycloneDX CLI to be installed on the build machine, I think it would be nice to use the Maven plugin for it. However, I couldn't find a merge option in the maven plugin. I've opened an issue for this in the cyclonedx-maven-plugin repo. Do you think this would be a better option, or should we just call the CLI from a pre-release or release script?

[stevespringett]

Note, the release process will likely end up changing prior to v4.5 with #1419. I'll likely add the CycloneDX CLI to the release scripts so it will be available.

[nscuro]

Dabbling with this right now, as the issue with the CLI has since been fixed.

The BOM generated during the Maven build can be merged with the service BOM using the exec-maven-plugin:

<properties>
    <bom-merge.cyclonedx-cli.path>cyclonedx</bom-merge.cyclonedx-cli.path>
    <bom-merge.skip>true</bom-merge.skip>
</properties>
<!-- ... -->
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>merge-bom</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>exec</goal>
            </goals>
            <configuration>
                <executable>${bom-merge.cyclonedx-cli.path}</executable>
                <arguments>
                    <argument>merge</argument>
                    <argument>--input-files</argument>
                    <argument>${project.build.directory}/bom.json</argument>
                    <argument>${project.basedir}/src/main/resources/services.bom.json</argument>
                    <argument>--output-file</argument>
                    <argument>${project.build.directory}/bom.json</argument>
                </arguments>
                <skip>${bom-merge.skip}</skip>
            </configuration>
        </execution>
    </executions>
</plugin>

My suggestion would be to have ${bom-merge.skip} default to false so that the build won't fail when folks don't have the CLI installed. There's already a build step that copies the BOM to .well-known/sbom:

https://github.com/DependencyTrack/dependency-track/blob/45868a937f9e5902bee630a2a8c627e459b773d1/pom.xml#L375-L378

We can load the SBOM from the classpath at runtime, parse it, and create a project from it. Was wondering though, do we want to kick off the various analysis tasks we have, or do we just import the data?

[syalioune]

Was wondering though, do we want to kick off the various analysis tasks we have, or do we just import the data?

I would personally expect the analysis tasks to run on the created project so that I can set up notifications for administrators.

[nscuro]

I raised a draft PR and would appreciate feedback on how this feature should behave: https://github.com/DependencyTrack/dependency-track/pull/2124

[msymons]

Moved to milestone 4.10 in order to align with incorporation of bom-repo-server etc.