Dependency-Track in a (loosely) air-gapped-like environment

[tnm-l]

HI,

We are working in an environment where we are allowed to fetch some specific information from the Internet (which lets us access most of the services listed in the Dependency Track’s services.bom.json) but not to post data to an external site. We would like to use Dependency Track to monitor the dependencies of our projects but, for it to be useful, we would need to send requests to OSS Index, since it seems to be the most exhaustive way to map dependencies identified via their package URL to vulnerabilities (without the need for a paid subscription).

Our CISO is concerned that sending data to OSS Index would leak a “dependency signature” of our projects (i.e. a list of all their dependencies and vulnerabilities) to a third party and won’t let us do this unless we hide these dependencies by mixing them with enough “ghost dependencies” (dependencies being artificially added to the request but not actually used by the projects) in the requests being sent.

We are aware of the plans of the Dependency Track team described in #4122 about a centralized vulnerability database and they may very well be a solution for us in the future but we would like to be able to use Dependency Track before this feature lands. Therefore, we are currently thinking of designing or own way of managing “ghost dependencies”. But before we do that, we have two questions:

We know there are several external data sources that can be mirrored by Dependency Track (like OSV and GitHub Advisory) and used by its internal analyzer but haven’t been able to get as much from them as from OSS Index. Our assumption is that OSS Index is the only way to map dependencies identified by their purl to vulnerabilities (without the need for a paid subscription ) while taking, at least, into account, all the vulnerabilities listed in the NVD with a limited amount of false positives or negatives. Is this assumption correct?

If this is correct, would the Dependency Track team be interested in a contribution that implements a means of dealing with hidden “ghost dependencies”?

I’m roughly describing what we have in mind in the proposed behavior section below but if another approach or a different design is more welcome, we are obviously open for suggestions.

Proposed behavior
An option is added to Dependency Track to handle “ghost dependencies” of projects.
Those dependencies are sent to the configured external analyzers together with the real one. Their vulnerabilities, licenses and latest versions are fetched but they don’t contribute to the various tabs of a project (Overview, Components, Services, Dependency Graph, Audit Vulnerabilities, Exploit Predictions and Policy Violations), to the Dependency-Track Dashboard, to the vulnerability view or to the vulnerability and policy violation audits.
They can be configured to be added automatically to selected projects and to be updated according to the updates of the projects’ real dependencies.
They contribute to a specific “ghost dependencies” tab of a project

In any case, thanks for your work on this tool and for your answer to come

[tnm-l]

We eventually chose another approach.