Securefix Action

| Versioning Policy | NotebookLM

Securefix Action is GitHub Actions to fix code securely.

Securefix Action allows you to fix code securely without sharing a GitHub App private key with strong permissions such as contents:write across GitHub Actions workflows. You don't need to allow external services to access your code. It elevates the security of your workflows to the next level.

Furthermore, it's easy to use. You don't need to host a server application. It achieves a server/client architecture using GitHub Actions by unique approach.

:bulb: NotebookLM And DeepWiki

• Google NotebookLM
• DeepWiki

:rocket: Recent Important Updates

• v0.5.6 (2026-03)
  • :bug: Fix a bug that client fails when some files are deleted
  • 💪 Support passing custom parameters from client to server to customize server workflow
• :bug: v0.5.5 (2026-02) Fix a bug that Git Submodules are broken
• :warning: v0.5.3 (2026-01) pull_request.base_branches in configuration files were abandoned
• 💪 v0.4.2 (2025-12) You can write Configuration files more simply
• :rocket: v0.4.1 (2025-11) The performance was drastically improved
• :warning: v0.3.0 (2025-10) If the repository or branch is changed, the source branch must be protected for security.

See also Release Notes.

Features

• 💪 Increase the developer productivity by fixing code in CI
• 🛡 Secure
  • You don't need to pass a GitHub App private key with strong permissions to GitHub Actions workflows on the client side
  • You don't need to allow external services to access your code
  • You can define custom validation before creating a commit
  • Commits are verified (signed)
• 😊 Easy to use
  • You can create a commit by one action on the client side
  • You don't need to host a server application

Overview

Sometimes you want to fix code in CI:

• Format code
• Generate document from code
• etc

In case of public repositories, we strongly recommend autofix.ci. autofix.ci allows you to fix code in CI of pull requests including pull requests from fork repositories securely. autofix.ci is easy to use, and it's free in public repositories. We love it.

autofix.ci is also available in private repositories, but perhaps it's a bit hard to use it in your private repositories for your business.

• It's not free, so you may have to submit a request to your company
• You need to allow the external server of autofix.ci to access your code. Perhaps you can't accept it
• If you don't receive pull requests from fork repositories, the reason to use autofix.ci might not be so string because you can fix code using actions such as commit-action

We think autofix.ci is valuable in private repositories too, but perhaps you can't use it.

If you use fix code in CI, you need to use an access token with contents:write permission. But if the token is abused, malicious code can be committed. For instance, an attacker can create a malicious commit to a pull request, and he may be able to approve and merge the pull request. It's so dangerous.

To prevent such a threat, you should protect personal access tokens and GitHub Apps having strong permissions securely.

One solution is the Client/Server Model. Clients are GitHub Actions workflows that want to fix code. They send a request to the server, then the server fix code. You don't need to pass an access token with strong permissions to clients (GitHub Actions Workflows).

Then how do you build the server? For instance, you would be able to build the server using AWS Lambda, Google Cloud Function, or k8s, and so on. But we don't want to host such a server application.

So we build a server using GitHub Actions workflow by unique approach. You don't need to host a server application.

Example

• demo-server: workflow
• demo-client: workflow

Architecture

Securefix Action adopts the Client/Server Model. It uses following GitHub Apps, repositories, and workflows:

• two GitHub Apps
  • a Server GitHub App: a GitHub App to create commits
  • a Client GitHub App: a GitHub App to send requests to a server workflow
• Repositories
  • a Server repository: a repository where a server workflow works
  • Client repositories: repositories where client workflows work
• Workflows
  • a Server Workflow: Receive requests from client workflows and create commits
  • a Client Workflow: Request to fix code to the Server Workflow

• Server: 1 GitHub App, 1 Repository
• Client: 1 GitHub App, N Repositories

1. The client workflow uploads fixed files and metadata to GitHub Actions Artifacts
2. The client workflow creates an issue label to the server repository
3. The server workflow is triggered by label:created event
4. The server workflow deletes the issue label
5. The server workflow downloads fixed files and metadata from GitHub Actions Artifacts
6. The server workflow validates the request
7. The server workflow pushes a commit to the client repository

:bulb: Why are labels used?

Securefix Action uses label event to trigger a server workflow. Generally repository_dispatch events are used to trigger workflows by API, but they require the permission actions:write. actions:write permissions is strong and dangerous, so we don't want to grant the permission. So we looked for alternative events from all events, and we found label event. Even if the permission is abused, the risk is low.

Getting Started

1. Create two repositories from templates demo-server and demo-client
2. Create a GitHub App for server
3. Create a GitHub App for client
4. Create GitHub App private keys
5. Add GitHub App's id and private keys to GitHub Secrets and Variables
6. Fix the server workflow if necessary
7. Fix the client workflow if necessary
8. Add a new file bar.yaml to client' repository and create a pull request

GitHub App for server

Deactivate Webhook.

Permissions:

• contents:write: To create commits
• actions:read: To download GitHub Actions Artifacts to fix code
• pull_requests:write: To notify problems on the server side to pull requests
• workflows:write: Optional. This is required if you want to fix GitHub Actions workflows
• members:read: Optional. This is required if you want to request reviews to teams
• Organization's projects:write: Optional. This is required if you want to add pull requests to GitHub Organization Projects

Installed Repositories: Install the app into the server repository and client repositories.

GitHub App for client

Deactivate Webhook.

Permissions:

• issues:write: To create labels

