How scanning works

Supply Chain Security 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, product, 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.

The default policy reports findings at medium severity or above as blocking. Administrators will be able to configure trusted repository policy as the application foundation is delivered.

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.