Skip to main content
Manual scans tell you your posture when you remember to ask. Monitoring flips that: mark a repo as monitored and Pipefort scans it automatically every time code is pushed to its default branch, keeping the dashboard, trends, and Attacker Mind current without anyone clicking “Scan”. Pair it with Slack notifications to hear about scans that found something new.

​
Turning it on

Monitoring is off by default for every repo. Toggle it in either place:
  • Repositories page — the Monitor column has a switch per row.
  • Repository detail page — the Monitoring switch in the header, next to the Re-scan button.
The toggle takes effect immediately: the next push to the repo’s default branch triggers a scan.

​
What a push-triggered scan does

A push scan is identical to pressing Re-scan with the all ruleset — same engine, same rule settings (global toggles and per-repo overrides are respected), same persistence. Two differences show up in the UI:
  • Scan history rows carry an auto badge (⚡) so you can tell push-triggered scans from manual ones.
  • The scan records the exact commit SHA that was pushed (manual scans record the branch head at scan time).

​
How it works

The Pipefort GitHub App subscribes to push webhooks. When GitHub delivers one:
  1. Pipefort verifies the delivery’s signature and rejects anything unsigned or tampered with.
  2. Pushes to branches other than the default branch, and branch deletions, are acknowledged and ignored.
  3. Duplicate deliveries (GitHub’s automatic redeliveries) never cause duplicate scans.
  4. If several organizations have linked the same installation and monitor the repo, each organization gets its own scan — scan history and findings are per-organization, exactly like manual scans.
Scans can take longer than GitHub’s ~10-second webhook delivery timeout, so the delivery may appear as “timed out” in the GitHub App’s Advanced → Recent Deliveries log even though the scan completed. Check the repo’s scan history in Pipefort for the actual result.

​
Limits (v1)

  • Default branch only. Pushes to other branches are ignored. (Branch lists are a planned follow-up.)
  • GitHub only. GitLab webhook support is a planned follow-up; GitLab repos can still be scanned manually.
  • Push events only. Changing repo settings (branch protection, Actions permissions) does not trigger a scan — those changes are picked up by the next scan, manual or pushed.