airgap-vetting

name	airgap-vetting
description	Vet an open-source product for air-gap readiness BEFORE adoption. Answers eight questions — telemetry, does-opt-out-actually-work, proxy-in-disguise over a hosted API, runtime downloads, custom-CA support, feature-level content egress / offline degradation, day-two sustainment (feed mirroring, staleness), and a 4-grade verdict (air-gap-native / possible-with-mirror / proxy-in-disguise / no-go). Two-pass: static grep of source + container image (bundled fingerprint tables work offline), then an optional dynamic harness (--network=none, egress deny+log, mitmproxy CA injection, faketime). Writes AIRGAP-VETTING.json + .md. Use for any "should we adopt X?" question in a disconnected environment, not just when the user says "air gap".
when_to_use	Use when the user asks to vet, audit, or evaluate a tool for air-gapped, offline, disconnected, or restricted-egress use: "does X work offline", "can we run X air-gapped", "will X phone home", "does X send telemetry", "is X really open source or a wrapper around their cloud", "what does X download at runtime", "can X use our internal CA", "check X before we adopt it", "is X self-hostable for real", "what breaks if X can't reach the internet", "how do we keep X updated offline". Also on symptoms: a tool hangs or crashes without internet, a security review needs an egress inventory, or an adoption decision needs an offline-readiness verdict. This is an adoption/offline-readiness vet — not CI/CD pipeline hardening and not source-code vulnerability scanning.
argument-hint	<product|repo-path|image-ref> [--dynamic] [--repo PATH] [--image REF] [--stakes low|high]

airgap-vetting

Rapidly vet a candidate OSS product for air-gap readiness before adoption. Answers eight questions and assigns one of four grades. The organizing insight from the research behind this skill: "documents an offline flag" ≠ "works offline" — several tools fall back to downloading even with their own offline flag set, and the decisive distinction (air-gap-native vs proxy-in-disguise) is only provable by denying egress after activation and watching whether the product keeps working.

Invoke with /airgap-vetting <target> [--dynamic] [--repo PATH] [--image REF] [--stakes low|high].

Arguments (parse from $ARGUMENTS):

• target (first positional, required): a product name (meilisearch), a local source checkout, a git URL, or a container image ref. Resolve whatever else is needed in Phase 0.
• --dynamic: run the Phase-2 dynamic harness (requires Docker and, for the deny+log step, root/iptables on a disposable host or VM). Without it the vet is static-only and the verdict says so.
• --repo PATH / --image REF: explicit source checkout / image when the positional target is ambiguous.
• --stakes low|high (default low): high mandates the dynamic pass for any candidate that survives static (refuse to emit a final grade without it); low allows a static-only provisional grade.

The eight questions:

#	Question	Reference
1	Sends telemetry to the internet?	references/telemetry.md
2	Can telemetry be turned off — and does off mean off?	references/telemetry.md
3	Actually a proxy over a hosted API?	references/downloads-and-proxy.md
4	Requires internet at runtime for downloads?	references/downloads-and-proxy.md
5	Supports custom CA / private TLS trust?	references/ca-trust.md
6	Ships user content out / degrades offline?	references/content-egress.md
7	Can it be kept alive offline (day-two)?	references/sustainment.md
8	Overall verdict grade	rubric below

Two cross-cutting sub-check clusters feed several questions: time/revocation/offline signature verification (references/verification-time.md) and identity/inbound/connectivity-probes (tail of references/content-egress.md).

Read each reference file at its question — they carry the exact hostnames, env vars, grep patterns, and known counter-examples. Do not answer a question from general knowledge when the reference has a table for it: the tables encode verified, sourced fingerprints, including several cases where docs and behavior disagree.

---

Phase 0: Scope the target

1. Check prior art. Read references/known-products.md. If the candidate (or its direct dependency) already has a row, say so up front — the row may answer the whole request, or at least pin expectations.
2. Resolve the target. Get a local source checkout (clone if needed; prefer an existing clone under ~/projects/github.com/<org>/<repo>) and, when a container distribution exists, the image ref. Record versions: git tag/commit and image tag@digest. The verdict is version-specific — pin what was actually vetted.
3. Identify the deployment shape (CLI, server, K8s chart/operator, desktop app). This decides which static checks apply (Helm image enumeration only for charts; browser-console check only for web UIs).
4. Locate the docs' own air-gap story. Search the repo/docs for pages titled "air-gap", "offline", "disconnected", "self-hosted". Their existence is a green flag (Q8) and their claims become hypotheses for the static pass to check — never conclusions.

---

Phase 1: Static pass (always)

