Tag Management

[msymons]

Current Behavior:

Dependency-Track v3.7.1 allows tags to be added to (or removed from) projects by users who have PORTFOLIO_MANAGEMENT permission. This permission includes the ability to create new tags.

• There is no mechanism to limit this ability by project (ie, allow users to change tags on projects 1-10 but not on projects 11-20)
• The only tag-related REST API functionality is the ability to return a list of all projects by tag. There is no ability to query the list of available tags, etc.
• There is no functionality to delete a tag from the system, or to edit existing tags.

Proposed Behavior:

Some items (such as tag deletion and enforcing lower-case) are discussed in #238).

• Add functionality that would allow listing all tags
• Add functionality to allow editing tags. This would be useful when teams change their names or a customer changes their name, etc.
• Allow for tags to be deleted (cleaned up).
• Only allow lower-case tags (this helps avoid duplication)
• Split the permission to create/edit/delete tags from the permission to add/remove tags from a project. I want to restrict the former more than I want to restrict the latter.
• Extending on this, it should be possible to link these permissions to projects, ie, teams A and B and C can change tags on projects 1-20 but team A can only modify tags on 1-10 and team B can only modify tags on 11-20, and team C can modify tags on any project. See restrict access to projects #140, currently in milestone 3.9.
• Enhance UI so that users can pick tags from a list when adding tags to a project.
• Extend functionality to REST so that (say) automated BOM upload from dependency-trak plugin could be enhanced to include tag specification.

[msymons]

Logged JENKINS-61741 to request tag support in Dependency-Track Jenkins plugin.

[sephiroth-j]

It would be great if tags can be created during upload of the bom.

[clemlesne]

This feature would be much appreciated.

[fbuchmeier-abi]

Hi folks,

due to a "misconfiguration" we have around 500k tags in our database. This slows down dependency track considerably. We would like to get rid of all the tags that we do not actually need but cannot seem to find an API endpoint to delete tags.

• Is there any progress on this issue in regards to the deletion of tags?
• Would it be OK to clean up the TAG table in the database manually?

Thanks and best regards,
Florian.

[nscuro]

@fbuchmeier-abi There is currently no one actively working on it AFAIK. As always, contributions would help getting it delivered sooner. :)

Would it be OK to clean up the TAG table in the database manually?

Yes. Just keep in mind that the PROJECTS_TAGS table has a foreign key relationship with the TAG table. As a first step you could try deleting tags whose IDs are not present in the PROJECTS_TAGS table. After that, you likely want to re-wire the remaining relationships, so all projects only have tags that you want to keep.

[rkg-mm]

Looking into this I wonder why
endpoint /v1/tag/{policyUuid} is related to policies. The description "Returns a list of all tags" is misleading as well, as it only returns a list of tags associated with a policy.

In my opinion this should be URL /v1/policy/{policyUuid}/tags instead, so /v1/tag/{name} or /v1/tag/{tagId} can be used to manage tags. However, this would be a breaking change in the API to clean this up. :(

Luckily policies are UUIDs and tags use LONG as id and string as name, so we can identify the difference and offer both. But this should probably be a deprecated legacy support then as it makes the API dirty

[nscuro]

There's a lot in this ticket's description, @msymons any chance we can break out non-MVP things into a separate one? Or break out the MVP functionality, and assign that to v4.12?

For context, we think we need to at least offer an overview of existing tags in v4.12, as tags are being used for more and more aspects of the system. Notification tagging is coming in v4.12, and it will be very hard to keep on top of things without a central place to view and manage tags.

@rkg-mm Agreed on the endpoint oddness. I should've paid more attention there when reviewing the change that brought it in.

[nscuro]

Interesting catch for modification / removal of existing tags:

• Tags are global, whereas project access can be limited via portfolio ACL
• If a user modifies or removes a tag, they might be affecting projects they can't "see"

Similarly, a tag might be used for policies, but the user trying to modify the tag does not have the POLICY_MANAGEMENT permission.

Or the tag might be used for notifications, but the user doesn't have the SYSTEM_CONFIGURATION permission.

In any case, users shouldn't be able to modify tags, if that modification affects things they don't have access to.

Thus, we will need a safety mechanism that prevents mutation of tags if:

• Tagged projects exist, but the user does not have access to all tagged projects
• Tagged policies exist, but the user lacks POLICY_MANAGEMENT permission
• Tagged notifications exist, but the user lacks SYSTEM_CONFIGURATION permission

[nscuro]

Split the permission to create/edit/delete tags from the permission to add/remove tags from a project. I want to restrict the former more than I want to restrict the latter.

That makes sense. So we're talking something like TAG_MANAGEMENT?

Do note that even with that permission, the restrictions I mentioned above should apply I think. Or is the expectation that users with TAG_MANAGEMENT can wreak havoc without additional constraints?

[nscuro]

Add functionality that would allow listing all tags

✅ Implemented in #3881 and DependencyTrack/frontend#922

Allow for tags to be deleted (cleaned up).

✅ Implemented in #3896 and DependencyTrack/frontend#928

Split the permission to create/edit/delete tags from the permission to add/remove tags from a project. I want to restrict the former more than I want to restrict the latter.

✅ A TAG_MANAGEMENT permission was introduced in #3896. At the moment, it is necessary in order to delete tags. Editing of tags is still to-be-implemented.

Creation of tags was historically possible for users with PORTFOLIO_MANAGEMENT permission. If we change that, then that would be a breaking change.

Extending on this, it should be possible to link these permissions to projects, ie, teams A and B and C can change tags on projects 1-20 but team A can only modify tags on 1-10 and team B can only modify tags on 11-20, and team C can modify tags on any project. See #140, currently in milestone 3.9.

✅ #3881 and #3896 were built with portfolio ACL in mind. If ACL is enabled, users can only see tagged projects that they have explicit access to. They can also only untag projects for which this is the case. Trying to delete a tag that is assigned to projects the user doesn't have access to will fail.

Extend functionality to REST so that (say) automated BOM upload from dependency-trak plugin could be enhanced to include tag specification.

✅ Implemented in #3843

[nscuro]

Enhance UI so that users can pick tags from a list when adding tags to a project.

✅ Implemented in DependencyTrack/frontend#936 in the form of auto-completion.

[nscuro]

@msymons Is there anything more beyond what we have lined up in v4.12 that you'd want? I think we addressed the majority of it, to a degree where I'm thinking it might make sense to break out remaining bits into smaller, separate issues. Summary issues like this are hard to track completion of.

[msymons]

Testing in v4.12.1 shows that the Tag Management MVP definitely does help... but does have limitations.

For instance, it does not seem to currently be possible to use the UI to add a tag to projects in bulk. Nor can one rename a tag.

It does make total sense to log anything additional as separate issues as some items might be more useful than others, or easier/harder to implement, etc.