Security

For autofix.ci to work, you need to provide autofix.ci's GitHub App with read/write permissions for your repository. Many maintainers are rightfully hesistant to provide such permissions to third parties. We are taking this responsibility very seriously, and have designed autofix.ci with security in mind from the start:

1. autofix.ci has a well-defined threat model in which GitHub Actions runners are treated as completely untrusted and potentially compromised. The autofix.ci API only enables the workflow to update the current pull request once.
2. autofix.ci minimizes untrusted input and data processing where possible. For example, instead of using git checkout/apply/push, we have decided to use GitHub's GraphQL API. This makes it much harder to port autofix.ci to other platforms, but means we only need to process a simple JSON data structure instead of applying git commands on untrusted repositories (see e.g. CVE-2021-21300).
3. autofix.ci's hosted service is written in a memory-safe language that emphasizes correctness (Rust).
4. autofix.ci's main author has extensive practical (building security software, organizing and playing CTF security competitions) and theoretical security experience (CS PhD from a security group).

Why does the workflow name have to be "autofix.ci"?

Consider a repository with two workflows: autofix.ci and compromised_workflow. We have an attacker that can execute code in compromised_workflow. However, this workflow is locked down to permissions: {contents: read}.

If arbitrary workflow names were allowed, the attacker could upload an "autofix.ci" artifact from the compromised workflow, and then manually call the autofix API. This privilege escalation path is mitigated by requiring that the artifact is upload from a specific workflow.

The server-side check is repeated in the action's code to provide immediate feedback.

What does the GitHub App request permissions for?

contents:write

This permission is necessary to push the fix commit.

actions:write

This permission is used to cancel all other workflows associated with a commit when fixing it (configurable via the fail-fast option in action.yml).

pull-requests:write

This permissions is used to add comments to pull requests. autofix.ci uses comments to inform external contributors that their PR needs fixing if they did not enable the "allow edits by maintainers" option.

checks:write

This permission is used to add commit statuses. When autofix.ci fails to fix a branch (for example due to branch protection rules), it creates a commit status with an explanation.

metadata:read

This permissions is mandatory for all GitHub Apps.

Reporting a Vulnerability

We ask that you do not report security issues to our normal GitHub issue tracker. If you believe you've identified a security issue with autofix.ci, please report it to securitynoreply@test@autofix.ci.

Once you've submitted an issue via email, you should receive an acknowledgment within 48 hours, and depending on the action to be taken, you may receive further follow-up emails.

Bug Bounty

For the responsible disclosure of critical vulnerabilities that could compromise the integrity or confidentiality of our users' GitHub repositories, autofix.ci pays a bug bounty of up to one month of autofix.ci's total revenue.

We will not bind you to any additional terms or have you sign an NDA when you report a vulnerability. However, bounty payments, if any, will be determined by autofix.ci, in autofix.ci's sole discretion. In no event shall autofix.ci be obligated to pay you a bounty for any submission. If you are unhappy with how autofix.ci is handling the disclosure process, you may walk away at any moment and publish your findings (but not any sensitive data you may have had access to) in the public.