Skip to content

SECURITY_MODEL.md

Latest commit

 

History

History
62 lines (40 loc) · 4.34 KB

SECURITY_MODEL.md

File metadata and controls

62 lines (40 loc) · 4.34 KB
Raw

Security Model

Scope

No independent third-party security audit has been completed for this project. The documentation and internal checks described here are not an external security certification.

NEXUS-Q Tools is a collection of independent CLI utilities. It is not a security certification, endpoint-protection suite, malware scanner, sandbox, or substitute for operational security. Each tool has a limited responsibility and trust boundary.

Design principles

  • Use public NEXUS-Q Core 4.1.2 APIs for supported hashing, signing, key derivation, authenticated encryption, randomness, and engine lifecycle operations.
  • Do not duplicate cryptographic primitives in tool crates.
  • Prefer read-only inputs and explicit output paths.
  • Reject unsafe paths, symlinks, malformed metadata, and existing destinations where the tool contract specifies.
  • Avoid logging secrets. Passwords must not be passed as command-line arguments.
  • Treat external files, archives, manifests, policies, and command configurations as untrusted input.

Cryptographic workflows

Hashes and integrity manifests

SHA-256 detects byte differences when the expected digest is trusted. A hash or manifest does not authenticate its author, provide confidentiality, or prevent replacement of both data and manifest.

Ed25519 signatures (nq-sign)

Signatures use NEXUS-Q Core's public Ed25519 API. Private key files are plaintext hexadecimal key material; protect permissions, backups, and device access. Verification proves correspondence between signature, supplied public key, and message bytes. It does not establish the real-world identity or trustworthiness of the key owner. Obtain public keys through an independent trusted channel. Signatures do not encrypt data.

Secure backups (nq-secure-backup)

Encrypted mode is the default. It uses Core Argon2id, AES-256-GCM, and OS-backed secure randomness. Passwords are read from a protected regular file, not argv; the in-memory password buffer is zeroized. Keep the password separate from the backup and retain a recovery copy. Losing the password makes encrypted data unrecoverable. Explicit --plain mode provides no confidentiality.

Archive processing is memory-buffered and has documented archive, manifest, and file-count limits. Restore verifies before writing and refuses an existing destination, but a filesystem failure can leave a partial newly created destination.

Local vault (nq-vault)

The content-addressed vault uses Core SHA-256 to identify objects. It is not encrypted storage. Filesystem permissions follow the OS user and umask.

Input and execution boundaries

  • nq-test-runner launches configured program/argument arrays without a shell, but does not sandbox them. Configured programs run with the user's permissions.
  • nq-bundle and nq-verify-bundle process ZIP content. Verification does not extract files; archive content is buffered in memory.
  • nq-policy validates manifest metadata only. It does not inspect actual artifact files.
  • nq-supply-chain inventories Cargo.lock metadata. It does not download dependencies, execute packages, query vulnerability databases, or authenticate publishers.
  • nq-env applies conservative redaction, but cannot guarantee every secret is identified. Review output before sharing.
  • nq-cache-report reports candidate directories; it does not delete or clean them.
  • nq-git-audit reports Git state without changing it.

Threats not addressed

The tools do not protect a compromised OS, malicious administrator, keylogger, compromised compiler/toolchain, malicious distribution channel, stolen unlocked device, weak/reused password, or compromised trusted public key. They do not provide remote attestation or a general-purpose sandbox.

Operational recommendations

  1. Install from the official crates.io pages in CRATES_IO.md.
  2. Verify only against independently trusted digests or public keys.
  3. Protect private keys and password files with restrictive permissions and secure backups.
  4. Use synthetic data for tests and support requests.
  5. Review destinations before commands that create or restore data.
  6. Keep the OS, Rust toolchain, and binaries maintained.
  7. Report vulnerabilities privately according to SECURITY.md.

Security-sensitive workflows require independent review in the intended environment. The project does not claim suitability for every threat model or regulatory requirement.