chore: add empty dep-graph when there are no dependencies

[thomasschafer]

• Tests written and linted ℹ︎
• Documentation written ℹ︎ - n/a
• Commit history is tidy ℹ︎

What this does

If a uv project has no dependencies then the SBOM will have no components with a pip PURL, e.g.:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "serialNumber": "urn:uuid:ac3b8db9-2725-4a70-b080-86bec40fe7db",
  "metadata": {
    "timestamp": "2025-11-24T15:20:24.447458000Z",
    "tools": [ { "vendor": "Astral Software Inc.", "name": "uv", "version": "0.9.11" } ],
    "component": {
      "type": "library",
      "bom-ref": "[email protected]",
      "name": "no-deps",
      "version": "0.1.0"
    }
  },
  "components": [],
  "dependencies": [
    {
      "ref": "[email protected]",
      "dependsOn": []
    }
  ]
}

This means that, when the SBOM is converted to dep-graphs, no dep-graphs are returned as the conversion endpoint cannot determine the ecosystem.

To work around this, we decided to manually add an empty dep-graph in this case, which this PR implements. To achieve this I've added a new Metadata field to the Findings struct which contains enough information to construct an empty dep-graph. I'm not sure if this is the best approach so happy to hear alternative ideas here.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[mcombuechen]

The pip package manager confuses me. Why are we impersonating a different package manager which we already support?

[klesniewski]

This is to be changed. We have an RCR pending second Jedi's review to add a new package manager to Registry. Once Registry understands uv, we can use it. Before then, not sure if we can use it and why risk it if we can easily adjust once all bits are in place.

[mcombuechen]

Thanks, I was missing this context.

[mcombuechen]

nit: maybe i'm getting hung up on the name too much, but this function does not seem to only validate, but also parse the input and now also return some metadata? should we name it differently to reflect this?

[thomasschafer]

Good point, updated the name

[mcombuechen]

is the any type intentional?

[thomasschafer]

It was as the dep-graph from the conversion endpoint was just being unmarshalled into an any, but after you mentioned it I thought it might be worth exploring unmarshalling into a proper DepGraph type. I had to implement a custom UnmarshalJSON method to achieve this as we only want to unmarshall the data to a DepGraph if it has type "depGraph", but it seems to work. Have a look at the latest commit and let me know what you think!

[mcombuechen]

nice! ok i didn't see that this was coming from this polymorphic "facts" array.