Ability to specify commenter when importing CycloneDX VEX

[magnus-lindhe-rrx]

Current Behavior

When a CycloneDX VEX file is uploaded to Dependency Track, the audit trail entry created for each affected vulnerability uses the hardcoded string "CycloneDX VEX" as the commenter, regardless of any authorship information present in the VEX file:

// CycloneDXVexImporter.java
private static final String COMMENTER = "CycloneDX VEX";

This means all VEX-imported audit trail entries look identical in the UI:

CycloneDX VEX - 15 Jun 2026 at 17:27:03
Details: The heap over-read affects only applications that call inflateGetHeader...

There is no way to distinguish who performed the vulnerability analysis, even when that information is present in the uploaded file.

If you do the analysis manually through the DT UI the user name will be used.

Proposed Behavior

Two solutions are proposed. Either or both could be implemented.

---

Solution A — Read metadata.authors from the VEX file

The CycloneDX specification includes a metadata.authors field explicitly designed for human-authored documents:

"The person(s) who created the BOM. Authors are common in BOMs created through manual processes."

When a VEX file is uploaded, CycloneDXVexImporter should check whether bom.metadata.authors is populated. If one or more authors are present, their names should be used as the commenter in the audit trail entry instead of the hardcoded fallback. If multiple authors are listed, they should be concatenated (e.g. "Alice Smith, Bob Jones"). If no authors are present, the current fallback of "CycloneDX VEX" should be retained to preserve backward compatibility.

Example — VEX file with author:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "metadata": {
    "authors": [
      { "name": "Alice Smith" }
    ]
  },
  "vulnerabilities": [ ... ]
}

Resulting audit trail entry:

Alice Smith - 15 Jun 2026 at 17:27:03
Details: The heap over-read affects only applications that call inflateGetHeader...

Fallback (no metadata.authors present):

CycloneDX VEX - 15 Jun 2026 at 17:27:03
Details: ...

This change requires a minimal, low-risk modification to CycloneDXVexImporter.applyVex() — the Bom object is already available at that point, so no additional parsing or API changes are needed.

---

Solution B — Optional author parameter on the VEX upload API

The VEX upload endpoint (PUT /api/v1/vex/cyclonedx/project/{uuid}) should accept an optional author query or form parameter. When provided, this value is passed through to CycloneDXVexImporter and used as the commenter in all audit trail entries created during that upload. This gives API callers and CI/CD pipelines full control over the commenter without needing to embed authorship inside the VEX file itself.

Example — API call with author parameter:

PUT /api/v1/vex/cyclonedx/project/8a4a1b2c-...
  ?author=Alice+Smith

Fallback (parameter omitted):

CycloneDX VEX - 15 Jun 2026 at 17:27:03
Details: ...

If both Solution A and Solution B are implemented, Solution B (the explicit API parameter) should take precedence over metadata.authors, which in turn takes precedence over the hardcoded fallback.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

There are a few things that make this tricky:

1. There is no guarantee that a CycloneDX file is only VEX. Some BOMs embed VEX data, in which case metadata.authors may refer to the "main" BOM, but not necessarily the VEX part of it.
2. Accepting arbitrary authors via API parameters opens the door to spoofing. User A could upload a VEX with author=B, even though user B was not involved in authoring the VEX at all.

What we could do is infer the author from the authenticated user. However that would assume the uploader to be the author, which is often not the case.

In general I agree that better auditability is needed here though. Just need to figure out a reliable and trustable way to determine the author(s).

[magnus-lindhe-rrx]

Perhaps DT could use a convention based either on annotations (verbose) or properties (lightweight).

A lightweight convention based on properties might look like this:

{
  "vulnerabilities": [
    {
      "id": "CVE-2023-1234",
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_present"
      },
      "properties": [
        {
          "name": "dt:analysis.author",
          "value": "Person A"
        }
      ]
    }
  ]
}