How scanning works

Supply Chain scans the immutable commit identified by GitHub. This keeps the result tied to the code a reviewer is assessing.

Scan lifecycle

1. GitHub sends a signed check event to Signals Corps.
2. Signals Corps verifies the webhook signature and rejects replayed deliveries.
3. The scan is queued for the repository, module, and exact commit SHA.
4. A worker downloads a bounded archive for that commit.
5. The archive is checked and extracted into disposable storage.
6. Supported files are inspected with pinned rules.
7. Findings and reproducibility metadata are recorded.
8. The result is published as a GitHub check.
9. Extracted source is deleted.

Repository safety boundaries

Repositories and archives are treated as untrusted input. The scanner:

• does not execute repository code;
• rejects path traversal, symbolic links, and hard links;
• limits archive download and extraction size;
• limits file counts and individual file sizes; and
• keeps private repository contents out of logs and external telemetry.

Policy

Enforcement policy is stored in Signals Corps, outside the commit being scanned. A pull request cannot weaken the policy used to assess itself.

Policy is managed by Signals Corps and selected by the Workspace’s effective plan. Customers can inspect the active profile but cannot edit rule behavior in the MVP. Recommended policy can block high or critical matches from the stable rule subset; Essential policy reports matches without automated blocking.

Re-runs and failures

Repeated delivery of the same GitHub event does not create duplicate active work. An explicit re-run creates a new result for the same commit so the history remains reviewable.

Download, extraction, scanner, persistence, and publication errors fail the scan. A technical error never produces a clean result.

Read Scans and results for the meaning of scan states, conclusions, and coverage.