@@ -58,9 +58,18 @@ Here are some details about mandatory and optional permissions used by the templ
| `PROJECT_CREATION_UPLOAD` | **optional** | This is required if you want to automatically create the project while uploading the SBOM files when the project does not exist (**but the parent project must exist**) |
| `VIEW_PORTFOLIO` and `PORTFOLIO_MANAGEMENT` | **optional** | Required if you want to automatically create one or several project ancestors prior to uploading the SBOM files.<br/>Granting those permissions is not recommended in the general case as they virtually give administration rights to the API Key owner |
### Multiple SBOM strategy
When collecting several SBOM files in a project, this template supports two strategies:
- publish each SBOM independently in **separate projects** (default),
- or **merge** all SBOM files and publish the result into a single project.
The merge strategy can be simply enabled by setting the `merge` / `$DEPTRACK_MERGE` configuration to `true` (see [below](#configuration)).
### Project Path
Whenever a SBOM file is found, the template uploads it to the Dependency Track server under a certain project.\
Whenever a SBOM file is published, the template uploads it to the Dependency Track server under a certain project.\
The target project is determined by evaluating the `project-path` input / `$DEPTRACK_PROJECT_PATH` variable (see [configuration chapter](#configuration)).
The project path is a sequence of elements separated by double slashes `//` (the separator is also configurable with the `path-separator` input / `$DEPTRACK_PATH_SEPARATOR` variable).\
@@ -72,12 +81,12 @@ Each element is expected to be one of the following:
Lastly, the project path supports some **expressions**, that will be dynamically replaced when being evaluated:
| `{file_prefix}` | SBOM filename prefix (before the first dot).<br/>Ex: when processing the file `reports/docker-sbom.cyclonedx.json`, `{file_prefix}` will be `docker-sbom`. |
| `{sbom_name}` | `Metadata > Component > Name` info extracted from the SBOM file (json or xml) |
| `{sbom_version}` | `Metadata > Component > Version` info extracted from the SBOM file (json or xml) |
| `{sbom_type}` | `Metadata > Component > Type` info extracted from the SBOM file (json or xml) |
| Expression | Value for separate SBOM files| Value for merged SBOM |
| `{file_prefix}` | SBOM filename prefix (before the first dot).<br/>Ex: when processing the file `reports/docker-sbom.cyclonedx.json`, `{file_prefix}` will be `docker-sbom`. |`merged` |
| `{sbom_name}` | `Metadata > Component > Name` info extracted from the SBOM file (json or xml) |`unk` |
| `{sbom_version}` | `Metadata > Component > Version` info extracted from the SBOM file (json or xml) | _empty string_ |
| `{sbom_type}` | `Metadata > Component > Type` info extracted from the SBOM file (json or xml) |`unk` |
#### Default project path
@@ -104,7 +113,7 @@ Example: Let's imagine a GitLab project located in `acme-program/acme-services/a
Lastly, let's suppose the project production branch is `main`, and 2 software versions have been released so far: `1.0.0` and `1.1.0`.
Then the corresponding Dependency Track project structure will be:
The corresponding Dependency Track project structure **with separate SBOMs strategy**will be:
```
| Project name | Version |
@@ -119,6 +128,17 @@ Then the corresponding Dependency Track project structure will be:
| ...
```
The corresponding Dependency Track project structure **with merged SBOMs strategy** will be: