dependency-track

dependency-track copied to clipboard

The /v1/vulnerability/component/{ident} endpoint allows the specifying a hash or component uuid to retrieve the vulnerabilities.

Enhance this endpoint to support Package URL.

Also, enhance this endpoint to support non-tracked components - or components that are not currently in the database. If a PURL is specified and the component is not tracked, this enhancement should use existing logic to perform a scan.

The cache manager should be used to cache responses if the component is not tracked.

Would this open up the possibility of improving the "latest version" info so that, when you have an out-of-date version then you can see that upgrading to latest would not introduce any vulnerability?

Possibly. OSS Index provides this for authenticated users, but there isn't an API for it. So unable to use OSS Index directly. I could try to force it by checking each version of a component., but that would be a lot of overhead.

More than likely, once commercial sources of vuln intel are integrated into DT such as Nexus IQ and Snyk, it would be much easier to perform this type of check.

This issue has been opened before the new component model was introduced. Now, an identity like a hash or a purl may match multiple components across multiple projects. Moreover, even if the purl matches, hashes may be different. It's not straightforward to determine which tracked component is meant or if the project is tracked in the first place.

I'm wondering what the correct behavior of the proposed endpoint would be? Given the context outlined above, it probably should return results for all matched components?

Or should the endpoint always trigger a scan (results may be loaded from cache)? If yes, should results be applied to all tracked components that match the queried component identity?

@nscuro, I think using one of: CPE, PURL, or SWID will likely be the path forward, and it would be generic, not specific to a project, or take into consideration different hashes, etc. I think this will be a very simple lookup which would take a CPE, PURL, or SWID tag ID and use one or more of the different sources of vulnerability intelligence to return results.

I see a dependency on #1642 here. Implementing this will also require some refactoring of the current scanning logic, to decouple it from the persistence layer a little.

This will be a bigger task and is also affected by how #1642 turns out. Moving to 4.7.