Installed Repositories: Install the app into the server repository and client repositories.

Add GitHub App's id and private keys to GitHub Secrets and Variables

Add GitHub App's private keys and ID to Repository Secrets and Variables

• client
  • id: client repository's variable DEMO_CLIENT_APP_ID
  • private key: client repository's Repository Secret DEMO_CLIENT_PRIVATE_KEY
• server
  • id: server repository's variable DEMO_SERVER_APP_ID
  • private key: server repository's Repository Secret DEMO_SERVER_PRIVATE_KEY

[!WARNING] In the getting started, we add private keys to Repository Secrets simply. But when you use Securefix Action actually, you must manage the Server GitHub App's private key and the server workflow securely. Only the server workflow must be able to access the server app's private key. See also How to manage a server GitHub App and a server workflow.

Fix the server workflow if necessary

Workflow

If you change a variable name and a secret name, please fix the workflow.

Fix the client workflow if necessary

Workflow

• If you change a variable name and a secret name, please fix the workflow
• If you change the server repository name, please fix the input server_repository

Add a new file bar.yaml to client' repository and create a pull request

1. Add bar.yaml to client repository (Example)

bar.yaml:

names:
  - bar

2. Create a pull request (Example):

Then workflows are run and bar.yaml is fixed automatically:

commit

--- a/bar.yaml
+++ b/bar.yaml
@@ -1,2 +1,2 @@
 names:
-- bar
+  - bar

Push to other repository and branch

Securefix Action >= v0.2.0 #123

By default, Securefix Action pushes a commit to the repository and branch where the action is run. But actually there are usecases that you want to push a commit to other repository and branch.

• Scaffold a pull request by workflow_dispatch
• Update GitHub Pages
• Create a pull request to the repository A when the repository B is updated
• etc

Securefix Action can push a commit to the other repository and branch securely. Allowing to push any repository and branch without any restriction is dangerous, so by default changing the repository and branch isn't allowed, meaning the action fails. You can push a commit from only allowed repositories and branches to only allowed repositories and branches. From Securefix Action v0.3.0, the source branch must be protected.

1. Configure the server side
2. Configure the client side

Create pull requests

When pushing a commit to the other repository and branch, you can also create a pull request.

1. Configure the server side
2. Configure the client side

Actions

Securefix Action is a single JavaScript Action. It has an input action, which accepts the following values:

• client: Client Action
• server: Server Action
  • prepare: Prepare for creating commits
  • commit: Create commits
  • notify: Notify the failure to the client side
• validate-config: Validate the configuration file of the server side

The server action is a single action that consolidates the prepare, commit, and notify actions. In most cases, you can simply use the server action.

If you need more flexibility, you can use the individual prepare, commit, and notify actions instead. For example, you can insert your own validation logic between prepare and commit, or implement custom notification handling instead of using the default notify action.

Actions' Available Versions

As of Securefix Action v0.2.0, Securefix Action is released using release-js-action. About available versions, please see the document.

Security

• You don't need to pass a GitHub App private key having strong permissions to GitHub Actions workflows on the client side
• You don't need to allow external services to access your code
• You can define custom validation before creating a commit
• Commits are verified (signed)

Client workflows can use a Client GitHub App, but it has only issues:write permission. Even if the app is abused, the risk is low. Server action creates a commit to the same repository and branch with the GitHub Actions Artifact. So it doesn't allow attackers to create a malicious commit to a different repository or a different branch.

How to manage a server GitHub App and a server workflow

You must protect a server GitHub App and a server workflow from attacks securely. There are several ideas:

• GitHub App Private Key:
  • Use GitHub Environment Secret
    • Restrict the branch
  • Use a secret manager such as AWS Secrets Manager and restrict the access by OIDC claims (repository, event, branch, workflow, etc)
• Server Workflow
  • Restrict members having the write permission of the server repository
    • For instance, grant the write permission to only system administrators

Custom Validation

You can insert custom validation between prepare action and commit action. You can use prepare action's outputs.

- uses: csm-actions/securefix-action@latest
  id: prepare
  with:
    action: prepare
    app_id: ${{ vars.DEMO_SERVER_APP_ID }}
    app_private_key: ${{ secrets.DEMO_SERVER_PRIVATE_KEY }}
# Custom Validation
- if: fromJson(steps.prepare.outputs.pull_request).user.login != 'suzuki-shunsuke'
  run: |
    exit 1
- uses: csm-actions/securefix-action@latest
  with:
    action: commit
    outputs: ${{ toJson(steps.prepare.outputs) }}
- uses: csm-actions/securefix-action@latest
  if: failure()
  with:
    action: notify
    outputs: ${{ toJson(steps.prepare.outputs) }}

Troubleshooting

• Error: No matching entry found in the config for the given repository and branch.

Client Workflow Name

By default, the client workflow name must be securefix for security. Otherwise, the prepare action fails. You can change the workflow name or remove the restriction using prepare action's workflow_name input.

How To Fix Workflow Files

By default, Serverfix Action doesn't allow you to fix workflow files for security. By default, the server action fails if fixed files include workflow files. You can allow it by setting prepare action's allow_workflow_fix to true.

GitHub API Rate Limiting

If you use Server Action in many client repositories and face GitHub API limiting, you can avoid the rate limiting by creating new GitHub Apps and a server repository and splitting clients:

Reference:

• Rate Limit of REST API
• Rate Limit of GraphQL API