Security

September 9, 2026 ยท View on GitHub

NVIDIA is dedicated to the security and trust of our software products and services, including all source code repositories.

Please do not report security vulnerabilities through GitHub.

Reporting Security Vulnerabilities

To report a potential security vulnerability in any NVIDIA product:

Include in your report:

  • Product/Driver name and version
  • Type of vulnerability (code execution, denial of service, buffer overflow, etc.)
  • Steps to reproduce
  • Proof-of-concept or exploit code
  • Potential impact and exploitation method

NVIDIA offers acknowledgement for externally reported security issues under our coordinated vulnerability disclosure policy. Visit PSIRT Policies for details.

Supported Versions

NVSentinel does not currently maintain long-term-support branches. Security and bug fixes are applied to the main branch and released as part of the latest tagged release; only the most recent release receives fixes. See RELEASE.md for the release process, including the emergency hotfix procedure used for urgent fixes.

Product Security Resources

For all security-related concerns: https://www.nvidia.com/en-us/security

Supply Chain Security

NVSentinel provides supply chain security artifacts for all container images:

  • SBOM Attestation: Complete inventory of packages, libraries, and components
  • SLSA Build Provenance: Verifiable build information (how and where images were created)

Setup

Export variables for the image you want to verify, for example:

export IMAGE="ghcr.io/nvidia/nvsentinel/fault-quarantine"
export DIGEST="$(crane digest "$IMAGE:v1.22.0")"
export IMAGE_DIGEST="$IMAGE@$DIGEST"

Authentication (if needed):

docker login ghcr.io

CycloneDX SBOM (Software Bill of Materials)

A Software Bill of Materials (SBOM) provides a detailed inventory of all components in a container image. NVSentinel generates SBOMs in CycloneDX JSON format with Syft, and attaches each one to its image as a Sigstore attestation:

cosign attest --predicate sbom-<component>.cdx.json --type cyclonedx "$IMAGE_DIGEST"

Retrieve the SBOM attestation:

cosign verify-attestation \
  --type cyclonedx \
  --certificate-identity-regexp '^https://github\.com/NVIDIA/NVSentinel/\.github/workflows/publish\.yml@refs/(heads|tags)/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  "$IMAGE_DIGEST" \
  | jq -r .payload | base64 -d | jq .predicate

That identity is the same one the in-cluster policies enforce, so a check that passes here matches what the admission controller will accept.

Images are not signed with cosign sign, so there is no standalone image signature to verify. Verifying this attestation authenticates the SBOM contents โ€” it does not establish how the image was built. Build provenance comes from the SLSA attestation below.

SLSA Build Provenance

SLSA (Supply chain Levels for Software Artifacts) provides verifiable information about how images were built.

NVSentinel images include SLSA Build Provenance attestations that can be verified both manually (using CLI tools) and automatically (using Kubernetes admission policies).

The quickest check uses the GitHub CLI, which needs no local tooling beyond gh:

gh attestation verify oci://ghcr.io/nvidia/nvsentinel/fault-quarantine:v1.22.0 \
  --repo NVIDIA/NVSentinel \
  --signer-workflow NVIDIA/NVSentinel/.github/workflows/publish.yml

A successful run reports the predicate type https://slsa.dev/provenance/v1 and the workflow that produced the image, for example .github/workflows/publish.yml@refs/tags/v1.22.0.

Refer to distros/kubernetes/nvsentinel/policies/README.md for:

  • Manual verification commands using cosign or gh CLI
  • Automated in-cluster verification using Sigstore Policy Controller
  • Installation and configuration instructions