Supply chain

Everything Atlantic ships (the engine, LightHouse, the infrastructure modules your stack is built from, and this site) is built from repositories that share one security baseline. It is released by version and pinned by every repository, so no repository can quietly run an older or weaker set of checks.

On every commit

What it is. Pre-commit hooks, installed in every clone, that block the commit:

Hook	Catches
gitleaks	Secrets in the staged change
Private-key detection	Key material of any kind
Size, merge-marker and syntax checks	Files over 1 MB, conflict markers, broken YAML, JSON and TOML
Python	ruff, and bandit at medium severity and above
Terraform	terraform fmt, checkov on every changed directory, terraform validate on push
TypeScript	Each package’s own eslint on changed files

Hooks are never skipped. A false positive is recorded in the repository’s own allow list with a reason, where review sees it. A real secret that reached a commit is rotated first, then removed.

In every pipeline

What it is. The same checks again in CI, plus scanners too slow for a commit:

Job	What it does	Effect
Secrets	gitleaks over the whole history on branches and tags	Fails the pipeline
Hooks, again	Every pre-commit hook over every file, so a clone without hooks is still caught	Fails the pipeline
Baseline drift	The repository’s hooks differ from the pinned baseline, or a language’s add-on is missing	Fails the pipeline
SAST	Static analysis by language (Semgrep-based)	Reports
Infrastructure as code	checkov, tfsec and Trivy’s Terraform rules	Reports; gates where a repository opts in
Dependencies	pip-audit; npm or pnpm audit at high and critical	Reports
Dockerfiles	Trivy’s Dockerfile rules (root user, unpinned bases)	Reports

The engine and LightHouse go further, and fail the pipeline on: pip-audit findings (exceptions are dated and expire), bandit, checkov on their infrastructure, and Trivy scans of every image they build.

“Reports” means the job runs and leaves its findings for triage without blocking the merge. Each repository moves a scanner to gating once its findings are cleared.

Branches and releases. The default branch of every repository accepts pushes from maintainers only, with force-push off. Release tags are protected: only maintainers create them, and a release never moves.

Images

What it is.

• The engine’s images and LightHouse’s service image are built on Chainguard’s Wolfi base, pinned by digest, with each package at an exact version. It was chosen because it carried no open findings when it replaced a Debian base that had eight high findings with no fix published.
• They run as a non-root user, with no package installer (pip) in the runtime image and no secret baked in: settings come from the environment at run time. LightHouse’s service also runs on a read-only root filesystem.
• The portal’s image is Node on Alpine, pinned by digest, with npm, npx, corepack and yarn removed from the runtime stage.
• Every dependency of this documentation site is pinned to an exact version at least two weeks old.

Verify. Pull an image by the digest your stack names and scan it with the scanner you trust. Under NDA we will share the latest scan reports.

Point-in-time reviews

Beyond the pipelines, LightHouse has been reviewed in full at a point in time. The most recent review, on 30 October 2026, ran Semgrep (OWASP Top Ten and language rules), Bandit, eslint’s security plugin, pip-audit, pnpm audit, Trivy (images and infrastructure), gitleaks over the full history, Checkov, tfsec, an OWASP ZAP baseline scan against a local stack and the public sign-in page, and a threat-model review of new endpoints. Findings were fixed, or accepted with a written reason and a mitigation. Two items from it have since been closed: the service image moved to the Wolfi base above, and every portal page now uses a per-request nonce in its content security policy.

No report from an independent third-party penetration test is available yet. This page will say when one is.

Signed telemetry

What it is. Every telemetry post from your deployment is signed with an Ed25519 key pair generated for that deployment. The private key stays in your secret store; LightHouse holds only the public key.

The signature covers four lines: the HTTP method, the path, a Unix timestamp, and the SHA-256 of the body exactly as sent. LightHouse’s intake refuses:

• an unsigned request (401 unsigned), or one whose signature does not verify (401 bad_signature);
• anything more than five minutes old (401 stale);
• any replay of a signature it has seen (409 replayed);
• any record naming a client or deployment other than the signer’s (403 mismatch);
• any record carrying an attribute not on its type’s allow list (422 invalid). The refusal names the attribute, never its value.

Up to two public keys can be registered for a deployment at once, so a planned rotation never interrupts telemetry. A key retired because it leaked is replaced with no overlap and stops at once.

Content reads and commands travel the other way, and are signed the same way with Atlantic’s keys, which your reader and your handler hold as public keys you configure. See Architecture.

Where. Your deployment signs; LightHouse’s intake verifies.

Verify. The engine’s sender is the reference implementation of the signature, and the format is in the telemetry contract. Your deployment’s keys and rotation state are in GET /api/v1/me under deployment_keys (key IDs only).