Some initial tests with Conduit enpoints
Pulling the Phabricator ID (PHID) of all tags starting with the Vuln- keyword:

curl https://phabricator.wikimedia.org/api/project.search \
    -d api.token=api-token \
    -d constraints[name]=Vuln-

Fetching some tasks marked with the Vuln-CSRF tag:

curl https://phabricator.wikimedia.org/api/maniphest.search \
    -d api.token=api-token \
    -d constraints[projects][0]=PHID-PROJ-iqbim6pzco5gjtkkf377 \
    -d limit=3

A few thoughts:

1. Is there a reason this task can't be public? Some of the relevant data concerning this project might be sensitive, but Phabricator should keep that information secure from public audiences. For example, if I reference a protected security bug (T268377), Phabricator should hide that effectively within a public view.
2. The Vuln- tags should be relatively up-to-date, though there may be a few we'd want to add and some could potentially have their descriptions updated.
3. Regarding the technical stack - I'd imagine wmcs would be the likely hosting environment? We do have a couple of existing, security-related cloud instances (see here) and there are at least a couple (1. 2) of security-related toolforge projects.
4. I would imagine for this dashboard to offer the most value, it would need to be able to robustly filter data on a project, team, user, date/time and risk level. Some of that data is available via Phabricator as part of the task, but some (especially team ownership and risk) is not, at least not at the moment.

Hey @sbassett,
Thanks for chiming in.

Is there a reason this task can't be public?  Some of the relevant data concerning this project might be sensitive, but Phabricator should keep that information secure from public audiences.  For example, if I reference a protected security bug (T268377), Phabricator should hide that effectively within a public view.

Honestly, I just erred on the side of caution and made it non-public from the beginning. I'm glad to make it public if there are not strong objections.

The `Vuln-` tags should be relatively up-to-date, though there may be a few we'd want to add and some could potentially have their descriptions updated.

Well noted, those additional tags can certainly be include them as well. Do you have other relevant tags in mind at the moment?

Regarding the technical stack - I'd imagine wmcs would be the likely hosting environment?  We do have a couple of existing, security-related cloud instances ([[ https://office.wikimedia.org/wiki/Wikimedia_Security_Team/Cloud_VPS_instance_(security-tools) | see here ]]) and there are at least a couple ([[ https://admin.toolforge.org/tool/security-tools | 1 ]]. [[ https://admin.toolforge.org/tool/security | 2 ]]) of security-related toolforge projects.

Thanks for pointing out those valuable links. Having already hosted a few stuffs on toolforge in the past, I'd like to explore the security-related instances, especially if that means that anybody with a toolforge access won't just be able to login, cd into our repository, and access any sensitive things. I'll explore the documentation and keep it in mind when the time to deploy it comes.

I would imagine for this dashboard to offer the most value, it would need to be able to robustly filter data on a project, team, user, date/time and risk level.  Some of that data is available via Phabricator as part of the task, but some (especially team ownership and risk) is not, at least not at the moment.

Yes, you're right. For the metadata such as team, user, date time, etc, I don't think it would be a big deal. However, for the risk and ownership, I think it's a different story. That's something I've surfaced with John too but in all fairness, I think those will probably be the most challenging parts. For example, mapping the severity level with our internal taxonomy, defining who owns the vulnerability, who is responsible for addressing it; those will need thorough discussions.

In T279140#6968080, @sguebo_WMF wrote:

Honestly, I just erred on the side of caution and made it non-public from the beginning. I'm glad to make it public if there are not strong objections.

For now, I think we can make this public. If it becomes necessary to include sensitive data here, directly within the task, we can always protect it again.

Well noted, those additional tags can certainly be include them as well. Do you have other relevant tags in mind at the moment?

I believe all of the existing Vuln- projects are captured within this search: https://phabricator.wikimedia.org/search/query/kTp2IDCjmIzN/#R. We'd likely want to include all of these within this dashboard, even if a handful are very rarely used. Looking over the last couple of quarters, Vuln-XSS (search) and Vuln-Infoleak (search) have the most associated tasks, so they should definitely be included. Vuln-Misconfiguration also has a decent number of associated tasks (search), though IME, that category is used for misconfigurations as well as a glob for other vulnerabilities that do not neatly fit into a different Vuln- category.

