Static.Self-managed.Verification-led.

Infrastructure compromise

• Registrar account takeover
• DNS hijack
• Hosting credential compromise

Content tampering

• Post-deployment file modification
• Malicious JavaScript injection
• Silent alteration of static assets

Administrative abuse

• Credential stuffing
• Automated vulnerability scanning

Commodity internet noise

Continuous automated probing for common CMS paths, configuration files, or known endpoints. These are treated as persistent background conditions rather than exceptional events.

Delivery & freshness

• A stale but validly-signed release served in place of a newer one
• A poisoned or stale browser / service-worker cache on the client

Registrar & DNS

• MFA enabled
• Registrar lock active
• DNSSEC enabled and validated
• CAA records restrict certificate issuance

Hosting

• Multi-factor authentication enabled
• SFTP-only deployment
• No SSH shell exposure
• No scheduled background execution

Public content

• Static architecture reduces server-side attack surface
• Strict CSP starting from default-src 'none'
• No external resource loading
• No dynamic script execution
• Local browser storage limited to reader preferences (language, appearance), a first-visit marker that retires the French machine-translation notice, and service-worker install timestamps used solely to display when the offline cache was last refreshed; readable on the Local Device Console; no cookies, no analytics or advertising identifiers, no session tracking or behavioural profiling

Monitoring

• Structured log analysis
• Pattern detection and anomaly scoring
• File integrity drift detection against the signed release baseline

Source control & supply chain

• Protected main and preprod branches: linear history, signed commits required, no force-push, no deletion
• Every change ships through a pull request gated by required checks — release gate, secret scan, reproducible build and signature verification
• Production deployment waits on a manual environment approval before the push reaches the live host
• Release archives carry SLSA build-track Level 3 provenance: built on a hosted runner, attested keyless through Sigstore (GitHub OIDC) and recorded in the public Rekor transparency log
• Each release ships a CycloneDX SBOM of the build toolchain
• The signing key never enters CI; the canonical manifest stays locally built and PGP-signed

Inspection routes

The site exposes public inspection routes so published content can be checked without private infrastructure access.

• /integrity/ records signed releases, public key and manifest
• /verify/ records one page’s canonical URL, source mirror and fingerprint
• /source/ publishes readable mirrors of selected public files
• /integrity/releases/ preserves frozen signed snapshots

What it does not cover

These routes support inspection and provenance. They do not remove the need to protect DNS, hosting credentials and the private signing key.

Out of scope

This model does not attempt to address:

• Physical compromise of hosting infrastructure
• Global DNS root compromise
• Certificate authority (CA) compromise
• State-level adversaries
• Zero-day browser exploits on client devices

Where the risk concentrates

The main risks remain domain, DNS, hosting and private key compromise.

Operator assumptions

• A single trusted author controls the source and each release
• The only private signing key lives on the author's local machine, never in CI
• That machine's integrity is assumed; a compromise there is out of scope
• Readers confirm the key fingerprint out of band before trusting a signature

Per-edition checks

Every published edition is checked against a fixed set of public targets. The checks cover availability, privacy, security headers, accessibility, SEO and markup, and the result is recorded as a signed snapshot alongside the edition.

View the latest test results at /tests/.