DependencyTrack / DependencyTrack/dependency-track

Add Internal Component Identification by Source Repository

Open
#1,145 0 comments 1 reaction 0 assignees View on GitHub
enhancement help wanted p2
Dominant language
Java
Stars
4.2k
Forks
811
Avg merge
8h 39m
Merged PRs (30d)
237

Description

### Current Behavior:
Internal components are identified by regexes which match their name or namespace. For packages which are internal and come from an internal package source, rather than the language's default package repository (so not from rubygems.org, etc), the name and namespace may not have any characteristics that identify them as internal.

With this setup it's hard for a company to use Dependency Track if they want to be cautious about which components are identified as external. It also makes it very hard to guarantee that the process of internal component identification will be resilient to changes in package naming patterns, because the regex will have to be changed in advance of every pattern change.

### Proposed Behavior:
To be able to identify internal components by metadata besides just the component's name and namespace–like identifying them by source repository using the `repository_url` field of a component's purl.

One option would be to also set a regex matching against the repository_url field, and have users be able to specify the default behavior if that field is not present in a purl.

Another option is that instead of users manually defining a regex, the repository_url field could just be compared to the urls stored in Administration>>Repositories, which already say whether they're internal or external. In this case, users could specify whether any repository_urls that aren't found in the repositories list or all purls without repository_urls would default to being designated as internal.

Finally, it would be nice to have more of a warning for possible failures in identifying internal components. If a component is uploaded and its purl is sent to an external repository but doesn't match any packages, that may be a sign that it is an internal component instead. These could result in alerts so that users know which purls aren't being caught, and then can change the regexes identifying internal components. There could also be a button to quickly mark the components causing the alerts as internal.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.