To report a potential security vulnerability in any NVIDIA product, please use either:

• This web form: Security Vulnerability Submission Form, or
• Send email to: NVIDIA PSIRT

If reporting a potential vulnerability via email, please encrypt it using NVIDIA’s public PGP key (see PGP Key page) and include the following information:

1. Product/Driver name and version/branch that contains the vulnerability
2. Type of vulnerability (code execution, denial of service, buffer overflow, etc.)
3. Instructions to reproduce the vulnerability
4. Proof-of-concept or exploit code
5. Potential impact of the vulnerability, including how an attacker could exploit the vulnerability

See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins and Notices.

NVIDIA PSIRT triages every report and coordinates any resulting fix and disclosure under NVIDIA's coordinated vulnerability disclosure process. What that process covers — how reports are evaluated, and what NVIDIA does and does not commit to — is described on the NVIDIA PSIRT policies page. Snapshot does not set separate terms; that policy governs. Note in particular that NVIDIA does not guarantee a specific resolution for every reported issue.

With the reporter's agreement, NVIDIA PSIRT may recognize them for a valid, privately reported vulnerability — on NVIDIA's acknowledgement page, or in the security bulletin for the issue. Recognition is discretionary and arranged by PSIRT as part of the process above. It is never given through GitHub Security Advisories; Snapshot does not publish those.

From v0.2.0 on, every published artifact — the operator image, the agent image, and the Helm chart — is signed in CI with Sigstore cosign keyless signing. Earlier releases predate the signing pipeline and carry SBOMs only; they are not signed retroactively. There is no key to distribute: the signing identity is this repository's release workflow, and each signature is recorded in the public Rekor transparency log. Images additionally carry SLSA provenance and an SBOM as OCI attestations, and each release ships SPDX and CycloneDX SBOMs alongside a signed SHA256SUMS.

Before trusting a pulled image or chart, verify it. The exact cosign verify and cosign verify-blob invocations, including the certificate identity to require, are in RELEASE.md. Verification needs cosign v3.0 or newer.

Be precise about what each part establishes. The signature identifies the workflow that produced the artifact — this repository's release workflow at a release tag — and nothing more. The source commit is recorded in the SLSA provenance attestation, so tying an artifact to a commit means reading the provenance as well as checking the signature; RELEASE.md shows both. Neither is a statement that the artifact is free of vulnerabilities — for that, report anything you find through the process above.

Snapshot is pre-1.0. Security fixes are applied to the most recent minor release line only.

If you are running a pre-release or an older patch version, upgrade to the latest patch release on the supported line to pick up a fix. This policy is revisited at 1.0, when more than one line may be supported at a time.