diff --git a/SECURITY.md b/SECURITY.md index d89aea6..356c1ea 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -18,7 +18,7 @@ MeshChatX is meant to be used on **trusted networks** (for example at home, on a If you still put the web interface on the **public internet**, you accept much higher risk (password guessing, misconfigured TLS or proxies, automated scanning, and overload of a single-node app). If you must expose it: **turn on authentication**, use **HTTPS** with a valid certificate for the public name, **restrict who can reach the port** (firewall, VPN, or a reverse proxy with sensible rules), and **keep the application updated**. `/robots.txt` with `Disallow: /` is only a hint to crawlers, not protection. -The app adds **rate limiting** and **lockout** for failed logins, **logging** of access attempts (viewable under Debug Logs), and **HttpOnly** session cookies with **SameSite=Lax**. These measures reduce some abuse; they do not make a public deployment “safe by default.” +The app adds **rate limiting** and **lockout** for failed logins, **logging** of access attempts (viewable under Debug Logs), and **HttpOnly** session cookies with **SameSite=Lax**. These measures reduce some abusebut do not make a public deployment “safe by default.” ### What you download should match what we built @@ -30,7 +30,7 @@ Official release binaries and packages are built in **automation on GitHub**, no **Docker images** published to GitHub Container Registry are built in CI and **signed with Cosign (keyless / Sigstore)** so the signature can be checked against the image digest. -**Optional extra signatures:** If you see `*.cosign.bundle` files next to a binary, those are additional attestations from a **repository-managed signing key** (when the project enables it). They are separate from the SLSA `*.intoto.jsonl` files; either or both may be present depending on configuration. +**Optional extra signatures:** If you see `*.cosign.bundle` files next to a binary, those are additional attestations from a **repository-managed signing key** (when the project enables it). They are separate from the SLSA `*.intoto.jsonl` files. Either or both may be present depending on configuration. ### Practical tips @@ -44,15 +44,16 @@ Official release binaries and packages are built in **automation on GitHub**, no ### Product controls (high level) -- **Desktop (Electron):** Packaging and runtime follow [Electron security guidance](https://www.electronjs.org/docs/latest/tutorial/security); ASAR integrity and hardened defaults (for example fuses that reduce risky Node integration) are part of the shipped app. +- **Desktop (Electron):** Packaging and runtime follow [Electron security guidance](https://www.electronjs.org/docs/latest/tutorial/security). ASAR integrity and hardened defaults (for example fuses that reduce risky Node integration) are part of the shipped app. - **Backend:** A SHA-256 manifest of the bundled Python backend is checked on startup to detect tampering with the on-disk payload. - **Data at rest:** The application can detect unexpected changes to sensitive files between runs (integrity monitoring around identities and database state). - **Web surface:** Content Security Policy is applied in depth across the stack. - **Containers:** Images are intended to run **without root** inside the container where the platform supports it. +- **External code (SRI):** Any WebAssembly or external JavaScript loaded at runtime (micron-parser-go, Codec2, RNode flasher libraries) is verified with **SHA-384 Subresource Integrity (SRI)** before execution. If a hash mismatch is detected, the code is blocked and an error is thrown. This prevents a compromised or malicious WASM binary (for example, a keylogger) from running even if an attacker replaces files on disk. ### Build, supply chain, and transparency -- **CI:** Automated pipelines (hosted on GitHub Actions) run dependency and configuration scanning (including **Trivy** and **pip-audit** on relevant paths), build checks, and security-relevant automated tests (authentication, path safety on dangerous operations, schema upgrades, backup/restore, rate limiting and access logging, and related areas). +- **CI:** Automated pipelines (hosted on GitHub Actions) run dependency and configuration scanning (including **Trivy** and **pip-audit** on relevant paths), build checks, and security-relevant automated tests (authentication, path safety on dangerous operations, schema upgrades, backup/restore, rate limiting and access logging, and related areas). SRI integrity tests verify that external WASM/JS files match their declared hashes without regenerating the integrity manifests. CI will fail if you update these files without regenerating the integrity manifests. - **Action pinning:** Third-party GitHub Actions are referenced with **pinned commit SHAs** in workflow definitions to reduce unexpected upgrades. - **Releases:** Tagged release artifacts for Linux, Windows, and macOS are produced in CI. **SLSA Build Level 3–style provenance** for those artifacts is generated via the **generic** SLSA GitHub generator (`generator_generic_slsa3.yml` at release **v2.1.0**), which satisfies the **isolated builder and signed provenance** expectations for that tier; **distribution** (draft releases, mirrors) and **consumer verification** remain your operational controls, as described in upstream SLSA documentation. - **Transparency logs:** Many Sigstore flows write to the **public Rekor** log (`https://rekor.sigstore.dev` by default). **Repository-key** `*.cosign.bundle` files next to release artifacts are built **without** a Rekor entry; with **Cosign v3+**, verify them against `cosign.pub` using `cosign verify-blob-attestation` and `--insecure-ignore-tlog=true` (signature and predicate are still checked against the public key). Private-repo or air-gapped policies may require different Sigstore settings; operators should align `COSIGN_REKOR_URL` and related variables with their own governance.