ProveBreakSecurity
Last updated September 25, 2026 · Reviewed against the code of the shipped release (5.2.1)
ProveBreak is a GitHub Action that you add to your own repository. When a watched workflow fails, it writes a proof card to that run’s GitHub Job Summary. For failed pushes to your default branch, it re-runs the failing tests at older commits to prove which commit broke them. It runs only on the GitHub Actions runners you already use. There is no ProveBreak server, account or dashboard.
“Sentinel” is ProveBreak’s internal code name. You’ll see it in file, folder and workflow names (for example .github/actions/sentinel/). It is the same software.
Permissions
The workflow starts from permissions: {} (nothing) and grants only what each job needs:
| Job | Token permissions | Secrets | Runs your code? |
|---|---|---|---|
install-check (only when the workflow file itself is pushed) | actions: read, contents: read | None | No |
card | actions: read, contents: read, pull-requests: read | None (job token only) | No — API reads and git plumbing only |
bisect (only for failed pushes to the default branch) | contents: read | None. Checkout doesn’t keep credentials, and secret-looking variable names are refused. | Yes — your failing tests at older commits |
render | contents: read (plus pull-requests: write only if you turn on PR comments, which are off by default) | A Slack webhook, only if you add one | No |
- It never pushes, commits, merges, assigns or changes code. The only GitHub write in the code is an opt-in pull-request comment (off by default).
- Runs from forks never get a bisect. Pull-request runs don’t either, unless you explicitly enable it (not recommended).
Where it runs
- Every job runs on your GitHub Actions runners (
ubuntu-latestby default). You can switch to self-hosted runners; if you do, use ephemeral ones, because a persistent self-hosted runner defeats job isolation. - The Action is plain Python standard library, with no third-party packages. It runs in isolated mode from a read-only staged copy, and the job that can hold a Slack webhook re-hashes the Action’s code and refuses to run if it differs from the copy used earlier in the run.
What leaves your environment
Checked against every network call in the Action’s source:
| Destination | When | What |
|---|---|---|
| Your GitHub API (github.com, or your GitHub Enterprise Server) | Always | Reads runs, jobs, logs, commits, comparisons and CODEOWNERS. The only write is the opt-in PR comment. |
| ProveBreak (us) | Never | There is no ProveBreak endpoint in the code and no telemetry. The Action also turns off Yarn’s own telemetry during test re-runs. |
Slack (hooks.slack.com only; other hosts and redirects refused) | Only if you add a Slack webhook | Headline, culprit short commit hash, failing test names, a summary of up to 400 characters, a suggested git revert command, and links. |
| pypi.org / registry.npmjs.org (read-only lookups) | Only if you turn on an experimental “outside cause” check (off by default) | Public package names and versions from your lockfile changes, to check release dates. |
| Your own LLM provider (HTTPS only, redirects refused) | Only if you turn on the experimental fix suggestion and supply your own API key and a culprit was proven | At most 24,000 characters: the culprit diff (credential-like files removed), the failing test’s source, short code snippets and a redacted error excerpt. Each run records what was sent. The key lives only in a job that runs no repository code. Suggested patches are displayed, never applied. |
| Package registries and toolchain downloads | During test re-runs | Whatever your own install step already fetches (for example npm ci, pip install, Go modules), plus standard actions/setup-* toolchains. No repository data is sent. |
Bottom line: by default, nothing leaves GitHub. Slack and the fix suggestion send data only when you opt in and supply the destination and key yourself.
Releases and integrity
- ProveBreak is delivered as a release archive that you add to your repository under
.github/actions/sentinel/. Nothing is fetched from us at run time. - The installer checks the archive’s SHA-256 against a value you pass on the command line (sent to you separately from the download) and stops on a mismatch. It refuses archive entries that aren’t plain files in the expected folder, and it never commits, pushes or uses the network.
- Every third-party action in the workflow is pinned to a full commit SHA.
- Not yet available: signed releases (Sigstore or GPG) and an SBOM. Today the SHA-256 checksum is the integrity check.
Data retention
- ProveBreak keeps no data of its own anywhere. Its output lives in your GitHub account: the Job Summary of each run (kept under your repository’s Actions log retention setting) and workflow artifacts kept for 3 days (intermediate) and 7 days (final card).
- Slack messages and LLM-provider requests (both opt-in) are governed by your agreements with those providers.
How to audit it
- Read the source. It is small, standard-library Python in your repository under
.github/actions/sentinel/, with a security-model comment at the top ofaction.yml. - Search for network calls:
grep -rn "urllib\|http" .github/actions/sentinel/src. You’ll find only the GitHub API client, the Slack sender, the opt-in registry lookups and the opt-in LLM call. - Check permissions in
.github/workflows/sentinel.yml(it starts atpermissions: {}). - Watch a run: every job logs its mode and a hash of the Action’s source. Card and bisect results are downloadable JSON artifacts.
- Remove it by deleting
.github/actions/sentinel/and.github/workflows/sentinel.yml.
Known limits
- The bisect job runs the code under test, so that code could misreport its own results. Output validation limits a forged result to a status from a fixed list and a commit within the searched range, and the job holds no secrets.
- Redaction of log excerpts (and of what goes to an LLM, if enabled) is pattern-based and can miss unusually shaped secrets.
- ProveBreak has not had an external penetration test. The statements on this page come from code review of the shipped release.
- Each eligible red push can use up to about 20 minutes of runner time for the bisect, plus setup, on your GitHub Actions bill.
Reporting a vulnerability
Email hello@provebreak.com with “Security report” in the subject. Please don’t include secrets or customer data in the first message.