From b040629c8219acc5098a94b6a544da9fdd95a721 Mon Sep 17 00:00:00 2001
From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com>
Date: Fri, 2 Oct 2026 22:49:58 +0000
Subject: [PATCH 1/7] docs: Update SECURITY.md

TRI-1935
---
 SECURITY.md | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/SECURITY.md b/SECURITY.md
index 7aa39f4e5d..640fd0a99b 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,5 +1,5 @@
 <!--
-# Copyright 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# Copyright 2023-2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions
@@ -42,3 +42,48 @@ 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.
+
+## Reporting Channels
+
+**Please do not open a public GitHub issue, discussion or pull request to report a security vulnerability.** Use one of the following private channels:
+
+1. **NVIDIA Vulnerability Disclosure Program** (preferred): https://www.nvidia.com/en-us/security/
+2. **Email**: [psirt@nvidia.com](mailto:psirt@nvidia.com), encrypted with NVIDIA's [public PGP key](https://www.nvidia.com/en-us/security/pgp-key/)
+3. **GitHub Private Vulnerability Reporting**: use the "Report a vulnerability" button on the Security tab of this repository, where it is enabled
+
+NVIDIA PSIRT acknowledges reports, assesses severity and coordinates remediation and disclosure with the reporter.
+
+## Security Architecture and Context
+
+Triton Inference Server (`server`) is a **Service**: a long-running inference server that loads models from a model repository and serves inference requests over network endpoints. Its primary security responsibility is to parse untrusted network input safely, enforce the configured access restrictions, and keep requests for different models and clients isolated within one process.
+
+Key interfaces and trust boundaries:
+
+- **HTTP/REST endpoint** (`src/http_server.cc`): KServe v2 and extension APIs for inference, model metadata, model repository control, shared memory, statistics, tracing and logging. Also optional SageMaker and Vertex AI adapters.
+- **gRPC endpoint** (`src/grpc/`): the same APIs over gRPC, including streaming inference. Optional TLS and mutual TLS are configured through the `--grpc-use-ssl*` options.
+- **Metrics endpoint**: optional Prometheus metrics, enabled with `--allow-metrics`.
+- **Command line and configuration** (`src/command_line_parser.cc`, `src/main.cc`): options set by the deployer control listeners, enabled APIs, model control mode, tracing output and TLS material.
+- **Model repository and backends**: model files, model configuration and backend libraries are loaded from local or cloud storage into the server process.
+- **Shared memory** (`src/shared_memory_manager.cc`): clients on the same host can register system or CUDA shared memory regions for tensor exchange.
+
+The HTTP and gRPC listeners default to binding all interfaces (`0.0.0.0`). Built-in access control is limited to optional per-API-category restrictions (`--http-restricted-api`, `--grpc-restricted-protocol`), which require a configured request header key and value. The categories are health, metadata, inference, shared-memory, model-config, model-repository, statistics, trace and logging.
+
+## Threat Model
+
+1. **Unauthenticated access to management APIs.** If the endpoints are reachable by untrusted clients and the restrictions above are not configured, any client can call the model repository, shared memory, trace, logging and statistics APIs. In particular, the model repository load and unload APIs, available when `--model-control-mode=explicit`, can change which models and backends run in the server.
+2. **Malicious or tampered models and backends.** Model files, configuration and backend libraries are loaded from the model repository. A model from an untrusted source, or a repository that an attacker can write to, can execute arbitrary code in the server process, since backends are loaded as shared libraries and the Python backend runs model code.
+3. **Malformed or oversized requests.** The HTTP parser (`src/http_server.cc`) and the gRPC handlers (`src/grpc/infer_handler.cc`, `src/grpc/stream_infer_handler.cc`) process attacker-controlled headers, JSON, binary tensor data and compressed bodies. Malformed input can lead to memory exhaustion, crashes or denial of service. Request size is bounded by `--http-max-input-size` and the gRPC message limits, which must be sized for the deployment.
+4. **Shared memory abuse.** A client that can register shared memory regions (`src/shared_memory_manager.cc`) supplies a region key, offset and size that the server maps and reads or writes. Incorrect bounds, access to regions belonging to other processes, or exposure of CUDA IPC handles can leak or corrupt data across trust boundaries.
+5. **Information disclosure through observability.** Metrics, statistics, model metadata and verbose logs can reveal model names, configuration, request rates and error details. Trace output (`src/tracer.cc`, `--trace-config`) can include input and output tensors at the `TENSORS` level and is written to a path chosen by the deployer, so the file's location and permissions determine who can read it.
+6. **Weak transport security.** Endpoints that are not protected by TLS expose request and response data, including tensors and any restricted-API header values, to anyone on the network path. gRPC TLS and mutual TLS are optional and are off by default.
+7. **Build and supply chain.** `build.py`, the Dockerfiles and the dependencies fetched during the build determine what ends up in the released server and container images. Unpinned or unverified dependencies can introduce compromised code.
+
+## Critical Security Assumptions
+
+- Triton is deployed on a **trusted network** or behind a gateway that provides authentication, authorization, rate limiting and TLS termination. The server itself does not provide user identity or per-user authorization.
+- Operators who expose Triton beyond a trusted network configure `--http-address`, `--grpc-address` and the restricted-API options so that management APIs are not reachable by untrusted clients.
+- The **model repository is trusted and access-controlled.** Anyone who can write models or backends to the repository, or call the model repository API, is able to run code in the server. Models from untrusted sources must be reviewed or run in an isolated deployment.
+- Shared memory is used only between **mutually trusted processes on the same host**, and the host operating system and GPU driver enforce memory isolation correctly.
+- TLS certificates and keys provided through the `--grpc-use-ssl*` options, and any restricted-API header values, are stored and rotated securely by the operator.
+- Trace and log output locations are writable only by the server and readable only by authorized users.
+- Backends and third-party libraries (including the framework runtimes each backend embeds) are kept up to date and are not affected by known vulnerabilities in the deployed version.

