Security

Review the upstream security policy, threat model, and test vectors when evaluating Ghostable for a sensitive environment. They document the disclosure process, modeled threats and residual risks, and stable cryptographic behavior.

Signatures provide origin and integrity checks. They do not make an authorized but harmful change safe to merge.

Plaintext secret values are encrypted locally before Ghostable writes repository-backed value records. Ghostable does not operate a hosted service that receives those values. Authorized local devices, process memory, generated env files, CI runners, shell or terminal tooling, and deployment providers may receive decrypted values when a user intentionally performs those operations.

• Local machine: private device identities and decrypted process memory exist outside the repository boundary.
• Repository: encrypted values and signed metadata are committed, but repository writers can propose malicious policy or grant changes.
• Automation: GHOSTABLE_CI_TOKEN is an out-of-band secret trusted for its configured grants.
• Deployment providers: Forge, Vapor, Cloud, local files, and injected processes receive plaintext after decryption.

Protected local operations that write, print, inject, validate, or deploy decrypted values require user-presence verification. Explicit production tokens are protected, and neutral names such as preview, staging, qa, and custom names are protected by default. Only names carrying a recognized local, development, test, or CI token use the unprotected fallback. See environment types for the exact classification.

macOS uses LocalAuthentication with Touch ID biometric verification. Linux uses the local PAM-backed sudo confirmation, which may use fingerprint verification when configured. Windows requests Windows Hello or the machine's configured fallback.

A non-interactive local session cannot satisfy this prompt. CI and deployment jobs must use a scoped automation credential. Dry runs that neither write nor print decrypted values do not require confirmation.

Ghostable is designed to resist:

• Passive repository readers without a valid device identity, environment key, or automation credential.
• Undetected modification of signed value, device, policy, access, activity, and key-metadata records.
• Continued authorized use of stale grants after reviewed revocation and key rotation.
• Non-interactive use of production-like local identities without a scoped automation token.

Ghostable is not designed to fully resist:

• A compromised authorized device, process, terminal, editor, or CI runner.
• Plaintext exposure after values are written to files or passed to a deployment provider.
• Reviewers accepting malicious repository changes.
• Secrets placed in annotations, schema descriptions, change reasons, commit messages, or other plaintext metadata.

• Protect local identity stores, CI tokens, and provider credentials.
• Never commit plaintext env files or private identity records.
• Review device, policy, access, suppression, and encrypted-value changes like code.
• Revoke lost or retired identities across all environments; Ghostable rotates the affected environment keys automatically.
• Rotate the underlying database passwords, API keys, or provider credentials when an authorized device or token may have exposed their plaintext.
• Use env clean to reduce local plaintext after sensitive work.
• Keep the CLI updated and reassess the threat model when your workflow changes.