Veramem is designed as a security-first, deterministic, and verifiable truth kernel.

Security is a foundational property of the system.
We welcome responsible disclosure and collaboration with the security and cryptography community.

At the moment, the latest stable release of Veramem is supported.

Security patches will be prioritized for:

• the latest release,
• critical vulnerabilities affecting protocol integrity.

Earlier versions may not receive fixes unless they impact core protocol safety.

If you believe you have found a security vulnerability, please do not open a public issue.

Instead, report it privately:

• Email: jlefauconnier@proton.me
• Subject: [VERAMEM SECURITY]

Include:

• a clear description,
• affected components,
• potential impact,
• proof-of-concept if available,
• reproducibility steps.

We aim to acknowledge reports within 72 hours.

We follow a coordinated disclosure process:

1. Report privately.
2. We validate and assess impact.
3. A fix is developed.
4. Coordinated disclosure timeline is agreed.
5. Public advisory is released.

Researchers will be credited unless anonymity is requested.

Security applies to:

• protocol correctness,
• deterministic encoding,
• commitment integrity,
• signal lineage safety,
• distributed convergence,
• attestation and trust,
• replay resistance,
• adversarial resilience.

Out of scope:

• vulnerabilities in third-party infrastructure,
• unrelated application-level misuse.

Veramem follows these core principles:

All protocol operations must be reproducible.

Every state must be auditable and cryptographically verifiable.

The system assumes adversarial environments.

Hidden or implicit state is avoided.

Sensitive data should never be exposed in plaintext when not required.

The kernel assumes:

• malicious participants,
• network adversaries,
• Byzantine environments,
• compromised devices,
• replay and rollback attacks,
• data tampering.

See:

• security/KERNEL_THREAT_MODEL.md

Key properties:

• deterministic commitments,
• domain separation,
• replay protection,
• forward compatibility.

Cryptographic changes require:

• security analysis,
• formal justification,
• interoperability considerations.

Device and node trust must:

• be explicit,
• be verifiable,
• resist replay,
• support distributed trust.

See:

• security/DEVICE_ATTESTATION_MODEL.md

We aim to:

• minimize dependencies,
• ensure reproducible builds,
• prevent hidden behavior.

Future roadmap includes:

• signed releases,
• deterministic packaging,
• transparency logs.

The project encourages:

• adversarial testing,
• fuzzing,
• property-based testing,
• formal verification.

See:

• VERAMEM_FORMAL_VERIFICATION_PLAN.md

Planned improvements:

• side-channel analysis,
• memory safety strategies,
• cryptographic agility,
• distributed consensus safety,
• long-term post-quantum migration.

Veramem is intended for:

• privacy-preserving systems,
• cognitive integrity,
• user autonomy.

It is not designed for:

• mass surveillance,
• coercive monitoring,
• opaque centralized control.

This security policy does not grant authorization to:

• access private infrastructure,
• perform denial-of-service attacks,
• violate applicable laws.

Researchers must respect applicable regulations.

We believe security is a collaborative effort.

We welcome:

• academic researchers,
• cryptographers,
• distributed systems experts.

Thank you for helping make Veramem a secure and trustworthy system.