//CI & CLI

Catch it in review, not in production.

The repository scanner runs on your machine or in your pipeline. It reads your filesystem and sends us nothing, findings come back with file and line, and the exit code fails the build.

runs onGitHub ActionsGitLabNodeBun

From your terminal

Scans committed credentials, env-file handling, unsafe migrations and unprotected route handlers.

npx flare-deep .                    # scan the current directory
npx flare-deep . --fail-on high     # stricter threshold
npx flare-deep . --json out.json    # machine-readable output

In GitHub Actions

name: Security
on: [pull_request, push]

jobs:
  flare:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx flare-deep . --fail-on critical
        # exits non-zero on a critical finding → the build fails

A summary on the pull request

The scan also posts a single comment on the PR (worst findings first, each with its file and line and the fix) and edits that same comment on every push rather than stacking a new one. It states what was found and stops: no severity theatre, no invented stakes. The blocking gate is the exit code above; this is the part a reviewer reads.

# generate the comment body
npx flare-deep . --pr-comment flare-comment.md --fail-on low
# then post it with actions/github-script (contents: read, pull-requests: write)

Exit codes

Suppressing a finding

Test fixtures and documentation sometimes have to contain credential-shaped text. Mark the line rather than excluding whole files, so the suppression stays visible in review:

const key = "sk_live_EXAMPLEKEYFORTESTS"; // flare-ignore: fixture