Email: privacy@paramant.app Subject: Security vulnerability — paramant-relay

We aim to respond within 48 hours and patch within 7 days for critical issues. All reports are treated with responsible disclosure.

We do not currently publish a PGP key. If your report is sensitive, email privacy@paramant.app and we will arrange an encrypted channel.

When a key is published it will be served at https://paramant.app/.well-known/openpgp-key.asc and its fingerprint listed here. Until then, treat any PGP key that claims to be ours as unverified and confirm through a separate channel before sending anything sensitive.

10 findings, all resolved.

114 checks applied across 13 categories on paramant.app:

14 findings, all resolved in commit e6f216d.

6 findings, all resolved in commit 0db3ef0.

20 findings across 4 critical / 5 high / 6 medium / 5 low. Full report: docs/security-audit-2026-04.md

Scope: TOTP reset flow abuse protection, error response hardening, rate limit verification, email template security review.

Scope: Static code analysis, authentication flows, network and infrastructure, active penetration testing, cryptographic implementation review, business logic, load testing.

Load test results (tool: hey, target: https://paramant.app/):

Next audit: External third-party penetration test planned before public general availability.

Before Mission 4, tamper-evidence depended on trusting Paramant's own servers:

"Trust Paramant's servers"

After Mission 4, the trust model is:

"Trust that at least one relay operator is honest"

This is the same trust model as RFC 6962 Certificate Transparency. Any relay operator running paramant-verify-peers becomes an independent auditor.

Every change to the CT log produces a Signed Tree Head (STH) — an ML-DSA-65 signed commitment to the current Merkle root:

{
  "version": 1,
  "relay_id": "https://health.paramant.app",
  "tree_size": 59,
  "sha3_root": "deed04dd...",
  "timestamp": 1713000000000,
  "signature": "<base64 ML-DSA-65 over canonical JSON>"
}

Signature is over the canonical JSON of {relay_id, sha3_root, timestamp, tree_size, version} (keys sorted). Signed with the relay's ML-DSA-65 identity key (NIST FIPS 204).

After every STH is produced, the relay broadcasts it to all registered peers:

POST /v2/sth/ingest
Body: { relay_id, sha3_root, timestamp, tree_size, version, signature, public_key, relay_pk_hash }

• Receiver verifies ML-DSA-65 signature before storing
• Invalid signatures are logged and rejected (HTTP 400)
• Valid STHs are stored in data/peer-sths/{relay_pk_hash}.jsonl
• Non-blocking, best-effort — peer failures do not affect the local relay

GET /v2/sth/consistency?from=<old_size>&to=<new_size> returns an RFC 6962-style proof that the new tree contains the old tree as a prefix. This is the key property that prevents a relay from "rewinding" its log.

# Verify no entries were removed or reordered between size 10 and current
curl "https://health.paramant.app/v2/sth/consistency?from=10" | jq .

Subscribe to /ct/feed.xml with any RSS reader to independently archive STH roots:

https://health.paramant.app/ct/feed.xml

If a relay later claims a different root for a published timestamp, any subscriber has cryptographic proof of the original commitment.

# Install
npm install -g @noble/post-quantum  # required for ML-DSA-65

# Verify all peer STHs are consistent
paramant-verify-peers --relay https://health.paramant.app

# Exit 0 = all consistent (or 0 peers)
# Exit 1 = inconsistency detected

The tool:

1. Fetches the peer STH mirror from the local relay
2. Verifies ML-DSA-65 signatures on each peer's latest STH
3. Cross-checks by fetching the STH directly from the peer relay
4. Checks for tree_size rollbacks (append-only violation)
5. Reports inconsistencies with full details

Additional fixes applied 2026-04-13:

• 0 npm vulnerabilities across all 4 packages
• Base image: node:22-alpine (node:20 was EOL)
• express 4.x → 5.x
• 0 GPL/AGPL/LGPL licenses
• 0 hardcoded secrets

What: gitleaks scan revealed historical credential exposure.

Remediation: Server .env permissions hardened to 600; gitleaks pre-commit hook installed.

Note on git history: Historical commits still contain the now-invalid credentials. Rewriting history would break existing clones with no security benefit since the credentials are revoked. Documented here for transparency.

Paramant maps technical controls to NIS2 (EU 2022/2555), IEC 62443 (industrial control systems), and NEN 7510 (Dutch healthcare). Mapping documents are part of the standard delivery package for Enterprise customers.

What this means:

• Architecture aligns with the technical requirements of these frameworks (RAM-only storage, post-quantum key exchange, signed CT log, EU-only jurisdiction, no US CLOUD Act exposure).
• Compliance documentation is generated from operational evidence — CT log, deployment artefacts, configuration — and updated per release.
• A signed Data Processing Agreement under GDPR Art. 28 is available to all paid tiers.

What this does NOT mean:

• No external penetration test has been conducted as of the date of this document. The internal automated audit (2026-04-19) and the independent reviews by R. Zwarts and Ryan Williams listed above are not third-party certification.
• No certification body has audited Paramant against ISO 27001, SOC 2, or any of the frameworks mentioned. The mapping documents are operator-generated.
• "Compliant by design" describes architectural alignment, not formal attestation. Customers requiring independent attestation should treat Paramant as a component within their broader ISMS and contract their own auditor.

If you need formal certification or third-party attestation as part of your procurement process, talk to us early — we will work with your auditor and provide the evidence we have, but we will not represent the platform as pre-certified.

• Beta access only; hardening for general public availability is in progress.
• Billing in the bundled admin tool uses optional Stripe device-sync hooks (operator-configured); the hosted paramant.app service uses Mollie.
• Some accounts created before TOTP rollout operate on API-key-only authentication.
• Rate limits have not been validated under sustained adversarial load; no WAF is deployed.
• External third-party penetration test has not yet been conducted.