Security Policy

Источник: dev/fera/community/SECURITY.md (read-only; сгенерировано scripts/sync-docs.mjs)

Security Policy

Supported versions

While the project is in closed development (pre-release), the master branch of each repository is the only supported version. Once release lines exist, supported versions are listed here.

Reporting a vulnerability

Do not open a public issue for a security vulnerability.

Report privately via GitHub’s private vulnerability reporting on the affected repository, or contact the maintainers through the private channel in the org’s contact section.

Include what you can of:

• The affected repository and code path.
• Reproduction steps or proof-of-concept.
• Impact assessment — what an attacker gains.
• Any constraints on disclosure (embargo, coordinated timing).

We will acknowledge within 72 hours, keep you informed of the fix progress, and credit you in the advisory (unless you prefer not).

What counts here

The project’s threat surface is broader than a typical application — by design. Worth reporting include:

• Trust chain: manifest signature bypass, downgrade or replay of signed modules, key-substitution paths in the trusted-key store.
• Plugin sandbox: WASM escape, capability escalation (a plugin calling interfaces it was not granted), translator rights-widening.
• Module loading: ABI confusion, load-order attacks, hash-check bypasses.
• Storage/crypto: encryption-tier misassignment, plaintext leaks of content-tier fields, key-derivation weaknesses.
• Lattice: container parsing memory safety, Merkle-verification bypass, decompression bombs.

Hardening that stays within the design’s stated trust model (e.g. “developer mode disables signature checks — by explicit user opt-in”) is not a vulnerability; the model is documented in the design corpus.

Contact

Private GitHub vulnerability reporting on the repository in question is the primary channel. For anything that spans repositories, report on the fera repository.