I've been running Code Pathfinder on the Code Pathfinder repo itself for a while. Which sounds circular, but it's genuinely useful. You find the rough edges fast when you're both the person writing the tool and the person using it on real code.
The way I'd been doing it: run the scanner locally before pushing, check the output, fix what needs fixing. That worked. But there's always that gap. You merge a PR, something slips through, and you only catch it on the next manual run.
So last week I wired it up properly. The code-pathfinder GitHub Action now scans on every pull request and posts findings directly in the PR. No more running locally and hoping you didn't miss anything before merging.
Two things happen when a scan runs on a PR:
A summary comment appears: a table of all findings, grouped by severity. If the scan comes up clean, it says so. Critical and high findings are easy to spot without scrolling through CI logs.
Inline review comments show up on the exact lines where critical and high severity issues were found, the same way a human reviewer would leave feedback. You see the rule name, a short description, and the specific line.
Both are opt-in. Two new inputs: pr-comment and pr-inline, both false by default, so nothing changes for existing workflows.
Getting started
Add the action to your repository at .github/workflows/security-scan.yml. Pick the rulesets that match your stack from the Code Pathfinder rules registry and drop them into the ruleset input:
name: Security Scan on: pull_request: branches: [main, master] permissions: security-events: write contents: read pull-requests: write # required for PR comments jobs: security-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: fetch-depth: 0 # required for diff-aware scanning - name: Run Security Scan uses: shivasurya/code-pathfinder@v1.3.6 with: ruleset: >- python/deserialization, python/django, python/flask, docker/security, docker/best-practice project: . verbose: true pr-comment: ${{ github.event_name == 'pull_request' }} pr-inline: ${{ github.event_name == 'pull_request' }} github-token: ${{ secrets.GITHUB_TOKEN }} - name: Upload SARIF to GitHub Security uses: github/codeql-action/upload-sarif@v4 if: always() with: sarif_file: pathfinder-results.sarif
A quick note on fetch-depth: 0. Without full git history, diff-aware scanning can't figure out which files changed in the PR, so it falls back to scanning everything.
The pull-requests: write permission is what lets the action post comments. The SARIF upload part works independently, so you can use both at once or either one on its own. Code Pathfinder also works with GitLab CI and Azure DevOps if you're not on GitHub.
All configuration options
| Input | Default | Description |
|---|---|---|
| ruleset | Remote ruleset(s) to use, comma-separated. Browse available rulesets at codepathfinder.dev/registry | |
| rules | Path to a local rules file or directory | |
| project | . | Path to the source code to scan |
| output | sarif | Output format: sarif, json, or csv |
| output-file | pathfinder-results.sarif | Output file path |
| fail-on | Exit with code 1 if findings match given severities (e.g. critical,high) | |
| verbose | false | Enable verbose output |
| skip-tests | true | Skip scanning test files |
| no-diff | false | Scan all files instead of only changed files |
| refresh-rules | false | Force refresh cached rulesets |
| debug | false | Enable debug diagnostics with timestamps |
| disable-metrics | false | Disable anonymous usage metrics |
| pr-comment | false | Post a summary comment on the PR with scan results |
| pr-inline | false | Post inline review comments for critical/high findings |
| github-token | GitHub token for posting comments (required when pr-comment or pr-inline is enabled) |
GHAS or just PR comments, there's a real choice here
Code Pathfinder works with GitHub's Code Scanning (the thing formerly known as GHAS, now called GitHub Code Security). It also has its own native PR commenting that doesn't touch any of that.
The SARIF upload path, using github/codeql-action/upload-sarif, sends findings to the Security tab where they're tracked over time and show up in the PR checks UI. If your team already lives in the Security tab, this is the cleaner long-term path.
The native PR comments path posts findings as plain PR comments and inline review annotations. No GitHub Advanced Security subscription needed. Works on any public repo, any plan. I've found this more immediately useful day-to-day. The findings are right there in the code review conversation, not one more tab to open.
You can do both. They're independent and don't conflict.
Security rules registry
The Code Pathfinder rules registry is where the available rulesets live. You can browse and preview rules before pulling them into a workflow. Right now it covers:
- python/deserialization: unsafe deserialization patterns in Python
- python/django: Django-specific security misconfigurations
- python/flask: Flask-specific security issues
- docker/security: Dockerfile misconfigurations covering privilege escalation, socket exposure, and the usual suspects. The Docker security rules post goes deep on what each one actually catches.
- docker/best-practice: Dockerfile best practices
Every ruleset is open source. If you want to write rules or poke at the existing ones, it's all on GitHub.
Give it a try
If you add it to your repo and something doesn't work right, or works but in a way that's subtly wrong, I'd genuinely like to know. Open an issue or start a discussion on the GitHub repo. Not as a formality. The project is still early and real usage is how I figure out what to fix next.
Related reading
- GitHub Actions integration docs — full reference for every input and output
- GitLab CI integration and Azure DevOps integration — if you're not on GitHub
- Docker security rules: 47 container vulnerability checks — the docker/security and docker/best-practice rulesets in detail
- Reducing SAST false positives — how to tune findings so PR comments stay actionable