Work through Questions 1–7 in order. For each, record in working state: answer (yes/no/partial/unknown), evidence[] (exact grep hit with file:line, hostname, or doc URL), and flags[] (red/green signals for grading). Every claim in the final report carries evidence — a verdict row without a grep hit or citation is a guess, and guesses get unknown, not no.

Q1 — Telemetry. Read references/telemetry.md §Fingerprints. Run BOTH grep layers (SDK packages AND hostnames) over source and — if an image is in scope — strings over its binaries, docker inspect ENV, entrypoint scripts, and a CNAME check of the registry host (Scarf Gateway hides in the distribution channel). One layer alone misses what the other catches.

Q2 — Opt-out semantics. Read references/telemetry.md §Opt-out. Grep the candidate for kill-switch-shaped tokens (telemetry-adjacent substrings, not an exact-name list) — the mere presence of opt-out handling is evidence telemetry exists. Then check the six pitfalls (opt-out-by-default, phones-home-before-opt-out, value-vs-presence bugs, reduce-not-eliminate, separate update-check channel, destination drift) against the code that actually reads the variable. Verify polarity in source, not docs.

Q3 — Proxy-in-disguise. Read references/downloads-and-proxy.md §Proxy. Repo topology, hardcoded base URLs, BYOK-routing docs, pricing-page "self-hosted = Enterprise" tells, mandatory-login issues.

Q4 — Runtime downloads. Same file, §Downloads. Build-time vs runtime is the organizing principle. For Helm charts, enumerate images from rendered output (helm template | grep -oE 'image: *"?[^"]+' | sort -u), never values.yaml alone. Runtime-computed image names are an automatic no-go.

Q5 — Custom CA. Read references/ca-trust.md. Identify the TLS stack per ecosystem, check additive-vs-replacement semantics, and hunt the two hard blockers (compiled-in webpki-roots, certificate pinning) plus the anti-pattern of verification-off switches offered instead of a CA option.

Q6 — Content egress & offline degradation. Read references/content-egress.md. Inventory features that send user content (AI assist, gravatar, map tiles/GeoIP, link previews) with their kill switches, plus CDN-loaded frontend assets. Also run the identity and inbound sub-checks at the tail of that file. Output here is a per-feature table: feature → destination → default on/off → kill switch → what's lost offline.

Q7 — Sustainment. Read references/sustainment.md. How do upgrades and content feeds (vuln DBs, rules, models) cross the gap, and what does the product do when a feed is stale — fail-closed, warn, or silently report green? Find the age-validation code (or its absence). Count the gap crossings an upgrade path requires.

Signature-verification and time sub-checks (feed Q4/Q5/Q7): if the product or its install path verifies signatures (cosign, Notation, GPG) or carries an expiring license, read references/verification-time.md and run its greps — provenance verification is itself a common hidden egress.

Static-pass greps run offline; only Phase 0 target resolution and optional gh issue-searches need network. When vetting from inside a gap, skip the gh checks and note them as not-run in the report.

---

Gate: static → dynamic

Run the dynamic pass when any of:

• --dynamic was passed, or --stakes high and the candidate survived static;
• Q3 is unresolved (docs market "offline" but static found license-ping or activation endpoints) — the post-activation egress-deny test is the mandated tie-breaker between possible-with-mirror and proxy-in-disguise; do not guess this boundary statically;
• Q2 found opt-out flags whose actual behavior can't be confirmed in source (compiled binary, obfuscated build);
• Q5 hinges on runtime behavior (does the binary honor HTTPS_PROXY + custom CA?).

If the gate fires but --dynamic was not passed and stakes are low, emit the static-only report with grade suffix (provisional — dynamic pass not run) and list exactly which dynamic steps would settle which questions.

If stakes are high but the dynamic pass cannot run (no Docker, no disposable host), do NOT emit a final grade — that is the whole point of high. Report the static findings, set grade_provisional: true with the grade left as the static best-guess, and state plainly that a final verdict requires running the listed dynamic steps on a disposable host.

Phase 2: Dynamic pass (gated)

Read references/dynamic-harness.md and run its ladder on a disposable host/VM: (1) --network=none first-run, (2) iptables DOCKER-USER deny+log with REJECT, (3) passive DNS/egress enumeration, (4) mitmproxy with CA injection — this one test settles Q5 and inventories Q1 destinations, (5) post-activation egress-deny (the Q3 tie-breaker), (6) browser-console check under deny for web UIs (Q6), (7) stale-feed run for security tools (Q7), (8) faketime skew runs (+30 days, +13 months) for time dependencies. Capture in two windows — first-run AND 10–30 min steady-state; timer-based heartbeats don't show up in a 30-second capture.

---

Phase 3: Grade (Question 8)

