Support "Dependency Track" as alternative target for SBOMs about sbom-operator HOT 7 CLOSED

I guess it would be great to use the project properties for mapping image names to projects.

This is a way a project should be found:

1. Search for project with the property "image-name" in the group "container" with the image name
2. If found use this project, if not found create a new project with the image name as the project name + also add the property "image-name"

(The property and group names may be configurable.)

Implementation:
The DT API does not provide a query for projects via property - so all projects have to be loaded in Initialize of the target and then loop through all projects and properties and create a lookup table (image-name to project id). Later in the ProcessSbom use this lookup-table to get the project id.

from sbom-operator.

I have started with a basic implementation here https://github.com/derkoe/sbom-operator/tree/dependency-track

from sbom-operator.

Hi, just came across this project and it looks like a very interesting concept. I maintain a maven plugin for integrating with Dependency Track and have a couple of thoughts on this integration approach that you have mentioned.

Regarding the API integration for uploading a BOM, why not just let DT decide to process it or not based on the project properties? If the project found by name has not also had a version change, then DT will effectively ignore that file assuming that that version has no new packages in it. If there are new packages (e.g. for a SNAPSHOT project release), then you want DT to process it. DT will then update it's local version of the project with the references to the new package information.

As such I think you should be able to avoid the complexity of iterating over the current projects and always just upload the BOM using the auto-create flag set to true. I took this approach for frequent uploads of the same project and found this to be the simplest and most effective integration approach for uploading BOMs as part of CICD pipelines.

https://github.com/pmckeown/dependency-track-maven-plugin/blob/master/src/main/java/io/github/pmckeown/dependencytrack/upload/UploadBomAction.java

Happy to discuss further with you if you like. I'm quite interested in trying out this DT integration for the multiple kube clusters I run at work.

from sbom-operator.

My Q&A from the DT-Slack channel:

The "upload" endpoint ("/api/v1/bom") needs several additional parameters (ProjectUUID, ProjectName, ProjectVersion, Autocreate). This request would be made for each OCI-Image a SBOM is generated for. Will all these parameters are the same for each upload (and only the sbom differs)? Or are they different for each upload?

You're supposed to either provide a project UUID or a projectName+projectVersion combination. UUID being useful in cases where the project exists already, and projectName+projectVersion when you're uploading a BOM for a new project. For your use case, you should go the name+version route, in combination with autoCreate. See also: https://docs.dependencytrack.org/usage/cicd/

So when there will be one projectName+projectVersion combination I can than upload all SBOMs of the cluster to this combination or should that change for each SBOM?

The latter. My expectation would be that you have one name+version combination for each image (e.g. Name: docker.io/golang, version 1.17.6-alpine3.15). Each image should be its own project in DT. This is also necessary because DT only holds the contents of the latest BOM uploaded for a project, so you can't upload multiple with different contents to the same project.

Is there a way to determine if a SBOM has already been uploaded to DT, so that my tool will only generate SBOMs for images which are new or changed?

No reliable way as of now, no. I'm not familiar with your project, but IMO determining whether a BOM has changed or not should not be the responsibility of sbom-operator, but of Dependency-Track. DT will ensure that the project will always resemble the state of the latest BOM uploaded to it.

When the operator is configured to store the SBOMs in Git, than it can be tracked there and duplicate scans can be omitted.

You can attach properties to projects in DT. It's essentially a key-value store. If you have some kind of indicator that you want to check against before generating a new SBOM, you can store and retrieve it from there: https://pkg.go.dev/github.com/nscuro/dtrack-client#ProjectProperty
Unless you're already using it as project version, you could put the image digest in there. Only when a DT project does not have a digest property, or the value of the digest is not equal to the image in your cluster, the sbom-operator could generate and upload a new SBOM.
There's an api/v1/project/lookup endpoint to query projects by their name and version: https://pkg.go.dev/github.com/nscuro/dtrack-client#ProjectService.Lookup

Is there an API to remove a project (aka. a previously uploaded SBOM)? This would be neccessary when a particular image is not deployed anymore.

Yes, DELETE /api/v1/project/<UUID> should do the trick.

from sbom-operator.

This sounds good @derkoe, thanks for working on that!
Querying all projects in Initialize is also ok for me, as long as the DT API has acceptable responce-times 😆

from sbom-operator.

Made the implementation work now - it runs successful on our test cluster. It creates Dependency Track projects on the fly (or uses existing ones with the property set).

I guess there is room for a few improvements:

• store the actual image hash as version (or as a property)
• add the Kubernetes namespace as a property

@ckotzbauer Should I create a PR for my changes?

from sbom-operator.

@ckotzbauer Should I create a PR for my changes?

Yes, please, then we can discuss improvements and other things there 👍

from sbom-operator.