From 4752cbaa54558795cca39c01334e2ee15b06f328 Mon Sep 17 00:00:00 2001
From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com>
Date: Mon, 5 Oct 2026 17:12:42 +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 640fd0a99b..827310899f 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -75,7 +75,7 @@ The HTTP and gRPC listeners default to binding all interfaces (`0.0.0.0`). Built
 3. **Malformed or oversized requests.** The HTTP parser (`src/http_server.cc`) and the gRPC handlers (`src/grpc/infer_handler.cc`, `src/grpc/stream_infer_handler.cc`) process attacker-controlled headers, JSON, binary tensor data and compressed bodies. Malformed input can lead to memory exhaustion, crashes or denial of service. Request size is bounded by `--http-max-input-size` and the gRPC message limits, which must be sized for the deployment.
 4. **Shared memory abuse.** A client that can register shared memory regions (`src/shared_memory_manager.cc`) supplies a region key, offset and size that the server maps and reads or writes. Incorrect bounds, access to regions belonging to other processes, or exposure of CUDA IPC handles can leak or corrupt data across trust boundaries.
 5. **Information disclosure through observability.** Metrics, statistics, model metadata and verbose logs can reveal model names, configuration, request rates and error details. Trace output (`src/tracer.cc`, `--trace-config`) can include input and output tensors at the `TENSORS` level and is written to a path chosen by the deployer, so the file's location and permissions determine who can read it.
-6. **Weak transport security.** Endpoints that are not protected by TLS expose request and response data, including tensors and any restricted-API header values, to anyone on the network path. gRPC TLS and mutual TLS are optional and are off by default.
+6. **Weak transport security.** The HTTP and metrics endpoints have no native TLS option (only gRPC has `--grpc-use-ssl*`), so endpoints that are not protected by a TLS-terminating gateway expose request and response data, including tensors and any restricted-API header values, to anyone on the network path. gRPC TLS and mutual TLS are optional and are off by default.
 7. **Build and supply chain.** `build.py`, the Dockerfiles and the dependencies fetched during the build determine what ends up in the released server and container images. Unpinned or unverified dependencies can introduce compromised code.
 
 ## Critical Security Assumptions

From c50261cc2efeaf65bf9082fdbb2cbd7f8599c3ec Mon Sep 17 00:00:00 2001
From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com>
Date: Mon, 5 Oct 2026 18:03:54 +0000
Subject: [PATCH 3/7] docs: Address Greptile review on SECURITY.md

TRI-1935
---
 SECURITY.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/SECURITY.md b/SECURITY.md
index 827310899f..1a02563506 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -47,7 +47,7 @@ See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins an
 
 **Please do not open a public GitHub issue, discussion or pull request to report a security vulnerability.** Use one of the following private channels:
 
