Add a dry-run validation command for encrypted files

It would be useful to have a dedicated validation mode that verifies whether encrypted SOPS files can be successfully parsed and decrypted with the configured key material, without exposing or writing the decrypted contents.

For example:

sops --validate secrets.yaml

The command could:

• Verify that the file is a valid SOPS-encrypted file.
• Validate the SOPS metadata and encryption structure.
• Confirm that the configured key(s) can decrypt the data.
• Return a non-zero exit code when validation fails.
• Never print decrypted secret values to stdout or stderr.

This would make SOPS files easier to validate in CI/CD pipelines before deployment.

Use case

A CI pipeline may need to verify that encrypted configuration files are valid and decryptable before merging or deploying a change. Currently, users may need to invoke a decryption operation as part of validation, which creates unnecessary risk and makes the intended purpose less explicit.

A dedicated dry-run validation operation would provide a safer and clearer way to perform this check.

Example $ sops --validate secrets/prod.yaml Valid SOPS file: secrets/prod.yaml Decryption key validation: OK

For an invalid or undecryptable file:

$ sops --validate secrets/prod.yaml Error: SOPS validation failed Reason: no configured key can decrypt the file

The command should only report validation status and diagnostic information, never secret contents.

Alternatives considered

Users can currently invoke SOPS decryption and discard the resulting plaintext, but this is less explicit and potentially increases the chance of accidentally exposing decrypted secrets through shell commands, CI logs, temporary files, or debugging output.

CI pipelines could also implement their own validation wrappers, but having this behavior directly supported by SOPS would provide a consistent and safer interface.

Additional context

This would be particularly useful for GitOps and CI/CD workflows where encrypted configuration files are committed to repositories and need to be validated automatically before deployment.

The proposed behavior should remain read-only and must not modify the encrypted file or its metadata.