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 for you in two situations:
  • When code is pushed to its default branch.
  • Once a day, whether or not anything was pushed.
The daily sweep is not a convenience. A repository nobody pushes to still depends on actions that are maintained by other people, and those can turn hostile without a single line of your code changing — a maintainer archives the repo, an advisory is published against the version you pin, or a version tag is quietly moved to point somewhere else. A push-triggered scanner cannot see any of that, because from its point of view nothing happened. Together they keep 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, and the repo joins the daily sweep.

​
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).

​
What the daily re-scan does

Every monitored repo is re-scanned about once a day, oldest first. Repos you have never scanned go to the front of the queue. Each run reads the current default-branch head, so the result is your posture now rather than your posture as of the last push. Scan history rows from the sweep carry a scheduled badge (🕐), kept deliberately separate from auto. “This appeared while nobody touched the repository” is a different and more alarming statement than “you pushed and this appeared”, and the badge is what tells them apart. Alerts work the same way they do for push scans: you hear about findings that are new, routed by your existing alert rules, and the Slack message says scheduled scan rather than push so you are not sent hunting for a commit that does not exist.

​
Drift on the actions you already pin

Scheduled scans do one thing push scans do not: they check whether the exact version tags your workflows reference still point at the commits Pipefort last saw them at. If actions/checkout@v4.1.1 resolved to one commit last week and a different one today, that is reported as a HIGH finding. An exact version tag is a promise that a specific commit is what you get, so a tag that changes is either a maintainer mistake or somebody replacing code you already reviewed. This is precisely how tj-actions/changed-files was compromised in March 2025: history was rewritten behind existing tags, and the affected repositories never changed at all. Floating refs are deliberately not reported. @v1 and @main are supposed to move — every release moves them — so flagging those would bury the signal under routine maintenance. Pin to a commit SHA if you want a ref that cannot move at all; see rule settings for the pinning rules that check this on every scan.

​
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 for the immediate trigger. Changing repo settings (branch protection, Actions permissions) does not fire a scan on its own — those changes are picked up by the next scan, whether pushed, manual, or scheduled.
  • The daily sweep is bounded. A large estate is walked over several days rather than in one run, stalest repos first, so every repo comes round regularly even though not all of them are scanned every night.
  • Drift detection is GitHub-only and covers third-party actions referenced by exact version tag. Actions pinned to a commit SHA are already immutable and are checked by the pinning rules instead.