Implementing GitHub’s private security issue reporting

Implementing GitHub’s private security issue reporting FOSS Backstage Berlin, 10-11 March 2025 @RCheesley

Ruth Cheesley (she/her) Mautic Project Lead & Co-Founder, Women of Open Source community ruth.cheesley@mau c.org speaking.ruthcheesley.co.uk for slides, recording, links and resources ti @RCheesley

Centralising the process of working on security issues. We used this system to: • Receive private security reports from researchers • Centralise all communication between researcher, security team and marketing team on xing and disclosure • Pay micro bounties from their $100 per project fi pot to researchers and developers

Our security reporting process at that time: The tool did the majority of the secure communication, prioritisation, and organisation of our incoming security issue reports - in effect it was our ‘issue queue’ for security issues

18th October, 2023: Our security reporting tool closes to non-AI/ML Rather unexpected news! • 6 weeks to nd a new system for our security issue collaboration • Needed to transfer all our publicised security issues too, as we wouldn’t be able to make any edits after that date • Opportunity to revisit what our security team - fl fi and our wider ecosystem - actually needed from our security reporting work ows

We had some frustrations with our existing processes, though! • Couldn’t easily collaborate on xes directly in the code (e.g. with PRs) with the researchers • Very minimal information provided in reports about the vulnerability • Juggling 3 systems - Jira, Huntr and GitHub • Multi-version xes were a real pain to manage and release - lots of manual work! • There was no central list of security advisories fi fi that had previously been released

Possible solution: GitHub Security Advisories? A new feature: allowing the public to securely and privately report vulnerabilities with a repository directly, as a draft security advisory for the team to review.

Creates a triage backlog for the team to review. Allows reviewing and triaging, accepting or rejecting the report based on whether it meets the policies of the project. We could also generate our own advisories directly.

Users create a draft advisory to report issues. • Requests a minimum dataset from the reporter, and associates them as the reporter for crediting • Secure, private place for collaboration with familiar work ows and team-based permissions • Allows the requesting of a CVE via GitHub, or assigning an existing CVE ID • Comments in the advisory are never made fl public - only the content of the advisory itself

Maintainers can decide whether to accept the reported advisory, or close it. Can it be reproduced? Is it in line with our security policy?

Collaborate on a private fork with access controlled via the security advisory. fi Enables any contributor to be given access to this fork via the advisory, so that they can work on/review the proposed xes.

Exact same process as making a PR in your main repository, but done privately. Collaborators clone the private fork, create a branch, and PR their changes as they normally would, which then shows in the advisory.

Merge all PRs relating to the advisory with a single click! PRs on advisories are merged all at once, by clicking one button - this merges the commits directly to the branch in your main repository.

Single squashed commit shows in your commit history. fi Once the advisory is published (when you’ve released the x) the commits link back to the original advisory, closing the loop for people checking the commit history.

Ensure that everyone involved in the security issue is credited on the advisory. It takes a village … with the GitHub Advisories you can recognise that by crediting everybody involved, even tools and sponsors.

Dependabot alerts automatically inform repositories which have your project as a dependency. A PR is provided to bump the version to the patched release, alerts show on the advisory itself in a separate tab.

https://mau.tc/github-advisories

Our current reporting process: Users now report security issues as a draft advisory, streamlining the process for them and for our security team. We maintain Jira as a private space for the team to collaborate.

With GitHub Advisories we can now … • Have a centralised location for all things security • Invite contributors to work on xes themselves, rather than have to do all the work ourselves • Ensure that reports contain the minimum set of information required for CVE submission • Simplify the merging of security xes affecting fi fi multiple branches with a ‘one click merge’

GitHub Advisories solved 95% of our pain points, except … • You can’t (currently) run your GitHub Actions on a private fork in GitHub • Merging multiple advisories in one release is still very time consuming due to the need to run automated tests after each is merged • You can’t auto-assign a team to access every new advisory, only admins get access by default • Requesting/updating CVEs is manual for CNAs • You can’t PR to a different repo (e.g. an extended long term support private repo) from an advisory, only the main public repo - still some manual git-fu needed.

Ruth Cheesley (she/her) What questions can I answer? ruth.cheesley@mau c.org speaking.ruthcheesley.co.uk for slides, recording, links and resources ti @RCheesley