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 PR appears safe to merge, though the earlier non-blocking concern about omitted local shared-memory guidance remains.

Findings

1.  Project scope omits clients. ▶
2.   Local shared-memory boundary omitted. ▶

Summary

The PR replaces repository-specific security guidance with NVIDIA’s standard vulnerability-reporting policy.

• Directs reports to NVIDIA’s submission form or PSIRT email.
• Removes the repository-specific architecture and threat-model sections.

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

[greptile-apps]

Project scope omits clients. The project description leaves out the Rust client library and JavaScript generated-client example, although both remain in this repository. Readers assessing security coverage or reporting a vulnerability in either component may be unsure whether this policy applies.

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]

Local shared-memory boundary omitted. General host-security language replaces the warning that shared-memory access depends on local permissions and handle secrecy, and that regions require cleanup. A gateway does not protect this local boundary. Operators using system or CUDA shared memory may overlook access to tensor data by other local processes. How this was verified: The C++ client creates and maps POSIX shared-memory regions, exposes a separate unlink operation, and the CUDA client exports IPC handles.