• Agents
  • Docs
  • Pricing
  • Blog
Log in
Get started

Security for apps built with AI. Paste a URL, get a report, fix what matters.

Product

  • How it works
  • What we find
  • Pricing
  • Agents
  • MCP Server
  • CLI
  • GitHub Action

Resources

  • Blog
  • Docs
  • FAQ
  • Glossary

Security

  • Supabase Security
  • Next.js Security
  • Lovable Security
  • Cursor Security
  • Bolt Security

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Imprint
© 2026 Flowpatrol. All rights reserved.
Back to Blog
Product

Security Checks on Every Pull Request

Introducing the Flowpatrol GitHub Action — scan every PR for vulnerabilities, post findings as comments, output SARIF for Code Scanning, and gate merges by severity.

Flowpatrol TeamMar 31, 20267 min read
Security Checks on Every Pull Request

You're shipping fast. Your CI should keep up.

Three PRs before lunch. A new feature branch after every standup. Maybe you're building alone, maybe you've got a small team — either way, the pace is real. Lovable deploys a preview on every push. Vercel gives you a URL in seconds. The code ships as fast as you can write the prompt.

But here's the thing nobody talks about: every PR is a chance to introduce a security issue. A new API route without auth. An RLS policy you forgot to add. An environment variable that ended up in the client bundle. Not because you're careless — because you're moving fast and nobody's checking.

What if your CI pipeline checked for you? What if every pull request got scanned the same way you'd scan before launch — automatically, in the background, before anyone clicks "merge"?

That's what the Flowpatrol GitHub Action does. One file in your repo. Every PR gets scanned. Findings show up right in the pull request. Done.


One file, done

Add this workflow to your repo. That's the entire setup.

name: Security Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: flowpatrol/scan-action@v1
        with:
          target-url: https://staging.myapp.com
          api-key: ${{ secrets.FLOWPATROL_API_KEY }}

Point target-url at your preview deployment. If you're on Vercel, Netlify, or Lovable, you already have preview URLs for every PR. Use the preview URL pattern your platform gives you — the action supports dynamic URLs via environment variables too.

Store your API key in GitHub Secrets. That's one trip to your repo settings. Then forget about it.

Every time someone opens a PR, the action runs a scan against the live preview. No configuration files. No rule definitions. No YAML sprawl. It just works.

A GitHub Actions workflow diagram showing a pull request triggering a Flowpatrol scan that posts results back as a PR comment


What happens when a PR opens

Here's the sequence, start to finish:

  1. Someone opens a pull request
  2. Your platform deploys a preview (Vercel, Netlify, Lovable — whatever you use)
  3. The Flowpatrol action starts a scan against that preview URL
  4. Findings come back in a few minutes
  5. The action posts a comment on the PR with everything it found
  6. If findings cross your threshold, the check fails — the PR can't merge

No context switching. No separate dashboard to check. The findings are right there in the PR, where you're already looking.

Here's what the PR comment looks like:

## Flowpatrol Scan Results

**3 findings** across your application

| Severity | Finding | Location |
|----------|---------|----------|
| Critical | Missing Row Level Security on `orders` table | `/api/orders` |
| High | IDOR — user can access other users' orders by changing ID | `GET /api/orders/:id` |
| Medium | Missing rate limiting on login endpoint | `POST /api/auth/login` |

### Critical: Missing Row Level Security on `orders` table

The `orders` table has RLS disabled. Any authenticated user can read all rows
via the Supabase REST API, not just their own.

**Evidence:** Authenticated as user A, successfully retrieved user B's orders
via `GET /rest/v1/orders?select=*`

**Fix:** Enable RLS and add a policy restricting access to the row owner.

---

