From 3fb6a3430e837be260fec42760514757a07d991f Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Fri, 2 Oct 2026 22:21:02 +0000 Subject: [PATCH 1/7] docs: Add SECURITY.md TRI-1935 --- SECURITY.md | 148 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..dead8816 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,148 @@ + + +# Security Policy + +## Reporting a Vulnerability + +Please do not report security vulnerabilities through public GitHub issues, +discussions, or pull requests. + +To report a potential security vulnerability in any NVIDIA product, use one of +the following channels: + +* **NVIDIA Vulnerability Disclosure Program** (preferred): + [https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/) +* **Email:** [psirt@nvidia.com](mailto:psirt@nvidia.com). Please encrypt + sensitive reports with NVIDIA's + [PGP key](https://www.nvidia.com/en-us/security/pgp-key). +* **GitHub Private Vulnerability Reporting:** use the "Report a vulnerability" + button on this repository's Security tab. + +OEM partners should contact their NVIDIA Customer Program Manager. + +Please include: + +1. Product or repository name and the version, branch or commit affected +2. Type of vulnerability (for example code execution, denial of service, + information disclosure) +3. Step-by-step instructions to reproduce the issue +4. Proof-of-concept or exploit code, if available +5. Potential impact, including how an attacker could exploit the issue + +NVIDIA PSIRT acknowledges reports, assesses them, and coordinates remediation +and disclosure with the reporter. Past advisories are published at +[https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/). + +## Security Architecture and Context + +**What this repository is.** Triton Tutorials is a collection of guides and +example code for the Triton Inference Server: Python and shell scripts, model +configurations (`config.pbtxt`), Dockerfiles, Kubernetes and Helm manifests, +and Markdown documentation. It is a **documentation and sample-code +repository**, not a shipped product. Nothing in it is a supported production +artifact. + +**Classification:** SDK / sample code (examples and reference deployments). + +**Primary security responsibility:** examples should not teach insecure +defaults, and sample code, container build files and scripts should not +contain vulnerabilities or embed credentials. + +**Key interfaces and boundaries** (exposed by the examples when a user runs +them, not by this repository itself): + +* Triton Inference Server HTTP (8000), gRPC (8001) and metrics (8002) endpoints + started by the guides. +* Example Gradio web client (`Conceptual_Guide/Part_6-building_complex_pipelines/gui`). +* Example Ray Serve and Kafka integrations under + `Triton_Inference_Server_Python_API/examples`. +* Docker build and run scripts (`build.sh`, `run.sh`) under + `Popular_Models_Guide/StableDiffusion` and `Triton_Inference_Server_Python_API`. +* Kubernetes and Helm deployments under `Deployment/Kubernetes`. +* Model artifacts and weights downloaded from third-party hubs at run time. + +**Repository Exposure Classification:** Public. Basis: the repository is +publicly visible on GitHub. + +**Service Exposure Classification:** Internal-Isolated (low confidence). Basis: +the repository ships no running service; deployments are created by users in +their own environments from the examples. + +## Threat Model + +1. **Untrusted model artifacts executed at load time.** Example scripts such as + `Conceptual_Guide/Part_5-Model_Ensembles/utils/export_text_recognition.py` + call `torch.load` on downloaded checkpoints, and the guides download models + from public hubs. A tampered or malicious checkpoint can execute arbitrary + code on the machine running the export step. +2. **Unauthenticated, unencrypted inference endpoints.** The guides start + Triton listening on all interfaces (HTTP, gRPC, metrics) without TLS or + authentication, and some `run.sh` scripts use `docker run --network host`. + Anyone who can reach the host can submit inference requests, read metrics + and model metadata, or exhaust GPU capacity. +3. **Credential exposure through build and run scripts.** The Stable Diffusion + and Python API `build.sh` scripts pass `HF_TOKEN` as a Docker `--build-arg`, + which can persist in image history, and `run.sh` passes it as a container + environment variable. Images built this way and pushed to a registry can + leak the token. +4. **Exposed management and UI surfaces.** The Gradio example client binds to + `0.0.0.0` and the Ray example starts the Ray head node with its dashboard + on `0.0.0.0`. On a shared network these expose a web UI and a cluster + control plane without authentication. +5. **Supply-chain risk in example dependencies and containers.** Dockerfiles, + `requirements.txt` files and guides pull packages, base images and + third-party tooling (for example `eksctl`, `huggingface-cli`, model + weights) that are not all pinned to digests or hashes. A compromised + upstream package or image affects anyone following the guide. +6. **Over-privileged sample deployments.** Kubernetes and Helm examples under + `Deployment/Kubernetes` and multi-node launch scripts that start the + server as a subprocess may run with broad container privileges and + cluster-wide defaults that are unsuitable for production. + +## Critical Security Assumptions + +* **Examples are for evaluation, not production.** Users are expected to add + TLS, authentication and authorization, network policy, and resource limits + before exposing any deployment built from these guides. +* **A trusted network is assumed.** Example endpoints (Triton, Gradio, Ray, + Kafka) have no authentication and are assumed to run on an isolated + development network or behind an authenticating proxy. +* **Model artifacts are assumed trusted.** Checkpoints and weights fetched + from public hubs are loaded without signature or hash verification; users + must verify provenance, prefer safe serialization formats, and avoid loading + untrusted pickled files. +* **Secrets are supplied by the user.** Tokens such as `HF_TOKEN` are expected + to come from the user's environment or a secret manager, are never committed + to the repository, and should not be baked into built images. +* **Dependencies are the user's responsibility to update.** Pinned versions in + examples reflect the time of writing and may contain known vulnerabilities. + Users should rebuild with current, scanned base images and packages. +* **The host and container runtime are trusted.** The examples assume the + Docker daemon, GPU drivers and Kubernetes cluster are correctly configured + and isolated. From cb3b893eed4b67517f8baec3cd1cb525a6eec94e Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 17:12:31 +0000 Subject: [PATCH 2/7] docs: Address SECURITY.md review findings TRI-1935 --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index dead8816..2316ade8 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -41,7 +41,7 @@ the following channels: * **Email:** [psirt@nvidia.com](mailto:psirt@nvidia.com). Please encrypt sensitive reports with NVIDIA's [PGP key](https://www.nvidia.com/en-us/security/pgp-key). -* **GitHub Private Vulnerability Reporting:** use the "Report a vulnerability" +* **GitHub Private Vulnerability Reporting (where enabled):** use the "Report a vulnerability" button on this repository's Security tab. OEM partners should contact their NVIDIA Customer Program Manager. From 66f8fc7f6a59f6b111c694078b588bddbd36e31c Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 18:03:55 +0000 Subject: [PATCH 3/7] docs: Address Greptile review on SECURITY.md TRI-1935 --- SECURITY.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 2316ade8..2948be0a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -90,9 +90,13 @@ them, not by this repository itself): **Repository Exposure Classification:** Public. Basis: the repository is publicly visible on GitHub. -**Service Exposure Classification:** Internal-Isolated (low confidence). Basis: +**Service Exposure Classification:** Not determined (low confidence). Basis: the repository ships no running service; deployments are created by users in -their own environments from the examples. +their own environments from the examples. Exposure depends on the example used: +the EKS multi-node Helm chart under `Deployment/Kubernetes` creates a Kubernetes +Service of type `LoadBalancer` by default for the unauthenticated Triton HTTP, +gRPC and metrics ports (8000-8002), so a deployment from it can be reachable +beyond the cluster unless the operator restricts access with network controls. ## Threat Model @@ -107,10 +111,12 @@ their own environments from the examples. Anyone who can reach the host can submit inference requests, read metrics and model metadata, or exhaust GPU capacity. 3. **Credential exposure through build and run scripts.** The Stable Diffusion - and Python API `build.sh` scripts pass `HF_TOKEN` as a Docker `--build-arg`, - which can persist in image history, and `run.sh` passes it as a container - environment variable. Images built this way and pushed to a registry can - leak the token. + and Python API `build.sh` scripts forward `HF_TOKEN` to `docker build` as a + `--build-arg`, but neither Dockerfile declares or uses it, so these + Dockerfiles do not place the token in the image. The `run.sh` scripts pass + `HF_TOKEN` and `GITHUB_TOKEN` into the running container as environment + variables, where any process in the container, or anyone with access to it, + can read them. 4. **Exposed management and UI surfaces.** The Gradio example client binds to `0.0.0.0` and the Ray example starts the Ray head node with its dashboard on `0.0.0.0`. On a shared network these expose a web UI and a cluster From 0318a577a91da93be84f8dcd7f2b9a9ac36bcea1 Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 19:31:41 +0000 Subject: [PATCH 4/7] docs: Simplify SECURITY.md TRI-1935 --- SECURITY.md | 138 ++++++++++++---------------------------------------- 1 file changed, 32 insertions(+), 106 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 2948be0a..9f01d122 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -30,125 +30,51 @@ ## Reporting a Vulnerability -Please do not report security vulnerabilities through public GitHub issues, -discussions, or pull requests. +NVIDIA is dedicated to the security and trust of our software products and services, including all source code repositories managed through our organization. -To report a potential security vulnerability in any NVIDIA product, use one of -the following channels: +To report a potential security vulnerability, please use one of the following channels: -* **NVIDIA Vulnerability Disclosure Program** (preferred): - [https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/) -* **Email:** [psirt@nvidia.com](mailto:psirt@nvidia.com). Please encrypt - sensitive reports with NVIDIA's - [PGP key](https://www.nvidia.com/en-us/security/pgp-key). -* **GitHub Private Vulnerability Reporting (where enabled):** use the "Report a vulnerability" - button on this repository's Security tab. +1. **NVIDIA Vulnerability Disclosure Program** (preferred): https://www.nvidia.com/en-us/security/ +2. **Web form:** [Security Vulnerability Submission Form](https://www.nvidia.com/object/submit-security-vulnerability.html) +3. **Email:** [NVIDIA PSIRT](mailto:psirt@nvidia.com). Please encrypt sensitive reports with NVIDIA's [PGP key](https://www.nvidia.com/en-us/security/pgp-key). +4. **GitHub Private Vulnerability Reporting (where enabled):** use the "Report a vulnerability" button on the Security tab of this repository. -OEM partners should contact their NVIDIA Customer Program Manager. +**Do not open a public issue or pull request to report a vulnerability.** Please include: -1. Product or repository name and the version, branch or commit affected -2. Type of vulnerability (for example code execution, denial of service, - information disclosure) -3. Step-by-step instructions to reproduce the issue -4. Proof-of-concept or exploit code, if available -5. Potential impact, including how an attacker could exploit the issue +* Product or component name and version or branch +* Type of vulnerability +* Steps to reproduce +* Proof of concept, if available +* Potential impact and how it could be exploited -NVIDIA PSIRT acknowledges reports, assesses them, and coordinates remediation -and disclosure with the reporter. Past advisories are published at -[https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/). +See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins and Notices. ## Security Architecture and Context -**What this repository is.** Triton Tutorials is a collection of guides and -example code for the Triton Inference Server: Python and shell scripts, model -configurations (`config.pbtxt`), Dockerfiles, Kubernetes and Helm manifests, -and Markdown documentation. It is a **documentation and sample-code -repository**, not a shipped product. Nothing in it is a supported production -artifact. - -**Classification:** SDK / sample code (examples and reference deployments). - -**Primary security responsibility:** examples should not teach insecure -defaults, and sample code, container build files and scripts should not -contain vulnerabilities or embed credentials. - -**Key interfaces and boundaries** (exposed by the examples when a user runs -them, not by this repository itself): - -* Triton Inference Server HTTP (8000), gRPC (8001) and metrics (8002) endpoints - started by the guides. -* Example Gradio web client (`Conceptual_Guide/Part_6-building_complex_pipelines/gui`). -* Example Ray Serve and Kafka integrations under - `Triton_Inference_Server_Python_API/examples`. -* Docker build and run scripts (`build.sh`, `run.sh`) under - `Popular_Models_Guide/StableDiffusion` and `Triton_Inference_Server_Python_API`. -* Kubernetes and Helm deployments under `Deployment/Kubernetes`. -* Model artifacts and weights downloaded from third-party hubs at run time. - -**Repository Exposure Classification:** Public. Basis: the repository is -publicly visible on GitHub. - -**Service Exposure Classification:** Not determined (low confidence). Basis: -the repository ships no running service; deployments are created by users in -their own environments from the examples. Exposure depends on the example used: -the EKS multi-node Helm chart under `Deployment/Kubernetes` creates a Kubernetes -Service of type `LoadBalancer` by default for the unauthenticated Triton HTTP, -gRPC and metrics ports (8000-8002), so a deployment from it can be reachable -beyond the cluster unless the operator restricts access with network controls. +**Project:** Tutorials and examples for Triton Inference Server. + +**Software type:** Examples and bundled third-party source packages. + +**Security boundaries:** The main security boundary is between this code and the environments, credentials and networks where it is built or run. + +**Repository Exposure Classification:** Public. + +**Service Exposure Classification:** Deployment-dependent. Exposure depends on how the software is deployed and configured by the operator. ## Threat Model -1. **Untrusted model artifacts executed at load time.** Example scripts such as - `Conceptual_Guide/Part_5-Model_Ensembles/utils/export_text_recognition.py` - call `torch.load` on downloaded checkpoints, and the guides download models - from public hubs. A tampered or malicious checkpoint can execute arbitrary - code on the machine running the export step. -2. **Unauthenticated, unencrypted inference endpoints.** The guides start - Triton listening on all interfaces (HTTP, gRPC, metrics) without TLS or - authentication, and some `run.sh` scripts use `docker run --network host`. - Anyone who can reach the host can submit inference requests, read metrics - and model metadata, or exhaust GPU capacity. -3. **Credential exposure through build and run scripts.** The Stable Diffusion - and Python API `build.sh` scripts forward `HF_TOKEN` to `docker build` as a - `--build-arg`, but neither Dockerfile declares or uses it, so these - Dockerfiles do not place the token in the image. The `run.sh` scripts pass - `HF_TOKEN` and `GITHUB_TOKEN` into the running container as environment - variables, where any process in the container, or anyone with access to it, - can read them. -4. **Exposed management and UI surfaces.** The Gradio example client binds to - `0.0.0.0` and the Ray example starts the Ray head node with its dashboard - on `0.0.0.0`. On a shared network these expose a web UI and a cluster - control plane without authentication. -5. **Supply-chain risk in example dependencies and containers.** Dockerfiles, - `requirements.txt` files and guides pull packages, base images and - third-party tooling (for example `eksctl`, `huggingface-cli`, model - weights) that are not all pinned to digests or hashes. A compromised - upstream package or image affects anyone following the guide. -6. **Over-privileged sample deployments.** Kubernetes and Helm examples under - `Deployment/Kubernetes` and multi-node launch scripts that start the - server as a subprocess may run with broad container privileges and - cluster-wide defaults that are unsuitable for production. +1. **Not hardened:** Examples and modified third-party sources are for development and reference, and may omit production security controls. +2. **Vulnerable or outdated dependencies:** Bundled or referenced third-party code may contain known vulnerabilities or lag behind upstream fixes. +3. **Supply chain:** Sources and models fetched at build or run time may be tampered with or unpinned. +4. **Exposure by default:** Example deployments may expose services without authentication or encryption. +5. **Credentials and sensitive data:** Credentials and data handled by examples may leak through logs, environment variables or build artifacts. ## Critical Security Assumptions -* **Examples are for evaluation, not production.** Users are expected to add - TLS, authentication and authorization, network policy, and resource limits - before exposing any deployment built from these guides. -* **A trusted network is assumed.** Example endpoints (Triton, Gradio, Ray, - Kafka) have no authentication and are assumed to run on an isolated - development network or behind an authenticating proxy. -* **Model artifacts are assumed trusted.** Checkpoints and weights fetched - from public hubs are loaded without signature or hash verification; users - must verify provenance, prefer safe serialization formats, and avoid loading - untrusted pickled files. -* **Secrets are supplied by the user.** Tokens such as `HF_TOKEN` are expected - to come from the user's environment or a secret manager, are never committed - to the repository, and should not be baked into built images. -* **Dependencies are the user's responsibility to update.** Pinned versions in - examples reflect the time of writing and may contain known vulnerabilities. - Users should rebuild with current, scanned base images and packages. -* **The host and container runtime are trusted.** The examples assume the - Docker daemon, GPU drivers and Kubernetes cluster are correctly configured - and isolated. +* The code is used for development and evaluation, and is reviewed before any production use. +* Deployers add authentication, authorization and TLS before exposing services. +* Dependencies are kept up to date and obtained from trusted sources. +* Credentials used with the examples are protected and rotated. +* Host operating system, driver and hardware security are the operator's responsibility. From 5e81be85bea242f24a7eece6ba988913947b3a1f Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 20:25:17 +0000 Subject: [PATCH 5/7] docs: Use standard NVIDIA SECURITY.md TRI-1935 --- SECURITY.md | 58 ++++++++++------------------------------------------- 1 file changed, 11 insertions(+), 47 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 9f01d122..27b2fd7f 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -26,55 +26,19 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. --> -# Security Policy +# Report a Security Vulnerability -## Reporting a Vulnerability +To report a potential security vulnerability in any NVIDIA product, please use either: +* This web form: [Security Vulnerability Submission Form](https://www.nvidia.com/object/submit-security-vulnerability.html), or +* Send email to: [NVIDIA PSIRT](mailto:psirt@nvidia.com) -NVIDIA is dedicated to the security and trust of our software products and services, including all source code repositories managed through our organization. +**OEM Partners should contact their NVIDIA Customer Program Manager** -To report a potential security vulnerability, please use one of the following channels: - -1. **NVIDIA Vulnerability Disclosure Program** (preferred): https://www.nvidia.com/en-us/security/ -2. **Web form:** [Security Vulnerability Submission Form](https://www.nvidia.com/object/submit-security-vulnerability.html) -3. **Email:** [NVIDIA PSIRT](mailto:psirt@nvidia.com). Please encrypt sensitive reports with NVIDIA's [PGP key](https://www.nvidia.com/en-us/security/pgp-key). -4. **GitHub Private Vulnerability Reporting (where enabled):** use the "Report a vulnerability" button on the Security tab of this repository. - -**Do not open a public issue or pull request to report a vulnerability.** - -Please include: - -* Product or component name and version or branch -* Type of vulnerability -* Steps to reproduce -* Proof of concept, if available -* Potential impact and how it could be exploited +If reporting a potential vulnerability via email, please encrypt it using NVIDIA’s public PGP key ([see PGP Key page](https://www.nvidia.com/en-us/security/pgp-key/)) 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. - -## Security Architecture and Context - -**Project:** Tutorials and examples for Triton Inference Server. - -**Software type:** Examples and bundled third-party source packages. - -**Security boundaries:** The main security boundary is between this code and the environments, credentials and networks where it is built or run. - -**Repository Exposure Classification:** Public. - -**Service Exposure Classification:** Deployment-dependent. Exposure depends on how the software is deployed and configured by the operator. - -## Threat Model - -1. **Not hardened:** Examples and modified third-party sources are for development and reference, and may omit production security controls. -2. **Vulnerable or outdated dependencies:** Bundled or referenced third-party code may contain known vulnerabilities or lag behind upstream fixes. -3. **Supply chain:** Sources and models fetched at build or run time may be tampered with or unpinned. -4. **Exposure by default:** Example deployments may expose services without authentication or encryption. -5. **Credentials and sensitive data:** Credentials and data handled by examples may leak through logs, environment variables or build artifacts. - -## Critical Security Assumptions - -* The code is used for development and evaluation, and is reviewed before any production use. -* Deployers add authentication, authorization and TLS before exposing services. -* Dependencies are kept up to date and obtained from trusted sources. -* Credentials used with the examples are protected and rotated. -* Host operating system, driver and hardware security are the operator's responsibility. From 1c6d973f6365e6e636517d42db54c95c7b145ec2 Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 21:13:57 +0000 Subject: [PATCH 6/7] docs: Add vulnerability reporting guidance to SECURITY.md TRI-1935 --- SECURITY.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 27b2fd7f..4ff320e7 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -42,3 +42,5 @@ If reporting a potential vulnerability via email, please encrypt it using NVIDIA 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. + +**Please do not report security vulnerabilities through public issues or other public channels.** From 11b0f4b3f8f3078165468250d98ba381750209e1 Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 21:36:56 +0000 Subject: [PATCH 7/7] docs: Adopt current NVIDIA SECURITY.md template TRI-1935 --- SECURITY.md | 33 ++++++++++++++++++++------------- 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 4ff320e7..ec8ed2c6 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -26,21 +26,28 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. --> -# Report a Security Vulnerability +## Security -To report a potential security vulnerability in any NVIDIA product, please use either: -* This web form: [Security Vulnerability Submission Form](https://www.nvidia.com/object/submit-security-vulnerability.html), or -* Send email to: [NVIDIA PSIRT](mailto:psirt@nvidia.com) +NVIDIA is dedicated to the security and trust of our software products and services, including all source code repositories managed through our organization. -**OEM Partners should contact their NVIDIA Customer Program Manager** +If you need to report a security issue, please use the appropriate contact points outlined below. **Please do not report security vulnerabilities through GitHub/GitLab.** If a potential security issue is inadvertently reported via a public issue or pull request, NVIDIA maintainers may limit public discussion and redirect the reporter to the appropriate private disclosure channels. -If reporting a potential vulnerability via email, please encrypt it using NVIDIA’s public PGP key ([see PGP Key page](https://www.nvidia.com/en-us/security/pgp-key/)) 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 +## Reporting Potential Security Vulnerability in an NVIDIA Product -See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins and Notices. +To report a potential security vulnerability in any NVIDIA product: -**Please do not report security vulnerabilities through public issues or other public channels.** +- Web: [Security Vulnerability Submission Form](https://www.nvidia.com/object/submit-security-vulnerability.html) +- E-Mail: psirt@nvidia.com + - We encourage you to use the following PGP key for secure email communication: [NVIDIA public PGP Key for communication](https://www.nvidia.com/en-us/security/pgp-key) + - Please include the following information: + - Product/Driver name and version/branch that contains the vulnerability + - Type of vulnerability (code execution, denial of service, buffer overflow, etc.) + - Instructions to reproduce the vulnerability + - Proof-of-concept or exploit code + - Potential impact of the vulnerability, including how an attacker could exploit the vulnerability + +While NVIDIA currently does not have a bug bounty program, we do offer acknowledgement when an externally reported security issue is addressed under our coordinated vulnerability disclosure policy. Please visit our [Product Security Incident Response Team (PSIRT)](https://www.nvidia.com/en-us/security/psirt-policies/) policies page for more information. + +## NVIDIA Product Security + +For all security-related concerns, please visit NVIDIA's Product Security portal at https://www.nvidia.com/en-us/security