Docs › Deployment & Data Sovereignty

Deployment & data sovereignty

For security, procurement, and data-protection reviewers — especially EU, government, defence, and regulated-financial buyers who must know exactly what leaves their environment. This page is a plain, verifiable account of where PullGuard runs and what data it handles.

Where your code goes: nowhere

PullGuard runs inside your CI and never receives your source code. The scanner analyses your code in place, on your runners, and emits results-only outputs — reports, SARIF, JSON — that you control. In its air-gapped configuration it makes zero external calls: no telemetry, no source upload, no phone-home. When run online, the only thing that leaves is license validation (an org name + token) — never your code.

One precise disclosure: free-tier scans running in GitHub Actions may attach an anonymous adoption signal (the public numeric GitHub repository/owner ids — no code, no findings, no PII) to the rules fetch, with opt-out via telemetry: false, PULLGUARD_TELEMETRY=off, or DO_NOT_TRACK=1. Paid, offline, and air-gapped scans never send any telemetry, ever.

Unlike SaaS scanners that upload your code to their cloud for analysis, PullGuard analyses in place and only ever produces a report that stays with you.

Data flow: what does (and doesn't) leave the runner

Mode	Source code	Findings / results	License check	Rule updates
Air-gapped self-hosted runner + mirrored image + offline key	✗ never leaves	✗ stays in your CI	✗ validated locally (signed offline key, no call)	✗ uses the image's embedded rules
Online GitHub-hosted runner + GHCR + online token	✗ never leaves	✗ stays in your CI / your git host	✓ org + token → our licensing service (no source)	✓ signed rule bundle fetched (read-only)

Your code is never uploaded to PullGuard in either mode. The licensing service only validates subscriptions; it never receives scan data.

Fully air-gapped operation

For sovereign / classified / no-egress environments, PullGuard runs with no external dependency at scan time:

Mirror the scanner image into your internal registry (from ghcr.io/pullguard-dev/pullguard:<tag>).
Run on a self-hosted runner inside your network (not a GitHub-hosted runner).
Use an offline license key — it validates locally against a signed key and never contacts our licensing service.

Result: the scan reads your code, writes a report, and makes zero network calls. CVE scanning stays available offline via the local vulnerability database (update on a connected machine, transfer the archive across your air-gap). Most SAST tools cannot operate this way.

Supply-chain verifiability

Since v1.3.4, the published scanner image ships SLSA build provenance and an SBOM. Your security team can verify how the image was built (source commit, builder, materials) and what it contains — before it ever runs in your environment:

docker buildx imagetools inspect ghcr.io/pullguard-dev/pullguard:<tag>

Release tags (e.g. v1.3.4) are immutable and preserved forever; pin an exact tag or a sha256: digest (the image-pin workflow input) for change-controlled environments.

Self-hosted server: results-only, on your infrastructure

Want a live, multi-repo dashboard without giving anyone your data? The self-hosted PullGuard server (Enterprise) runs inside your boundary, on your domain. Your CI POSTs scan results only — findings, scores, grades — never source code; the ingest endpoint actively rejects source-looking payloads. The server validates its licence offline and makes no call home, so it too runs fully air-gapped.

Regulatory posture

The scanner is not an “AI system” under the EU AI Act. It is static analysis — deterministic rules and program analysis, with no machine-learning inference at runtime. You scan for AI-era risk without the scanner itself being in scope as an AI system.
GDPR-favourable. Because PullGuard never receives your scan data, it is not a processor of personal data that may appear in your code — that data stays in your environment.
Compliance mapping ≠ certification. PullGuard maps your findings to control frameworks to produce evidence auditors can use — it does not, and does not claim to, grant compliance.

What to verify yourself

Don't take our word for it — every claim above is testable in your own environment:

Run a scan on a self-hosted runner with an offline key and capture the network traffic — you should see zero outbound calls.
docker buildx imagetools inspect ghcr.io/pullguard-dev/pullguard:<tag> — confirm the SLSA build provenance + SBOM.
Inspect any emitted report — it contains findings and metadata about your code, produced locally; nothing is sent to us.

Questions from a procurement or data-protection review are welcome — hello@pullguard.dev.