Assign exactly one grade. When evidence splits across grades, the worse grade wins — the cost of over-promising air-gap readiness (a dead product inside the gap) far exceeds the cost of extra mirroring work.

air-gap-native — complete published artifact enumeration (image list / relatedImages / SBOM); digest-pinnable references; ONE global registry override covering ALL images including init-containers and operator-pulled ones; license validated locally via cryptographic signature with zero callbacks ever; every outbound feature listed with a documented kill switch or local-mirror path; custom-CA injection works; offline docs artifact; installer completes with egress fully denied; content feeds published as mirrorable artifacts (OCI/HTTPS) with override flags and non-silent staleness handling; a published feature-degradation table.

possible-with-mirror — all artifacts enumerable and mirrorable (possibly with effort); registry overrides exist but per-image rather than global; offline license path exists but may be approval-gated; some features degrade offline in a documented way; requires standing mirror infrastructure and periodic content sync. Also the cap for: default-on content-egress features that DO have a self-hosted path, and security feeds that go silently stale (state the silent-stale warning explicitly in the verdict).

proxy-in-disguise — vendor markets "offline/disconnected" but operation requires allowlisted egress to specific endpoints: license-ping servers, telemetry gateways, activation callbacks, update checks that gate functionality, or login that requires the vendor's cloud with no offline workaround. Works behind an HTTP proxy, dies behind a true gap. Decisive objective test: does the product survive a permanent egress-deny applied after activation? Note: air-gap sold only as a negotiated license tier is a proxy-in-disguise trigger even when technically mirrorable.

no-go — hardcoded URLs with no override; image/artifact names computed at runtime (defeats all mirroring); install scripts that fetch mid-run with no offline flag; license enforcement that shuts the product down absent connectivity with no offline tier; no way to enumerate what to mirror; TLS certificate pinning or compiled-in-roots-only on endpoints that must be mirrored.

---

Phase 4: Output

4a. Write ./AIRGAP-VETTING.json

{
  "vetting_completed": true,
  "candidate": {
    "name": "...",
    "version": "git tag/commit and/or image@digest actually vetted",
    "source": "repo URL", "image": "ref or null",
    "deployment_shape": "cli|server|k8s-chart|k8s-operator|desktop"
  },
  "mode": "static-only|static+dynamic",
  "stakes": "low|high",
  "grade": "air-gap-native|possible-with-mirror|proxy-in-disguise|no-go",
  "grade_provisional": false,
  "questions": [
    {
      "id": 1,
      "question": "Sends telemetry to internet?",
      "answer": "yes|no|partial|unknown",
      "evidence": ["exact grep hit with file:line, hostname, or captured destination"],
      "flags": ["red: ...", "green: ..."],
      "kill_switches": ["ENV_VAR=value (polarity verified in source at file:line)"],
      "dynamic_confirmed": false
    }
  ],
  "egress_inventory": ["hostname — purpose — first-seen (static grep | dns capture | mitm)"],
  "mirror_list": ["everything that must cross the gap: images@digest, feeds, models, docs"],
  "sustainment": {
    "feeds": [{"feed": "...", "mechanism": "...", "staleness_behavior": "fail-closed|warn|silent"}],
    "upgrade_gap_crossings": "packages/artifacts per upgrade hop",
    "sync_cadence_required": "..."
  },
  "not_run": ["checks skipped and why"]
}

Every question appears exactly once, unknown answers stay unknown, and not_run lists what a follow-up should do. Do not print this JSON to the terminal; write to file only.

4b. Write ./AIRGAP-VETTING.md

Reviewer-facing, in this order: title + one-line verdict; the grade with its two or three decisive pieces of evidence; the eight-question table (question | answer | strongest evidence); the per-feature content-egress table (Q6); the mirror list; the sustainment summary; Not run / next steps. Keep it under ~120 lines — the JSON carries the full detail.

4c. Append to the known-products log

Append one row to ./AIRGAP-KNOWN-PRODUCTS.md in the working directory (create with header if absent, same columns as references/known-products.md). If the skill directory itself is writable (in-repo development, not an installed plugin), ALSO append the row to references/known-products.md so the skill compounds across runs.

4d. Terminal summary

Under ~10 lines: grade (+ provisional marker), the single most decisive finding, count of red/green flags per question, where the reports were written, and — if static-only — the one dynamic test most worth running.

---

Maintenance

Smoke tests (expected grades for three known-products rows), design rationale, composition with sibling skills, and provenance live in references/maintenance.md. Re-verify the version-gated facts periodically — cosign v2 vs v3 flags, DCT shutdown 2026-12-08, and the dated known-products rows all drift.