-1. **NVIDIA Vulnerability Disclosure Program** (preferred): https://www.nvidia.com/en-us/security/
+1. **NVIDIA Vulnerability Disclosure Program** (preferred): submit through the [Security Vulnerability Submission Form](https://www.nvidia.com/object/submit-security-vulnerability.html). Program information: https://www.nvidia.com/en-us/security/
 2. **Email**: [psirt@nvidia.com](mailto:psirt@nvidia.com), encrypted with NVIDIA's [public PGP key](https://www.nvidia.com/en-us/security/pgp-key/)
 3. **GitHub Private Vulnerability Reporting**: use the "Report a vulnerability" button on the Security tab of this repository, where it is enabled
 
@@ -72,7 +72,7 @@ The HTTP and gRPC listeners default to binding all interfaces (`0.0.0.0`). Built
 
 1. **Unauthenticated access to management APIs.** If the endpoints are reachable by untrusted clients and the restrictions above are not configured, any client can call the model repository, shared memory, trace, logging and statistics APIs. In particular, the model repository load and unload APIs, available when `--model-control-mode=explicit`, can change which models and backends run in the server.
 2. **Malicious or tampered models and backends.** Model files, configuration and backend libraries are loaded from the model repository. A model from an untrusted source, or a repository that an attacker can write to, can execute arbitrary code in the server process, since backends are loaded as shared libraries and the Python backend runs model code.
-3. **Malformed or oversized requests.** The HTTP parser (`src/http_server.cc`) and the gRPC handlers (`src/grpc/infer_handler.cc`, `src/grpc/stream_infer_handler.cc`) process attacker-controlled headers, JSON, binary tensor data and compressed bodies. Malformed input can lead to memory exhaustion, crashes or denial of service. Request size is bounded by `--http-max-input-size` and the gRPC message limits, which must be sized for the deployment.
+3. **Malformed or oversized requests.** The HTTP parser (`src/http_server.cc`) and the gRPC handlers (`src/grpc/infer_handler.cc`, `src/grpc/stream_infer_handler.cc`) process attacker-controlled headers, JSON, binary tensor data and compressed bodies. Malformed input can lead to memory exhaustion, crashes or denial of service. `--http-max-input-size` is enforced while the HTTP handler processes the request body (JSON size and tensor byte sizes); the server sets no separate limit on how much of an incoming request it buffers, so an oversized request can consume memory before it is rejected. The gRPC message size is fixed at `INT32_MAX` (`MAX_GRPC_MESSAGE_SIZE` in `src/common.h`) and has no command-line option, so deployments that need a smaller request bound must enforce one outside the server, for example in a gateway.
 4. **Shared memory abuse.** A client that can register shared memory regions (`src/shared_memory_manager.cc`) supplies a region key, offset and size that the server maps and reads or writes. Incorrect bounds, access to regions belonging to other processes, or exposure of CUDA IPC handles can leak or corrupt data across trust boundaries.
 5. **Information disclosure through observability.** Metrics, statistics, model metadata and verbose logs can reveal model names, configuration, request rates and error details. Trace output (`src/tracer.cc`, `--trace-config`) can include input and output tensors at the `TENSORS` level and is written to a path chosen by the deployer, so the file's location and permissions determine who can read it.
 6. **Weak transport security.** The HTTP and metrics endpoints have no native TLS option (only gRPC has `--grpc-use-ssl*`), so endpoints that are not protected by a TLS-terminating gateway expose request and response data, including tensors and any restricted-API header values, to anyone on the network path. gRPC TLS and mutual TLS are optional and are off by default.

From 22e1aedc31ecb9fa71c08d7f0081c0400859fa3c Mon Sep 17 00:00:00 2001
From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com>
Date: Mon, 5 Oct 2026 19:30:39 +0000
Subject: [PATCH 4/7] docs: Simplify SECURITY.md

TRI-1935
---
 SECURITY.md | 50 ++++++++++++++++++++------------------------------
 1 file changed, 20 insertions(+), 30 deletions(-)

diff --git a/SECURITY.md b/SECURITY.md
index 1a02563506..c223207bfe 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -43,47 +43,37 @@ If reporting a potential vulnerability via email, please encrypt it using NVIDIA
 
 See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins and Notices.
 
-## Reporting Channels
+## Additional Reporting Channels
 
-**Please do not open a public GitHub issue, discussion or pull request to report a security vulnerability.** Use one of the following private channels:
+1. **NVIDIA Vulnerability Disclosure Program** (preferred): https://www.nvidia.com/en-us/security/
+2. **GitHub Private Vulnerability Reporting (where enabled):** use the "Report a vulnerability" button on the Security tab of this repository.
 
-1. **NVIDIA Vulnerability Disclosure Program** (preferred): submit through the [Security Vulnerability Submission Form](https://www.nvidia.com/object/submit-security-vulnerability.html). Program information: https://www.nvidia.com/en-us/security/
-2. **Email**: [psirt@nvidia.com](mailto:psirt@nvidia.com), encrypted with NVIDIA's [public PGP key](https://www.nvidia.com/en-us/security/pgp-key/)
-3. **GitHub Private Vulnerability Reporting**: use the "Report a vulnerability" button on the Security tab of this repository, where it is enabled
-
-NVIDIA PSIRT acknowledges reports, assesses severity and coordinates remediation and disclosure with the reporter.
+**Do not open a public issue or pull request to report a vulnerability.**
 
 ## Security Architecture and Context
 
-Triton Inference Server (`server`) is a **Service**: a long-running inference server that loads models from a model repository and serves inference requests over network endpoints. Its primary security responsibility is to parse untrusted network input safely, enforce the configured access restrictions, and keep requests for different models and clients isolated within one process.
+**Project:** The Triton Inference Server provides an optimized cloud and edge inferencing solution.
+
+**Software type:** Software component (library, backend, client or tool) used as part of a Triton Inference Server deployment.
 
-Key interfaces and trust boundaries:
+**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.
 
-- **HTTP/REST endpoint** (`src/http_server.cc`): KServe v2 and extension APIs for inference, model metadata, model repository control, shared memory, statistics, tracing and logging. Also optional SageMaker and Vertex AI adapters.
-- **gRPC endpoint** (`src/grpc/`): the same APIs over gRPC, including streaming inference. Optional TLS and mutual TLS are configured through the `--grpc-use-ssl*` options.
-- **Metrics endpoint**: optional Prometheus metrics, enabled with `--allow-metrics`.
-- **Command line and configuration** (`src/command_line_parser.cc`, `src/main.cc`): options set by the deployer control listeners, enabled APIs, model control mode, tracing output and TLS material.
-- **Model repository and backends**: model files, model configuration and backend libraries are loaded from local or cloud storage into the server process.
-- **Shared memory** (`src/shared_memory_manager.cc`): clients on the same host can register system or CUDA shared memory regions for tensor exchange.
+**Repository Exposure Classification:** Public.
 
-The HTTP and gRPC listeners default to binding all interfaces (`0.0.0.0`). Built-in access control is limited to optional per-API-category restrictions (`--http-restricted-api`, `--grpc-restricted-protocol`), which require a configured request header key and value. The categories are health, metadata, inference, shared-memory, model-config, model-repository, statistics, trace and logging.
+**Service Exposure Classification:** Deployment-dependent. Exposure depends on how the software is deployed and configured by the operator.
 
 ## Threat Model
 
-1. **Unauthenticated access to management APIs.** If the endpoints are reachable by untrusted clients and the restrictions above are not configured, any client can call the model repository, shared memory, trace, logging and statistics APIs. In particular, the model repository load and unload APIs, available when `--model-control-mode=explicit`, can change which models and backends run in the server.
-2. **Malicious or tampered models and backends.** Model files, configuration and backend libraries are loaded from the model repository. A model from an untrusted source, or a repository that an attacker can write to, can execute arbitrary code in the server process, since backends are loaded as shared libraries and the Python backend runs model code.
-3. **Malformed or oversized requests.** The HTTP parser (`src/http_server.cc`) and the gRPC handlers (`src/grpc/infer_handler.cc`, `src/grpc/stream_infer_handler.cc`) process attacker-controlled headers, JSON, binary tensor data and compressed bodies. Malformed input can lead to memory exhaustion, crashes or denial of service. `--http-max-input-size` is enforced while the HTTP handler processes the request body (JSON size and tensor byte sizes); the server sets no separate limit on how much of an incoming request it buffers, so an oversized request can consume memory before it is rejected. The gRPC message size is fixed at `INT32_MAX` (`MAX_GRPC_MESSAGE_SIZE` in `src/common.h`) and has no command-line option, so deployments that need a smaller request bound must enforce one outside the server, for example in a gateway.
-4. **Shared memory abuse.** A client that can register shared memory regions (`src/shared_memory_manager.cc`) supplies a region key, offset and size that the server maps and reads or writes. Incorrect bounds, access to regions belonging to other processes, or exposure of CUDA IPC handles can leak or corrupt data across trust boundaries.
-5. **Information disclosure through observability.** Metrics, statistics, model metadata and verbose logs can reveal model names, configuration, request rates and error details. Trace output (`src/tracer.cc`, `--trace-config`) can include input and output tensors at the `TENSORS` level and is written to a path chosen by the deployer, so the file's location and permissions determine who can read it.
-6. **Weak transport security.** The HTTP and metrics endpoints have no native TLS option (only gRPC has `--grpc-use-ssl*`), so endpoints that are not protected by a TLS-terminating gateway expose request and response data, including tensors and any restricted-API header values, to anyone on the network path. gRPC TLS and mutual TLS are optional and are off by default.
-7. **Build and supply chain.** `build.py`, the Dockerfiles and the dependencies fetched during the build determine what ends up in the released server and container images. Unpinned or unverified dependencies can introduce compromised code.
+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
 
-- Triton is deployed on a **trusted network** or behind a gateway that provides authentication, authorization, rate limiting and TLS termination. The server itself does not provide user identity or per-user authorization.
-- Operators who expose Triton beyond a trusted network configure `--http-address`, `--grpc-address` and the restricted-API options so that management APIs are not reachable by untrusted clients.
-- The **model repository is trusted and access-controlled.** Anyone who can write models or backends to the repository, or call the model repository API, is able to run code in the server. Models from untrusted sources must be reviewed or run in an isolated deployment.
-- Shared memory is used only between **mutually trusted processes on the same host**, and the host operating system and GPU driver enforce memory isolation correctly.
-- TLS certificates and keys provided through the `--grpc-use-ssl*` options, and any restricted-API header values, are stored and rotated securely by the operator.
-- Trace and log output locations are writable only by the server and readable only by authorized users.
-- Backends and third-party libraries (including the framework runtimes each backend embeds) are kept up to date and are not affected by known vulnerabilities in the deployed version.
+* 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 064b40cf2833fd522234b72ef51c94c299a3a835 Mon Sep 17 00:00:00 2001
From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com>
Date: Mon, 5 Oct 2026 20:55:59 +0000
Subject: [PATCH 5/7] docs: Add vulnerability reporting guidance to SECURITY.md

TRI-1935
---
 SECURITY.md | 35 +++++------------------------------
 1 file changed, 5 insertions(+), 30 deletions(-)

diff --git a/SECURITY.md b/SECURITY.md
index c223207bfe..1eda114bfe 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -43,37 +43,12 @@ If reporting a potential vulnerability via email, please encrypt it using NVIDIA
 
 See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins and Notices.
 
-## Additional Reporting Channels
+## Additional Reporting Guidance
 
-1. **NVIDIA Vulnerability Disclosure Program** (preferred): https://www.nvidia.com/en-us/security/
-2. **GitHub Private Vulnerability Reporting (where enabled):** use the "Report a vulnerability" button on the Security tab of this repository.
+**Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.**
 
-**Do not open a public issue or pull request to report a vulnerability.**
+Where the feature is enabled for this repository, you can also report a vulnerability privately through GitHub by using the "Report a vulnerability" button on the repository's Security tab.
 
-## Security Architecture and Context
+## Security Model
 
-**Project:** The Triton Inference Server provides an optimized cloud and edge inferencing solution.
-
-**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.
+The security of a Triton Inference Server deployment depends largely on how it is configured and where it is run. See [Secure Deployment Considerations](docs/customization_guide/deploy.md) for the deployment practices NVIDIA recommends.

From 1d440001eb4666d85dc95996cf54d3c4db96d9f3 Mon Sep 17 00:00:00 2001
From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com>
Date: Mon, 5 Oct 2026 21:11:01 +0000
Subject: [PATCH 6/7] docs: Add vulnerability reporting guidance to SECURITY.md

TRI-1935
---
 SECURITY.md | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/SECURITY.md b/SECURITY.md
index 1eda114bfe..4f4da40033 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -43,12 +43,4 @@ If reporting a potential vulnerability via email, please encrypt it using NVIDIA
 
 See https://www.nvidia.com/en-us/security/ for past NVIDIA Security Bulletins and Notices.
 
-## Additional Reporting Guidance
-
-**Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.**
-
-Where the feature is enabled for this repository, you can also report a vulnerability privately through GitHub by using the "Report a vulnerability" button on the repository's Security tab.
-
-## Security Model
-
-The security of a Triton Inference Server deployment depends largely on how it is configured and where it is run. See [Secure Deployment Considerations](docs/customization_guide/deploy.md) for the deployment practices NVIDIA recommends.
+**Please do not report security vulnerabilities through public issues or other public channels.**

From 2aac05c53408da16a871b314d6339f5e58e8606b Mon Sep 17 00:00:00 2001
From: "M. Chornyi" <99709299+mc-nv@users.noreply.github.com>
Date: Mon, 5 Oct 2026 21:33:47 +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 4f4da40033..e3a279a406 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