Auto GitHub issue to track report

[splitbrain]

Currently I get an email about new reports (not sure where that mail comes from - might be my public github address?). I would prefer if huntr would:

• automatically open an issue in the affected repository (one per report)
• link between the report and issue (both ways)
• initially keep the issue vague
  • the title should contain the severity, but not the actual issue
  • the body should just have some intro text and the link to the report
• once the report has been made public the issue should be auto-updated, changing the text and subject to the original report

I'd be okay with having to enable that behaviour in a user setting on hunter.dev if needed.

[tomaarsen]

I see some issues with this. Security vulnerabilities should be hidden from the eyes of potential malicious actors, and shown exclusively to the maintainers of the product. I recognise that you try to tackle this by omitting the true report, but even notifying users that there is an active vulnerability before it can be resolved is risky. Beyond that, I'm unsure how you would support a link to the report, considering only the maintainers ought to be able to see this report (until it's made public after a fix)

I believe the email is taken from a SECURITY.md file, if such a file exists.

[jaapmarcus]

I totally agree I prefer contact to be made privately instead public. For an simple XSS / CSFR token *** it might not hurt but for the more serious zero day / RCE or code injection it might cause a lot of issues...

[splitbrain]

Well, development is coordinated via github issues. Before I fix a vulnerability I need to have an issue ID to reference in my commit anyway. Currently I have to do all the steps above manually. Being able to opt into a more automated workflow would make it easier for me as a maintainer.

[tomaarsen]

You have an argument there, for sure: Pull requests are also public, and will appear before a report has been made public (unless you use GitHub's Security tab, which allows you to discuss security vulnerabilities within only the core team, and create hidden branches, but outside users don't have access to this, meaning that the reporter cannot contribute to such a hidden branch.)

[RCheesley]

I would like to see the following:

• Issue is validated by maintainer
• Maintainer is prompted to create a GitHub Advisory, transferring all the data from the report on Huntr to the advisory
• Maintainer is prompted to create the private fork where work can be done to address the vulnerability and discussions can happen in private (option to add the reporter)
• PR/s are approved in the private fork = fix is accepted in Huntr
• PR/s are merged into the main repo (eg the fix is released and advisory is published), maintainer is prompted to make the Huntr report public

This would give a private, secure area to discuss the issue once it has been validated, you could even maybe keep it in sync with the activity on Huntr. Reporters can be added as a collaborator without having to be in your team, so that also gets around the other issues raised.

It's a really nice system, we transitioned over to it last year and it has definitely improved our security workflows, but the Huntr -> advisory stuff is all manual at this time.

[JamieSlome]

Nice ideas @RCheesley - we have certainly seen maintainers talking about being able to do fix work, i.e. git commits under private repositories, just to really ensure that any vulnerability intelligence is not shared prior to publication.

I will follow up with the team tomorrow, to see if we can share a status update and further thoughts here, but we do recognize this and understand your requirements here ❤️

I am sure @psmoros will follow up with his thoughts shortly too!

[RCheesley]

Yeah, the GitHub private forks feature of advisories is really nice to work work with, the only down side is that it does not allow you to run your GitHub Actions / CI/CD workflows. So we have to make the PRs against both the private fork, and a completely separate private repository which is a mirror of our public repo where we run our unit tests and the like. So it's not perfect but it does solve a lot of problems.

[psmoros]

Also #2188