Skip to content

Security: Open-NV/opennv-validation

Security

SECURITY.md

Security policy

Reporting a vulnerability

Please do not open a public issue for suspected vulnerabilities or sensitive data exposure. Use GitHub's private vulnerability reporting / Security Advisory workflow for this repository. Include the affected revision, impact, reproduction steps using synthetic data, and any known mitigation.

Never submit credentials, tokens, production inventory, raw production CLI output, customer identifiers, or reachable management addresses. If private reporting is unavailable, contact an OpenNV organization owner privately and ask for a secure reporting channel before sharing details.

Supported versions

Until the first stable release, security fixes are applied to the latest main revision. Operators should pin immutable commits or release tags and review security notes before upgrading.

Deployment boundary

OpenNV reaches privileged network-management interfaces and stores execution evidence. A production deployment must use private networking, strict ingress and egress controls, TLS at the service boundary, least-privilege read-only device accounts, SSH host-key verification, external secret management, bounded workloads, encrypted storage, backups, and an explicit evidence retention policy.

OPENNV_DEMO_MODE=true is for local evaluation. In-memory state is not durable, and demo behavior is not proof of production authentication, persistence, throughput, or device compatibility.

The executor has additional transport and dependency guidance in executor/SECURITY.md. Changes to authentication, repository/inventory URL validation, Git checkout, OutputFSM activation, command admission, expression evaluation, raw-output handling, or cancellation are security-sensitive and require negative tests.

There aren't any published security advisories