*Scanned by [Flowpatrol](https://flowpatrol.ai) in 4m 32s*

Every finding has evidence. The request that was made, the response that came back, and a clear explanation of what to fix. No guessing. No vague warnings.


Not just a comment

PR comments are great for visibility. But if you want findings tracked over time — across PRs, across branches — you want them in GitHub's Security tab.

The action outputs a SARIF file. One extra step uploads it to GitHub Code Scanning:

name: Security Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: flowpatrol/scan-action@v1
        id: scan
        with:
          target-url: https://staging.myapp.com
          api-key: ${{ secrets.FLOWPATROL_API_KEY }}

      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: ${{ steps.scan.outputs.sarif-file }}

Now your findings show up in the Security tab alongside CodeQL results and Dependabot alerts. Same interface your team already knows. Findings get tracked, deduplicated, and you can dismiss false positives right from the GitHub UI.

The if: always() matters — you want the SARIF uploaded even when the scan finds issues and the check fails.

GitHub Security tab showing Flowpatrol findings alongside CodeQL alerts, with severity badges and file locations


Control what blocks

Not every finding should block a merge. A missing X-Frame-Options header on a staging deploy probably doesn't need to stop your team. A critical auth bypass absolutely does.

The fail-on parameter lets you set the bar:

# Only block on critical findings — everything else is informational
- uses: flowpatrol/scan-action@v1
  with:
    target-url: https://staging.myapp.com
    api-key: ${{ secrets.FLOWPATROL_API_KEY }}
    fail-on: critical

Here's how the levels work:

  • critical — Only block on critical findings. Good for early-stage projects where you want visibility without friction.
  • high — Block on critical and high. The sweet spot for most teams.
  • medium — Block on medium and above. Tighter. Good for apps handling payments or sensitive data.
  • low — Block on everything. Maximum strictness.
  • none — Never block. The check always passes, but findings still appear as PR comments and SARIF. Pure visibility mode.

Start with critical or high. Tighten it as your app matures. The goal is to catch the things that matter without slowing you down.


Full configuration

Here's every option the action supports:

- uses: flowpatrol/scan-action@v1
  with:
    # Required
    target-url: https://staging.myapp.com
    api-key: ${{ secrets.FLOWPATROL_API_KEY }}

    # Scan mode (default: standard)
    #   quick    — headers, secrets, fingerprints (~2 min, 1 credit)
    #   standard — full scan (~5 min, 5 credits)
    #   deep     — aggressive + chained attack patterns (~15 min, 15 credits)
    scan-mode: standard

    # What severity level fails the check (default: high)
    fail-on: high

    # Post findings as a PR comment (default: true)
    comment: true

    # Generate SARIF output (default: true)
    sarif: true

    # Wait timeout in seconds (default: 600)
    timeout: 600

Three scan modes. Pick based on what you need:

  • Quick is for fast feedback. Headers, exposed secrets, framework fingerprints. Takes about two minutes. Good for draft PRs or WIP branches.
  • Standard is the default. The same scan you'd run from the Flowpatrol dashboard. Covers access controls, auth flows, API testing, and secrets. About five minutes.
  • Deep is for pre-launch. It chains findings together — uses a discovered API key to test what it can access, follows IDOR patterns across related endpoints, tests auth bypass sequences. Takes longer, finds more.

Pair it with the CLI

The GitHub Action covers CI. But sometimes you want to check things before you push — right from your terminal.

That's what @flowpatrol/cli is for:

npx @flowpatrol/cli scan https://localhost:3000

Same scan engine. Same findings format. Just runs locally instead of in CI. Catch issues before they even make it to a PR.

The action is for your pipeline. The CLI is for your workflow. Use both.

A split view showing the Flowpatrol CLI running in a terminal on the left and a GitHub PR comment with scan results on the right


Add the workflow. Ship with confidence.

You're already deploying previews on every PR. You're already running linters and type checks in CI. Adding a security scan is the same pattern — one more check that runs automatically, catches real issues, and gives you a clear pass/fail before you merge.

Here's your checklist:

  1. Add the workflow file. Copy the YAML above into .github/workflows/security.yml. Point it at your preview URL. Commit and push.

  2. Set your API key. Go to your repo settings, add FLOWPATROL_API_KEY as a secret. You can grab a key from your Flowpatrol dashboard.

  3. Open a PR. The scan runs automatically. Check the PR comment for findings. Check the Actions tab for the pass/fail status.

  4. Add SARIF if you want tracking. Add the github/codeql-action/upload-sarif step. Findings start showing up in your Security tab.

  5. Tune fail-on to your comfort level. Start with critical. Tighten over time. The action works for you, not against you.

Five minutes to set up. Runs on every PR from here on out. You built the app — now every change gets checked before it ships.


The Flowpatrol GitHub Action is available now on the GitHub Marketplace. Questions? Find us on Twitter/X or email contact@flowpatrol.ai.

Back to all posts

More in Product

Ship Faster with Security in Your Terminal
Mar 31, 2026

Ship Faster with Security in Your Terminal

Read more
Introducing Flowpatrol: You Shipped It. Now Make Sure It's Solid.
Mar 27, 2026

Introducing Flowpatrol: You Shipped It. Now Make Sure It's Solid.

Read more