rules-vault

Potentially unsafe pattern detected in vault code: "tls_disable = 1". Review the use case — this may indicate a security risk, a deprecated API, or a misconfiguration. Confirm the write is intentional.

RISK: tls_disable=1 in a Vault listener config transmits tokens, secrets, and leases in plaintext — any network observer can steal Vault tokens and decrypt all secrets. FIX: configure a valid TLS certificate in the listener block ('tls_cert_file' + 'tls_key_file') and set tls_disable=0 (or remove the directive, as TLS is on by default).

You are using an outdated API for vault. Please upgrade to the newer API.

RISK: Running Vault without an enabled audit device means there is no tamper-evident log of secret reads, token creation, or policy changes — a requirement for SOC 2 CC7.3 and PCI-DSS. FIX: enable at least one audit device ('vault audit enable file file_path=/var/log/vault/audit.log') and monitor the log for anomalies.

RISK: Vault dev mode runs with an in-memory backend, a well-known root token ('root'), TLS disabled, and auto-unsealed — every secret is ephemeral and the instance is trivially compromised. FIX: never deploy dev mode outside a local developer sandbox; use a persistent backend (Raft, Consul) with proper unsealing and ACL policies.

RISK: Hardcoding a Vault root or initial-root token in a config file, .env, or Terraform state commits a credential that has unrestricted access to every secret in the Vault cluster. FIX: rotate the root token immediately, store it in a hardware-secured credential store, and use Vault agent or short-lived AppRole tokens for application auth.

RISK: A hardcoded Vault unseal key in source code or config allows anyone with repo access to unseal the Vault without quorum — destroying the security model of Shamir's secret sharing. FIX: store unseal keys in separate, access-controlled vaults (KMS, HSM, or a separate Vault instance) and never commit them; use auto-unseal (AWS KMS, GCP KMS, Azure Key Vault) for production.