For now, I think we can make this public. If it becomes necessary to include sensitive data here, directly within the task, we can always protect it again.

Thanks for updating the task.

I believe all of the existing Vuln- projects are captured within this search: https://phabricator.wikimedia.org/search/query/kTp2IDCjmIzN/#R. We'd likely want to include all of these within this dashboard, even if a handful are very rarely used. Looking over the last couple of quarters, Vuln-XSS (search) and Vuln-Infoleak (search) have the most associated tasks, so they should definitely be included. Vuln-Misconfiguration also has a decent number of associated tasks (search), though IME, that category is used for misconfigurations as well as a glob for other vulnerabilities that do not neatly fit into a different Vuln- category.

I see, then it's fine since I was able to collect all the existing tags from the Conduit API as well using the Vuln- prefix.

curl https://phabricator.wikimedia.org/api/project.search \
    -d api.token=api-token \
    -d constraints[name]=Vuln-

Said that I'll keep the query you've mentioned earlier and double check later.

In T279140#6968184, @sguebo_WMF wrote:

I see, then it's fine since I was able to collect all the existing tags from the Conduit API as well using the Vuln- prefix.

Sounds good. Not sure if you're using personal API tokens for this, tied to your Phab account, but we probably shouldn't do that. We do have a bot though we'd likely need to recover credentials for that and add you and maybe @Reedy and myself as maintainers.

In T279140#6968192, @sbassett wrote:

In T279140#6968184, @sguebo_WMF wrote:

I see, then it's fine since I was able to collect all the existing tags from the Conduit API as well using the Vuln- prefix.

Sounds good. Not sure if you're using personal API tokens for this, tied to your Phab account, but we probably shouldn't do that. We do have a bot though we'd likely need to recover credentials for that and add you and maybe @Reedy and myself as maintainers.

Nice catch! I am using a token linked to my account. I'd be grateful if I could be given the relevant bot's credentials and added as a maintainer. Let me know if there's anything I need to do for that.

In T279140#6968315, @sguebo_WMF wrote:

Nice catch! I am using a token linked to my account. I'd be grateful if I could be given the relevant bot's credentials and added as a maintainer. Let me know if there's anything I need to do for that.

Sadly, I'm not certain if anyone on our team has access to manage this bot right now. That would likely involve a new task/request tagged with Phabricator and/or Phabricator-Bot-Requests to gain access. @Reedy might have the ability to make such changes, though I am not certain.

FWIW, I used https://github.com/disqus/python-phabricator for some stuff like that before (incase you hadn't found it). I think other random tooling uses it too

https://github.com/wikimedia/mediawiki-tools-release/blob/master/make-security-tasks/makesecuritytasks.py (it's nothing fancy)

@security_team_bot is the bot. I don't think there's an easy way to give "access" beyond you having full phab admin access. But I am able to create a conduit token for it, and pass that to you somewhere directly, that's not an issue.

See T265923: Reclaim @security_team_bot for some discussion around that before

Ah, now I remember T265923, and how frustrating Phabricator's complete lack of collective bot ownership is. I suppose the best we can do is have @Reedy grab the api token and keep it safe within our team vault.

Thanks @Reedy, I intend to use the Phabricator's Python library since it's pretty straightforward.
I guess I can grab the token with you once you've gotten the chance to create it.

I completed a prototype with basic filtering options. For now, one can filter by project (tag), year when the ticket was created, and severity. The code base is available at https://github.com/samuelguebo/vm-dashboard. It's public for now since there are no credentials or sensitive data there but I'm glad to make it private if there are any objections.

Change 678054 had a related patch set uploaded (by Samuel (WMF); author: Samuel (WMF)):

[wikimedia/security/vm-dashboard@master] [MINOR] Initial commit

https://gerrit.wikimedia.org/r/678054

Change 678072 had a related patch set uploaded (by Samuel (WMF); author: Samuel (WMF)):

[wikimedia/security/vm-dashboard@master] [MINOR] Change occurences of Project into Vulnerability

https://gerrit.wikimedia.org/r/678072