Read your SBOM findings: OWASP Dependency-Track

This guide connects OWASP Dependency-Track so kanman reads the vulnerabilities and policy violations it finds in your SBOMs and acts on them like on every other public advisory.

By default kanman only reads Dependency-Track. It never changes an analysis, never suppresses a finding and only uploads SBOMs when an admin allowed it on the connection and a team chose it.

You need to be an owner or admin of the workspace for step 1 and a lead of the team (or a workspace owner or admin) for steps 2 and 3. Every member sees the mappings and the cards.

1. Connect Dependency-Track (once per workspace)

1. Open Workspace settings, choose Connections and open OWASP Dependency-Track.
2. Enter:
   • the address of your Dependency-Track API server, for example https://dependency-track.example.com
   • where kanman reaches it from: kanman’s cloud, or your runner (inside your network) if the server is only reachable inside your company network. Your self-hosted runner then reads Dependency-Track and kanman’s cloud never connects to it.
   • how kanman signs in: with a token, or with a variable on the runner
   • the secret name that holds the API key, for example DTRACK_API_KEY
3. Provide the API key in one of two ways:
   • Enter it once. kanman stores it encrypted as a workspace secret of that name and never shows it again.
   • Set it on your runners. Set a variable with that name in the runner’s or the team’s runner environment instead. kanman then never sees it.
4. Create the API key in Dependency-Track under Administration > Access Management > Teams for a team with the permissions VIEW_PORTFOLIO and VIEW_VULNERABILITY (add VIEW_POLICY_VIOLATION for policy violations, and BOM_UPLOAD only if you want uploads).
5. Leave SBOM uploads on Off (read only), or choose Allowed for teams that choose it.
6. Click Test connection. kanman checks that the address answers as a Dependency-Track server and that the key may read the portfolio.

2. Confirm which projects belong to your team

Once the connection works, kanman compares the Dependency-Track projects with each team’s repositories (project names, versions and the package URLs of their components against what each repository depends on) and proposes the projects it is confident about. The team’s leads hear about it once in the team chat.

1. Open the team’s Team settings, choose Connections and open Dependency-Track.
2. Under Projects I propose, each proposal shows the project, the repository and why kanman thinks they belong together.
3. Correct the repository if needed, then click Confirm, or Not this one. kanman never proposes a project you turned down again; ask kanman in the chat if you want it mapped later.

Confirmed projects show how many open findings their last read found and when. Forget a project to stop reading it. A project also appears on the page of the service it belongs to, under What I read for this service, where leads can forget it too.

3. Choose how SBOMs get there

On the same page:

• Read findings only (default): kanman reads what Dependency-Track already knows.
• CI job per repository (recommended): kanman proposes one story per repository that adds a CI job sending a CycloneDX SBOM to the project on every change of the default branch. The API key comes from a masked CI variable your team sets, never from the repository.
• I upload SBOMs: kanman builds an SBOM from the dependencies it scans and uploads it whenever they change. This option only appears when an admin allowed uploads on the connection.

Policy violations as findings (on by default) turns license and version policy violations into cards on your board.

What kanman does with the findings

• One card per advisory. About every hour kanman reads each confirmed project. Its vulnerabilities join the advisory watch as one more source next to OSV.dev: the same CVE or GHSA becomes one card for all affected repositories, never two.
• Your analysis counts. A finding your team marked Not affected or False positive in Dependency-Track, or suppressed there, never becomes a card. If a card is already open, it moves to done with that as the reason.
• Policy violations become cards with the policy, the component and the project. When Dependency-Track no longer reports a violation, its card moves to done.
• kanman then checks whether the vulnerable code is reached and does the fix within the team’s rights, as for every advisory. Dependency updates never merge on their own.