Marmeon

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Every change lands on main through a public pull request (https://github.com/marmeon/marmeon/pulls?q=is%3Apr), reviewed and checked by CI before it is squash-merged; the full commit history between releases is public in https://github.com/marmeon/marmeon/commits/main. Release candidates (1.0.0-rc.1 to rc.8) were also published on npm under the dist-tag next.

Repository on GitHub, which uses git. git is distributed.

Every release has a unique version shared by all packages (e.g. 1.0.0), published on npm and tagged in git as an annotated tag v<version> with a GitHub Release (https://github.com/marmeon/marmeon/releases). Tags are protected against updates and deletion by a repository ruleset.

Each release is identified by an annotated git tag v<version> on its release commit, created by the release workflow (https://github.com/marmeon/marmeon/tags), for example v1.0.0.

Each release has release notes on its GitHub Release (https://github.com/marmeon/marmeon/releases/tag/v1.0.0) and in each package's CHANGELOG.md, grouped into breaking changes, features, fixes and documentation; each entry is a pull request title written as a release note, not a raw git log. Upgrade impact is described in UPGRADING.md (https://github.com/marmeon/marmeon/blob/main/UPGRADING.md), where every breaking change has an entry rated High/Medium/Low with its likelihood of impact and the steps an app has to take.

No publicly known vulnerability with a CVE or similar identifier has been fixed in a Marmeon release yet (no published advisories: https://github.com/marmeon/marmeon/security/advisories). When one is, SECURITY.md commits to publishing the GitHub advisory with the fixed release and requesting a CVE where it applies; the release notes will name it.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/marmeon/marmeon/blob/main/SECURITY.md. [osps_do_02_01]

GitHub Issues: https://github.com/marmeon/marmeon/issues

No bug reports have been submitted yet: the issue tracker (https://github.com/marmeon/marmeon/issues) has no issues so far, as the project only became public recently. Reports are answered by the maintainer; security reports within five working days (SECURITY.md).

No enhancement requests have been submitted yet, neither as issues (https://github.com/marmeon/marmeon/issues) nor in Discussions (https://github.com/marmeon/marmeon/discussions); the project only became public recently. Requests will be answered there by the maintainer.

All reports and responses are public and searchable on GitHub: issues at https://github.com/marmeon/marmeon/issues (including closed ones), discussions at https://github.com/marmeon/marmeon/discussions, and the review of every change in its pull request (https://github.com/marmeon/marmeon/pulls?q=is%3Apr). Published security advisories appear at https://github.com/marmeon/marmeon/security/advisories.

https://marmeon.com/docs/security-policy (also SECURITY.md at https://github.com/marmeon/marmeon/security/policy): vulnerabilities are reported privately through GitHub's private vulnerability reporting (https://github.com/marmeon/marmeon/security/advisories/new) or by mail to security@marmeon.com, with what to include, the response time, the coordinated disclosure process and the supported versions.

https://marmeon.com/docs/security-policy (SECURITY.md, https://github.com/marmeon/marmeon/security/policy): reports go through GitHub's private vulnerability reporting (https://github.com/marmeon/marmeon/security/advisories/new), which only the maintainers can see, or by mail to security@marmeon.com, read only by the maintainers. The policy asks reporters never to use a public issue, pull request or discussion.

No vulnerability reports have been received in the last 6 months (no private reports or advisories in https://github.com/marmeon/marmeon/security/advisories). SECURITY.md commits to an initial response within five working days.

The packages are built from source with one command: pnpm install --frozen-lockfile && pnpm build (CONTRIBUTING.md › Set up: https://github.com/marmeon/marmeon/blob/main/CONTRIBUTING.md#set-up). CI rebuilds everything on every pull request, and builds are reproducible: pnpm release:verify <commit> rebuilds a release commit and checks that the result is byte for byte the tarballs published on npm (https://github.com/marmeon/marmeon/blob/main/CONTRIBUTING.md#releasing).

The build uses common tools of the TypeScript/Node.js ecosystem: pnpm (workspaces, frozen lockfile), the TypeScript compiler (tsc -b with project references) and Vite for client bundles; npm publishes the packages. pnpm build wraps them; nothing project-specific is needed to build from source.

All build tools are FLOSS: Node.js (MIT), pnpm (MIT), TypeScript (Apache-2.0) and Vite (MIT); every build and dev dependency comes from npm under an open-source licence. No proprietary tool is needed to build or test.

The Vitest test suites (MIT, in the repository next to the code under the project's MIT licence) cover every package, plus suites against real Postgres, Redis and S3 services and end-to-end tests of the apps. How to run them is documented in CONTRIBUTING.md (https://github.com/marmeon/marmeon/blob/main/CONTRIBUTING.md#before-you-open-a-pull-request and #the-test-suites-against-real-services): pnpm test, pnpm test packages/<name>, pnpm test:pgsql, pnpm test:redis; pnpm run ci runs everything CI runs. The CI workflow (https://github.com/marmeon/marmeon/blob/main/.github/workflows/ci.yml) runs them on every pull request.

The tests run with the standard command of the JavaScript ecosystem: pnpm test (the "test" script in package.json, which runs Vitest). Single packages or files take a path: pnpm test packages/<name>.

Every change comes with tests (CONTRIBUTING.md: behaviour in Vitest, type guarantees as @ts-expect-error tests, a feature shown in the example app), and CI rejects changes that break them. The suites have 580+ test files next to the code, including suites against real Postgres, Redis and S3 services, end-to-end tests of the example apps and smoke tests of the packed tarballs; security-relevant inputs (validation, cookies, signed URLs, sessions, CSRF, uploads) are tested for their failure cases.

Every change is integrated into main through a pull request; GitHub Actions (https://github.com/marmeon/marmeon/actions/workflows/ci.yml) runs build, typecheck, lint, the unit and integration test suites (including Postgres, Redis and S3), API and release checks, workflow analysis (zizmor) and packed-tarball smoke tests on every pull request and push to main. A ruleset on main requires these checks to pass before merging.

CONTRIBUTING.md › Before you open a pull request (https://github.com/marmeon/marmeon/blob/main/CONTRIBUTING.md#before-you-open-a-pull-request): "Tests come with the change — type guarantees as @ts-expect-error tests, behaviour in Vitest, a feature shown in apps/web-app." The same rule is in AGENTS.md for coding agents, and review rejects a change without its tests.

The most recent feature pull requests all came with tests:

• #756 Add LIVE_DRIVER=database for live updates without Redis — 12 test files (https://github.com/marmeon/marmeon/pull/756)
• #752 Give every new app storage, live updates and notifications — 10 test files (https://github.com/marmeon/marmeon/pull/752)
• #755 Accept a @graph block in <Head jsonLd> — 2 test files (https://github.com/marmeon/marmeon/pull/755)
  Every merged pull request passed the full test suite in CI (https://github.com/marmeon/marmeon/pulls?q=is%3Apr+is%3Amerged).

The policy is part of the instructions for pull requests: CONTRIBUTING.md › Before you open a pull request (https://github.com/marmeon/marmeon/blob/main/CONTRIBUTING.md#before-you-open-a-pull-request) lists "Tests come with the change" among the requirements for every change, and AGENTS.md repeats it for coding agents.

TypeScript runs in its strictest modes (tsconfig.base.json: strict, noUncheckedIndexedAccess, noImplicitOverride, noFallthroughCasesInSwitch, verbatimModuleSyntax, erasableSyntaxOnly), and the code is linted with oxlint --deny-warnings (correctness rules as errors, plus eslint-plugin-regexp rules that refuse super-linear regular expressions in package code). Both run in CI on every pull request (pnpm run ci --only typecheck,lint); see CONTRIBUTING.md › Lint (https://github.com/marmeon/marmeon/blob/main/CONTRIBUTING.md#lint).

Warnings fail the build: oxlint runs with --deny-warnings and the TypeScript compiler's errors fail typecheck, both required checks on main. A lint rule may only be disabled with a written reason, which pnpm check:source enforces (CONTRIBUTING.md › Rules over the source, rule 13: https://github.com/marmeon/marmeon/blob/main/CONTRIBUTING.md#rules-over-the-source-pnpm-checksource).

Warnings are treated as errors (oxlint --deny-warnings), TypeScript uses strict plus the stricter flags beyond it (noUncheckedIndexedAccess, noImplicitOverride, noFallthroughCasesInSwitch, erasableSyntaxOnly), every lint-disable needs a written reason enforced by check:source, and a test (scripts/lint.test.ts) makes sure the regexp lint plugin keeps reporting, so a rule cannot silently stop working.

The project's lead developer designs for these principles, and the framework's documented design shows them (https://marmeon.com/docs/security):

• Fail-safe defaults: "Secure by default" is a core principle; protections fail closed outside development (https://marmeon.com/docs/security#the-environment-decides-and-fails-closed), development routes exist only in development, signed-in pages are never cached. API tokens cannot be created without explicit abilities and an expiry.
• Complete mediation: CSRF checks, session and token verification and authorization policies run on every request in the pipeline, not per call site.
• Open design: security rests on keys (APP_KEY rotation, encryption with a bound context, signed URLs with expiry), not on hidden mechanisms.
• Separation of privilege: two-factor authentication and passkeys are built in; an API token's abilities are checked on top of its user's authorization policies, so both must allow an action.
• Least privilege: API tokens carry abilities and expiries (https://marmeon.com/docs/api-tokens); CI workflows start with permissions: {} and grant per job only what they need.
• Least common mechanism: no global state, one scope per request or job.
• Economy of mechanism / limited attack surface: one endpoint per class, few public entry points, a public API checked against a snapshot.
• Input validation with allowlists: request bodies and queries are validated against declared schemas, and fields the schema does not name are dropped before the controller sees the data (https://marmeon.com/docs/validation).
• Psychological acceptability: the secure path is the default and the shortest one in the API.

The lead developer knows the common vulnerability classes of web frameworks (OWASP Top 10, CWE Top 25), and the framework ships a mitigation for each:

• SQL injection: queries go through a typed query builder with bound parameters; raw SQL is documented with its risks (https://marmeon.com/docs/security#secret-columns-and-raw-sql).
• Cross-site scripting: React escapes output, and a nonce-based Content Security Policy is on by default (https://marmeon.com/docs/csp).
• Cross-site request forgery: CSRF protection on every state-changing request (https://marmeon.com/docs/csrf).
• Missing authentication / authorization: authentication middleware and policies per route and per record (https://marmeon.com/docs/authentication, https://marmeon.com/docs/authorization); signed-in pages are never cached.
• Broken session and credential handling: secure, HTTP-only cookies, password hashing, two-factor authentication and passkeys, tokens with abilities and expiries, rate limiting on sign-in (https://marmeon.com/docs/rate-limiting).
• Account enumeration: lookups by address answer the same for known and unknown accounts.
• Injection of untrusted input generally: request data is validated against allowlist schemas before it reaches the controller (https://marmeon.com/docs/validation).
• Path traversal: storage path guards fail closed.
• Regular-expression denial of service: lint rules refuse super-linear regular expressions in package code.
• Sensitive data exposure: secrets are kept out of logs and recordings; HSTS is supported (https://marmeon.com/docs/security#logs-and-recordings).
• Supply chain: dependencies pinned, releases built reproducibly with npm provenance, GitHub Actions pinned by SHA.

All defaults use published, expert-reviewed algorithms from Node's node:crypto (OpenSSL); the project implements no cryptographic primitive of its own:

• Encryption: AES-256-GCM (authenticated), keys derived with HKDF (https://marmeon.com/docs/encryption).
• Password hashing: Argon2id with OWASP's recommended costs by default, scrypt as the alternative (https://marmeon.com/docs/hashing).
• Signed URLs, cookies and tokens: HMAC-SHA-256 and SHA-256 (https://marmeon.com/docs/urls).
• Two-factor authentication: TOTP per RFC 6238; passkeys per WebAuthn.

Marmeon calls node:crypto (OpenSSL) for every cryptographic function: ciphers, HMAC, hashes, key derivation, Argon2id/scrypt, signature verification and random values. It implements no cryptographic primitive itself; protocol code on top (TOTP per RFC 6238, WebAuthn verification) only combines node:crypto calls as the specifications describe.

All cryptography comes from Node.js's node:crypto, which is built on OpenSSL (Apache-2.0); Node.js itself is MIT. No proprietary library or service is needed for any cryptographic function.

Every key length is fixed at or above the NIST SP 800-57 (2012) minimum for 2030 (112-bit security), and no smaller one can be configured: encryption uses AES-256-GCM with a 32-byte APP_KEY (a shorter key refuses to start), signatures and tokens use HMAC-SHA-256, passwords use Argon2id (scrypt as the alternative) with random salts, TOTP uses HMAC-SHA1 per RFC 6238 with a 160-bit secret, and passkeys accept only ES256, EdDSA and RS256. RSA passkeys must have at least 2048 and at most 4096 bits, at registration and at sign-in, since 1.1.0. https://marmeon.com/docs/passkeys

No default security mechanism uses a broken algorithm or an inappropriate mode: encryption is AES-256-GCM (authenticated, a fresh random IV per message), signatures HMAC-SHA-256, password hashing Argon2id or scrypt, passkeys ES256/EdDSA/RS256. MD5 appears only in test fixtures, never in shipped code. TOTP uses HMAC-SHA-1 because RFC 6238 and every authenticator app require it; HMAC-SHA-1 is not affected by the known SHA-1 collision attacks. SHA-1 also names Lua scripts for Redis's EVALSHA, as an identifier with no security role.

The default mechanisms use SHA-256, AES-256-GCM, Argon2id and modern signature algorithms. SHA-1 is used in exactly two places, neither as a collision-resistant hash: (1) TOTP two-factor codes use HMAC-SHA-1, because RFC 6238 and practically every authenticator app support only that; HMAC's security does not rest on SHA-1's collision resistance, and no practical attack on HMAC-SHA-1 is known. (2) Redis identifies Lua scripts by their SHA-1 for EVALSHA, a name with no security role. No CBC mode is used.

Marmeon implements no key agreement protocol of its own. Transport encryption is TLS, provided by Node.js (OpenSSL) or by the reverse proxy in front of the app; Node's defaults negotiate TLS 1.2/1.3 with ephemeral (EC)DHE key exchange only, so sessions have forward secrecy, and TLS 1.3 always does. Data encrypted at rest with APP_KEY is not a key agreement and is protected by key rotation instead (https://marmeon.com/docs/encryption).

Passwords are stored only as Argon2id hashes by default (OWASP's recommended costs: 19 MiB, 2 passes, 1 lane), with scrypt (N=2^17, r=8, p=1) as the alternative; each hash gets a fresh random salt from crypto.randomBytes and is stored in PHC string format. Hashes are upgraded on the next successful sign-in when the driver or costs change (https://marmeon.com/docs/hashing).

All keys, nonces, IVs, salts, tokens, CSP nonces and recovery codes come from node:crypto's CSPRNG (crypto.randomBytes, randomUUID, randomInt, getRandomValues). Math.random appears in shipped code only for non-security purposes: unique names of temporary files written next to build artifacts, and jitter between retries.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The project never delivers hashes over plain HTTP. Packages are published to npm over HTTPS with signed npm provenance attestations (Sigstore) from the release workflow; npm verifies each tarball's SHA-512 integrity from the lockfile. The release's SHA512SUMS are created by the GitHub Actions release workflow and served over HTTPS, and pnpm release:verify rebuilds and compares them against the published tarballs.

No vulnerability of medium or higher severity in Marmeon has been publicly known without a fix (no advisories: https://github.com/marmeon/marmeon/security/advisories). Two moderate advisories in transitive dependencies of the mail rendering chain (GHSA-3g3m-2fjr-6pw4 in glob, GHSA-g3hv-75wg-m249 in minimatch, both published 2026-10-30) are not exploitable through Marmeon: the affected code paths are only used by js-beautify's command line and for .editorconfig patterns. They are tracked, and will be resolved once the upstream packages (js-beautify, editorconfig) allow the fixed major versions, or overridden before the 60-day mark.

SECURITY.md commits to acknowledging a report within five working days, fixing it in a private advisory fork and releasing the fix for all supported versions with a published advisory (https://marmeon.com/docs/security-policy). The release process supports out-of-band patch releases on the current line and on older lines under latest-<major> (https://marmeon.com/docs/releases#which-versions-get-fixes); builds are reproducible and published from CI with provenance, so a fix can ship within hours. No critical vulnerability has been reported so far.

No valid credentials are in the repositories. GitHub secret scanning and push protection are enabled and report no open alerts; secrets come only from environment variables (.env files are git-ignored; .env.example holds placeholders). Test fixtures that look like tokens are assembled at run time so they never appear as literals, and release publishing uses npm trusted publishing (OIDC) with no token stored anywhere.

CodeQL code scanning (security-extended queries for JavaScript/TypeScript) runs on every pull request and every push to main (https://github.com/marmeon/marmeon/blob/main/.github/workflows/codeql.yml), so every release commit has been analysed; the OpenSSF Scorecard rates SAST 10/10. In addition, oxlint (with eslint-plugin-regexp's ReDoS rules) lints every change, and zizmor statically analyses the GitHub workflows.

CodeQL runs with the security-extended query suite (https://github.com/marmeon/marmeon/blob/main/.github/codeql/codeql-config.yml), which looks for the common vulnerability classes of JavaScript/TypeScript: injection (SQL, command, code), cross-site scripting, path traversal, prototype pollution, ReDoS, insecure randomness, open redirects, missing CSRF protection and more. The lint configuration adds eslint-plugin-regexp's rules against super-linear regular expressions (ReDoS) in package code, and zizmor checks the workflows for injection and privilege problems.

CodeQL findings are triaged as they appear: there are no open CodeQL alerts; 23 alerts were fixed in code and the remaining ones were dismissed on GitHub with a written reason (false positives or test-only code), never suppressed in the code (policy in https://github.com/marmeon/marmeon/blob/main/.github/codeql/codeql-config.yml). The scan runs on every pull request, so a new finding blocks attention before merge.

CodeQL runs on every pull request, on every push to main and once a week (to apply new queries to existing code); oxlint and zizmor run in CI on every pull request and push (https://github.com/marmeon/marmeon/blob/main/.github/workflows/codeql.yml, https://github.com/marmeon/marmeon/blob/main/.github/workflows/ci.yml). The OpenSSF Scorecard confirms: "SAST tool is run on all commits".

Marmeon is written entirely in TypeScript, a memory-safe language; it ships no C, C++ or native addons.

The test suites run with many assertions enabled that production does not run: thousands of Vitest assertions, type-level assertions (@ts-expect-error tests checked by the compiler), and run-wide checks that fail a test run on an unhandled rejection or error, on a test that leaves a temporary directory behind, and on a retried test. Development and test environments add checks of their own (development-only routes and diagnostics), which are off in production.

No dedicated dynamic analysis tool is run yet, so none has reported a vulnerability. Vulnerabilities found by any means are handled under the security policy: acknowledged within five working days, fixed in a private advisory and released for all supported versions (https://marmeon.com/docs/security-policy).