docs: Add SECURITY.md

[mc-nv]

What does the PR do?

• Adds SECURITY.md, which this repository did not have. Flagged by an AIVO asset review.
• Uses NVIDIA's current standard template, as in NVIDIA/NeMo, cuda-python and Megatron-LM. Text is NVIDIA-authored, unmodified except the platform-neutral "GitHub/GitLab" wording from cuda-python.
• Reporting policy only: no threat model or architecture section.
• Applied across all Triton repositories.

Checklist

• PR title reflects the change and is of format <commit_type>: <Title>
• Changes are described in the pull request.
• Related issues are referenced.
• Populated github labels field
• Added test plan and verified test passes.
• Verified that the PR passes existing CI.
• Verified copyright is correct on all changed files.
• Added succinct git squash message before merging ref.
• All template sections are filled out.
• Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:

Check the conventional commit type
box here and add the label to the github PR.

• build
• ci
• docs
• feat
• fix
• perf
• refactor
• revert
• style
• test

Related PRs:

• docs: Adopt current NVIDIA SECURITY.md template server#8997

Where should the reviewer start?

• SECURITY.md — compare against NVIDIA/NeMo/SECURITY.md for the canonical wording.

Test plan:

• Documentation only; no code paths affected.

• CI Pipeline ID:

Caveats:

• NVIDIA ships two variants of the warning sentence: NVIDIA/NeMo says "through GitHub", NVIDIA/cuda-python says "through GitHub/GitLab". This PR uses the latter because Triton repositories exist on both GitHub and internal GitLab.
• The template's PGP wording is "we encourage you" rather than a hard requirement. Kept as-is for template fidelity; raised on docs: Adopt current NVIDIA SECURITY.md template server#8997.

Background

An AIVO asset review (securityportal.nvidia.com/aivo/assets) flagged Triton repositories with no SECURITY.md. Rather than authoring per-repository security documentation, every repository adopts NVIDIA's current standard template so the policy is identical everywhere and carries no repository-specific claims to maintain.

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• Resolves: TRI-1935

[greptile-apps]

Confidence Score: 5/5

[Low risk] Adds security reporting guidance document.

The documentation change appears safe to merge.

Findings

1.  False host security boundary ▶
2.  Client requests called trusted ▶

Summary

Adds NVIDIA’s standard security-reporting policy to SECURITY.md, replacing repository-specific architecture and threat-model text. Reporters are directed to the NVIDIA submission form or PSIRT email.

_{Reviews (4) · Last reviewed commit: "docs: Adopt current NVIDIA SECURITY.md t..."}

[greptile-apps]

False host security boundary

The new description places a security boundary between the backend and its hosting server. This backend is a shared library that runs inside the Triton server process with the server’s privileges. An operator relying on this threat model could wrongly assume a compromised model or backend is isolated from the server. State explicitly that there is no process boundary between them.

Suggested change

	**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.
	**Security boundaries:** Models, configuration and request data enter the backend through Triton. The backend runs inside the Triton server process with the server's privileges; there is no process security boundary between them.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Client requests called trusted

The assumption that “other inputs” come from trusted sources appears to include inference requests, although the threat model says requests can come from untrusted clients. Request tensor data reaches ONNX Runtime after structural checks. This wording makes it harder for operators to distinguish client-controlled requests from trusted model artifacts and configuration.

Suggested change

	* Models, configuration and other inputs come from trusted sources.
	* Models and configuration come from trusted sources; inference requests may come from untrusted clients and must not be assumed trusted.