I am thinking to use Taiga as an issue tracker. Since some bugs can be security vulnerabilities, those usually cannot be reported on the issue tracker and have to be set up separately, which makes it so you no longer can have a single source of issues. In addition, there can be bugs arising from private testing, which also cannot be reported on the issue tracker since they can point at secret features. So you end up having three separate sources of issues.
This is probably a pretty complicated request, so it makes sense if this will never appear, anyway. I am thinking of a “scope” system - each issue can have a scope, and each scope can be gated behind some privilege levels (separately for “Read” and “Write”; it isn’t required to have “read” for “write”). For example, anyone can “Write” issues with “security” scope, but only the designated security team can “Read” them (otherwise only the issues you yourself have submitted are visible). In the same way, only private testers can both “Write” and “Read” issues with “testing” scope. You can control these privileges the same way as you control stuff like view_issues etc.
Scopes ideally should be configurable, but that is probably pretty hard to set up. Without that (and instead hardcoding scope names), I was able to hack the solution in like a day (basing on Taiga 6 code) so it’s probably not too hard, and can be considered useful in other scenarios.