Repository navigation
docs: Add SECURITY.md - #18
Conversation
TRI-1935
|
TRI-1935
|
|
||
| ## 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. |
There was a problem hiding this comment.
Path traversal warning removed The new threat model replaces the specific warning about unchecked configuration paths with a general warning about untrusted input. If a deployment accepts model configuration from an authenticated but untrusted party, a key containing
../ can make the agent read outside the model directory and return that file’s digest in a mismatch error. Gateway authentication does not confine file access, so operators need the specific warning to identify which inputs must be trusted.
How this was verified: The configuration key supplies an unchecked path to ReadFile(), and a mismatch error includes the computed digest.
Knowledge Base Used: Native checksum agent implementation
|
|
||
| ## Security Architecture and Context | ||
|
|
||
| **Project:** The Triton repository agent that verifies model checksums. |
There was a problem hiding this comment.
Tamper protection limits omitted Describing the agent simply as verifying model checksums drops the previous warning that it is not a defense against deliberate tampering. It checks only files named in configuration parameters, accepts a model with no such parameters, and reads its MD5 expectations from the model configuration. An operator relying on it for tamper protection could therefore load unverified files or files changed together with their expected digests. Restore the limits on what this check protects.
How this was verified: The load callback compares MD5 digests only for configured parameters and succeeds when that list is empty.
Knowledge Base Used: Checksum repository agent
| 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. |
There was a problem hiding this comment.
Resource risk points elsewhere The replacement guidance points to oversized or numerous requests, but this agent reads an entire configured model file during an in-process load action; it does not serve inference requests. An operator could rate-limit a gateway while leaving large model files able to exhaust server memory. Identify model files and load-time verification as the resource risk.
How this was verified: The load callback passes configured file paths to ReadFile(), which allocates space for the whole file before hashing.
Knowledge Base Used: Checksum repository agent
| ## 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. |
There was a problem hiding this comment.
Repository immutability assumption omitted The revised assumptions say model inputs must come from trusted sources but omit the earlier requirement that the repository remain unchanged between verification and use. Even a file from a trusted source can be replaced after its load-time checksum and before the backend reads it, leaving the bytes actually loaded unverified. Restore the immutability assumption so operators do not mistake trusted provenance for continued integrity.
How this was verified: The agent hashes configured files during its load callback, before the backend uses them, and performs no later integrity check.
Knowledge Base Used: Checksum repository agent
What does the PR do?
SECURITY.md, which this repository did not have. Flagged by an AIVO asset review.NVIDIA/NeMo,cuda-pythonandMegatron-LM. Text is NVIDIA-authored, unmodified except the platform-neutral "GitHub/GitLab" wording fromcuda-python.Checklist
<commit_type>: <Title>Commit Type:
Check the conventional commit type
box here and add the label to the github PR.
Related PRs:
Where should the reviewer start?
SECURITY.md— compare againstNVIDIA/NeMo/SECURITY.mdfor the canonical wording.Test plan:
Documentation only; no code paths affected.
CI Pipeline ID:
Caveats:
NVIDIA/NeMosays "through GitHub",NVIDIA/cuda-pythonsays "through GitHub/GitLab". This PR uses the latter because Triton repositories exist on both GitHub and internal GitLab.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)