From 4488cc2fbbd03586f3c679b5e60e210753ad1426 Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Fri, 2 Oct 2026 20:58:47 +0000 Subject: [PATCH 1/6] docs: Add SECURITY.md TRI-1935 --- SECURITY.md | 144 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..3f59316 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,144 @@ + + +# Report a Security Vulnerability + +To report a potential security vulnerability in this project or any NVIDIA +product, please use one of the following channels. **Do not open a public +GitHub issue for a suspected vulnerability.** + +1. **NVIDIA Vulnerability Disclosure Program** (preferred): + [https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/) +2. **Email NVIDIA PSIRT:** [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). +3. **GitHub Private Vulnerability Reporting:** use the "Report a vulnerability" + button on the repository's Security tab, where enabled. + +**OEM partners should contact their NVIDIA Customer Program Manager.** + +Please include: + +1. Product name and version or branch that contains the vulnerability +2. Type of vulnerability (memory corruption, denial of service, information + disclosure, etc.) +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, triages and validates them, coordinates a +fix and disclosure timeline with the reporter, and publishes security +bulletins at [https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/). + +# Security Architecture and Context + +**Project:** Triton Local Cache, the in-memory response cache implementation +for [Triton Inference Server](https://github.com/triton-inference-server/server). + +**Software classification:** Library. It is a C++17 shared library +(`libtritoncache_local.so`) that Triton Core loads as a cache plugin through +the `TRITONCACHE_*` C API (`src/cache_api.cc`). It is not a standalone process +and opens no network listeners, files, or sockets of its own. + +**Primary security responsibility:** Store and return cached inference +response buffers faithfully and within a fixed memory budget, without memory +corruption, cross-entry data mixing, or unbounded resource use. + +**Key interfaces and boundaries:** + +- **Plugin API (trust boundary with Triton Core):** `CacheInitialize`, + `CacheFinalize`, `CacheLookup`, `CacheInsert`. Triton Core supplies the + cache key, entry buffers, buffer attributes, and the copy allocator. The + library validates for null arguments, zero-sized buffers, and CPU or pinned + CPU memory type only. +- **Configuration input:** a JSON string passed by the server operator + (`--cache-config local,size=`), parsed with RapidJSON in + `LocalCache::Create`. Only the `size` field is consumed. +- **Memory:** one `malloc`-ed region of the configured size, managed with + `boost::interprocess::managed_external_buffer` and guarded by internal + mutexes. Eviction is least-recently-used. +- **Observability:** optional Prometheus metrics (`nv_cache_*`) through the + Triton metrics API, and Triton logging. + +**Repository Exposure Classification:** Public. Basis: the repository is +publicly visible on GitHub. + +**Service Exposure Classification:** Internal-Sensitive (medium confidence). +Basis: the library runs inside the Triton server process and handles model +inference responses, which can contain customer data, but it has no direct +network exposure and inherits the deployment's exposure from the host server. + +# Threat Model + +1. **Resource exhaustion through cache sizing:** the `size` setting is + allocated in one `malloc` call at initialization. An excessively large or + malformed value can cause start-up failure or memory pressure on the host. + Treat the cache configuration as trusted operator input. +2. **Cross-request data exposure through shared cache entries:** all + callers of one cache instance share a single key space, and entries are + returned to any caller presenting the same key. If Triton Core, or a + deployment, derives keys without covering all inputs that affect the + response (model, version, input data, relevant parameters), one request can + receive another's cached output. +3. **Memory-safety defects in buffer lifetime handling:** the library stores + raw pointers into the managed buffer, LRU list iterators, and per-entry + attribute objects, and relies on Triton Core copying data out before an + entry can be evicted. Bugs in eviction, entry lifetime, or locking + (`cache_mu_` and `buffer_mu_` ordering) could lead to use-after-free, + double free, or data races. Concurrency changes should be reviewed with + this in mind. +4. **Denial of service through cache churn:** insertion of many or large + entries evicts useful entries and can fail allocation when a single + response exceeds the cache size or memory is fragmented. Callers must treat + insert failures as non-fatal and fall back to uncached execution. +5. **Information disclosure through logs and metrics:** the cache + configuration and cache keys appear in log messages, and aggregate + utilization, hit, and eviction counters are exported as metrics. Keys + derived from request data should not be assumed confidential in logs. +6. **Supply-chain risk in build dependencies:** the library builds against + Boost, RapidJSON, and Triton common and core components. Compromised or + vulnerable dependency versions would affect the resulting binary. + +# Critical Security Assumptions + +- **No authentication or authorization:** the library performs none. Access + control is entirely the responsibility of Triton Server and its deployment. +- **Trusted caller:** Triton Core is assumed to pass valid buffers, correct + sizes, and keys that fully identify the response being cached. +- **Trusted configuration:** the cache configuration string is assumed to come + from the server operator, not from untrusted users. +- **No encryption at rest or in memory:** cached responses are stored as + plaintext in process memory and are not zeroed on eviction, so other code in + the same process (or a memory dump of it) can observe them. +- **Single-tenant cache:** there is no per-tenant isolation or quota. Do not + share one cache instance between mutually distrusting tenants. +- **CPU memory only:** only CPU and pinned CPU buffers are supported. GPU + memory buffers are rejected. +- **Process isolation:** the host process boundary and operating system + protections are assumed to prevent untrusted code from reading or writing + the cache region. From 5824f061b8210cabd5ebd7d6733505279153875b Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 18:03:47 +0000 Subject: [PATCH 2/6] docs: Address Greptile review on SECURITY.md TRI-1935 --- SECURITY.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 3f59316..ca2b558 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -60,7 +60,7 @@ bulletins at [https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en- **Project:** Triton Local Cache, the in-memory response cache implementation for [Triton Inference Server](https://github.com/triton-inference-server/server). -**Software classification:** Library. It is a C++17 shared library +**Software classification:** Library. It is a C++20 shared library (`libtritoncache_local.so`) that Triton Core loads as a cache plugin through the `TRITONCACHE_*` C API (`src/cache_api.cc`). It is not a standalone process and opens no network listeners, files, or sockets of its own. @@ -116,10 +116,13 @@ network exposure and inherits the deployment's exposure from the host server. entries evicts useful entries and can fail allocation when a single response exceeds the cache size or memory is fragmented. Callers must treat insert failures as non-fatal and fall back to uncached execution. -5. **Information disclosure through logs and metrics:** the cache - configuration and cache keys appear in log messages, and aggregate - utilization, hit, and eviction counters are exported as metrics. Keys - derived from request data should not be assumed confidential in logs. +5. **Information disclosure through logs, errors, and metrics:** the cache + configuration and cache keys appear in log messages, and keys also appear + verbatim in the error messages returned for lookup misses, duplicate + inserts, and failed inserts (`src/local_cache.cc`), so log controls alone + do not protect them. Aggregate utilization (a 0.0 to 1.0 ratio), hit, and + eviction values are exported as gauge metrics. Keys derived from request + data should not be assumed confidential in logs or returned errors. 6. **Supply-chain risk in build dependencies:** the library builds against Boost, RapidJSON, and Triton common and core components. Compromised or vulnerable dependency versions would affect the resulting binary. From 4d65ad191894314256c5ea55b6d0923b2be341fd Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 19:29:38 +0000 Subject: [PATCH 3/6] docs: Simplify SECURITY.md TRI-1935 --- SECURITY.md | 159 +++++++++++++++------------------------------------- 1 file changed, 46 insertions(+), 113 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index ca2b558..4b24b60 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -26,122 +26,55 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. --> -# Report a Security Vulnerability +# Security Policy -To report a potential security vulnerability in this project or any NVIDIA -product, please use one of the following channels. **Do not open a public -GitHub issue for a suspected vulnerability.** +## Reporting a Vulnerability -1. **NVIDIA Vulnerability Disclosure Program** (preferred): - [https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/) -2. **Email NVIDIA PSIRT:** [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). -3. **GitHub Private Vulnerability Reporting:** use the "Report a vulnerability" - button on the repository's Security tab, where enabled. +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: -1. Product name and version or branch that contains the vulnerability -2. Type of vulnerability (memory corruption, denial of service, information - disclosure, etc.) -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, triages and validates them, coordinates a -fix and disclosure timeline with the reporter, and publishes security -bulletins at [https://www.nvidia.com/en-us/security/](https://www.nvidia.com/en-us/security/). - -# Security Architecture and Context - -**Project:** Triton Local Cache, the in-memory response cache implementation -for [Triton Inference Server](https://github.com/triton-inference-server/server). - -**Software classification:** Library. It is a C++20 shared library -(`libtritoncache_local.so`) that Triton Core loads as a cache plugin through -the `TRITONCACHE_*` C API (`src/cache_api.cc`). It is not a standalone process -and opens no network listeners, files, or sockets of its own. - -**Primary security responsibility:** Store and return cached inference -response buffers faithfully and within a fixed memory budget, without memory -corruption, cross-entry data mixing, or unbounded resource use. - -**Key interfaces and boundaries:** - -- **Plugin API (trust boundary with Triton Core):** `CacheInitialize`, - `CacheFinalize`, `CacheLookup`, `CacheInsert`. Triton Core supplies the - cache key, entry buffers, buffer attributes, and the copy allocator. The - library validates for null arguments, zero-sized buffers, and CPU or pinned - CPU memory type only. -- **Configuration input:** a JSON string passed by the server operator - (`--cache-config local,size=`), parsed with RapidJSON in - `LocalCache::Create`. Only the `size` field is consumed. -- **Memory:** one `malloc`-ed region of the configured size, managed with - `boost::interprocess::managed_external_buffer` and guarded by internal - mutexes. Eviction is least-recently-used. -- **Observability:** optional Prometheus metrics (`nv_cache_*`) through the - Triton metrics API, and Triton logging. - -**Repository Exposure Classification:** Public. Basis: the repository is -publicly visible on GitHub. - -**Service Exposure Classification:** Internal-Sensitive (medium confidence). -Basis: the library runs inside the Triton server process and handles model -inference responses, which can contain customer data, but it has no direct -network exposure and inherits the deployment's exposure from the host server. - -# Threat Model - -1. **Resource exhaustion through cache sizing:** the `size` setting is - allocated in one `malloc` call at initialization. An excessively large or - malformed value can cause start-up failure or memory pressure on the host. - Treat the cache configuration as trusted operator input. -2. **Cross-request data exposure through shared cache entries:** all - callers of one cache instance share a single key space, and entries are - returned to any caller presenting the same key. If Triton Core, or a - deployment, derives keys without covering all inputs that affect the - response (model, version, input data, relevant parameters), one request can - receive another's cached output. -3. **Memory-safety defects in buffer lifetime handling:** the library stores - raw pointers into the managed buffer, LRU list iterators, and per-entry - attribute objects, and relies on Triton Core copying data out before an - entry can be evicted. Bugs in eviction, entry lifetime, or locking - (`cache_mu_` and `buffer_mu_` ordering) could lead to use-after-free, - double free, or data races. Concurrency changes should be reviewed with - this in mind. -4. **Denial of service through cache churn:** insertion of many or large - entries evicts useful entries and can fail allocation when a single - response exceeds the cache size or memory is fragmented. Callers must treat - insert failures as non-fatal and fall back to uncached execution. -5. **Information disclosure through logs, errors, and metrics:** the cache - configuration and cache keys appear in log messages, and keys also appear - verbatim in the error messages returned for lookup misses, duplicate - inserts, and failed inserts (`src/local_cache.cc`), so log controls alone - do not protect them. Aggregate utilization (a 0.0 to 1.0 ratio), hit, and - eviction values are exported as gauge metrics. Keys derived from request - data should not be assumed confidential in logs or returned errors. -6. **Supply-chain risk in build dependencies:** the library builds against - Boost, RapidJSON, and Triton common and core components. Compromised or - vulnerable dependency versions would affect the resulting binary. - -# Critical Security Assumptions - -- **No authentication or authorization:** the library performs none. Access - control is entirely the responsibility of Triton Server and its deployment. -- **Trusted caller:** Triton Core is assumed to pass valid buffers, correct - sizes, and keys that fully identify the response being cached. -- **Trusted configuration:** the cache configuration string is assumed to come - from the server operator, not from untrusted users. -- **No encryption at rest or in memory:** cached responses are stored as - plaintext in process memory and are not zeroed on eviction, so other code in - the same process (or a memory dump of it) can observe them. -- **Single-tenant cache:** there is no per-tenant isolation or quota. Do not - share one cache instance between mutually distrusting tenants. -- **CPU memory only:** only CPU and pinned CPU buffers are supported. GPU - memory buffers are rejected. -- **Process isolation:** the host process boundary and operating system - protections are assumed to prevent untrusted code from reading or writing - the cache region. +* 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 + +See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins and Notices. + +## Security Architecture and Context + +**Project:** Implementation of a local in-memory cache for Triton Inference Server's cache API. + +**Software type:** Software component (library, backend, client or tool) used as part of a Triton Inference Server deployment. + +**Security boundaries:** The main security boundary is between this component and the data, models and configuration it is given, and between it and the server or application that hosts it. + +**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 input:** Requests, models, configuration or data supplied to this component may be malformed or malicious, and could cause crashes, memory errors or unintended behavior if not validated. +2. **Supply chain:** Source and build dependencies fetched at build or install time may be compromised, outdated or unpinned. +3. **Network exposure:** When deployed behind a network-facing server, endpoints may be reachable by untrusted clients. This component does not by itself provide authentication, authorization or encryption. +4. **Resource exhaustion:** Oversized or numerous requests may consume memory, compute or other resources and degrade availability. +5. **Information disclosure:** Logs, metrics and error messages may reveal sensitive data such as paths, identifiers or request content. + +## Critical Security Assumptions + +* The component is deployed in a trusted environment or behind a gateway that provides authentication, authorization, TLS and rate limiting. +* Models, configuration and other inputs come from trusted sources. +* Dependencies and the build environment are kept up to date and obtained from trusted sources. +* Operators protect secrets, certificates and credentials, and restrict access to logs and metrics. +* Host operating system, driver and hardware security are the operator's responsibility. From a580b33c9ee5e4dfe481952c4652e41507222e78 Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 20:23:35 +0000 Subject: [PATCH 4/6] 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 4b24b60..df20980 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:** Implementation of a local in-memory cache for Triton Inference Server's cache API. - -**Software type:** Software component (library, backend, client or tool) used as part of a Triton Inference Server deployment. - -**Security boundaries:** The main security boundary is between this component and the data, models and configuration it is given, and between it and the server or application that hosts it. - -**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 input:** Requests, models, configuration or data supplied to this component may be malformed or malicious, and could cause crashes, memory errors or unintended behavior if not validated. -2. **Supply chain:** Source and build dependencies fetched at build or install time may be compromised, outdated or unpinned. -3. **Network exposure:** When deployed behind a network-facing server, endpoints may be reachable by untrusted clients. This component does not by itself provide authentication, authorization or encryption. -4. **Resource exhaustion:** Oversized or numerous requests may consume memory, compute or other resources and degrade availability. -5. **Information disclosure:** Logs, metrics and error messages may reveal sensitive data such as paths, identifiers or request content. - -## Critical Security Assumptions - -* The component is deployed in a trusted environment or behind a gateway that provides authentication, authorization, TLS and rate limiting. -* Models, configuration and other inputs come from trusted sources. -* Dependencies and the build environment are kept up to date and obtained from trusted sources. -* Operators protect secrets, certificates and credentials, and restrict access to logs and metrics. -* Host operating system, driver and hardware security are the operator's responsibility. From 147b04f264f8a3d970f149b44a9d037f6420f064 Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 21:12:15 +0000 Subject: [PATCH 5/6] 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 df20980..b600f85 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 4d0dcde92d56f30b477e9f94507671f2c46f0913 Mon Sep 17 00:00:00 2001 From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com> Date: Mon, 5 Oct 2026 21:35:14 +0000 Subject: [PATCH 6/6] 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 b600f85..0f8d3b0 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