Fixes, right in your
pull requests.
One workflow file. Railo finds security issues in each pull request and suggests the fix on the line, ready to commit. It runs in your own CI.
Setup
One file. That is the install.
- 1
Add the file.
Commit it as .github/workflows/railo.yml. It uses the GitHub token every workflow already has.
- 2
Open a pull request.
Railo scans the changed files on your runner and writes the fixes it knows.
- 3
Commit the suggestion.
Each fix appears on the changed line. One click applies it, as the reviewer.
This is warn mode: suggestions on the pull request. Set mode: enforce and grant contents: write to get a separate fix pull request instead.
name: Railo
on:
pull_request:
types: [opened, synchronize, reopened]
permissions:
contents: read
pull-requests: write
checks: write
security-events: write
jobs:
railo:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ github.head_ref }}
fetch-depth: 0
persist-credentials: false
- uses: IWEBai/railo-action@v2
with:
mode: warn
On the pull request
Your reviewer clicks once.
Railo uses GitHub's own suggested changes. The fix lands as a normal commit by the person who accepted it.
github-actions bot
on app/users.py, line 6
SQL injection (CWE-89), line 6. Rescanned after the fix: the finding is gone and nothing new appeared.
Nothing is pushed until someone clicks.
Built to be let into your CI.
Runs on your runner.
Scanning and fixing happen inside your GitHub Actions job. Your source code is not sent to Railo. A usage ping carries the repository name, mode and counts; set RAILO_TELEMETRY=0 to turn it off.
Only the workflow token.
No app to install and no personal token. The workflow's own GITHUB_TOKEN, with the permissions written in the file, is all it uses.
Checked before you see it.
Every fix is rescanned: the finding must be gone and nothing new may appear. It also tries your test command before and after each fix and drops one that adds a failure; your own CI on the change is still the real test.
Already have a backlog?
The Action fixes what new pull requests introduce. A Fix Sprint clears what is already there: every finding fixed or explained in one week, with the evidence to show for it.
