ONNX Security Assurance Case¶

Version: 1.0 (DRAFT) Date: February 2026 Project: ONNX (Open Neural Network Exchange) Scope: ONNX Core (onnx/onnx) and the produced Python wheel

This document provides the security assurance case for ONNX Core, supporting the OpenSSF Best Practices Badge application.

Out of scope: Inference engines and execution providers that consume ONNX models (e.g. ONNX Runtime) are separate projects and are not covered by this document.

1. Threat Model¶

Note: No specific threat modeling template (e.g. STRIDE, PASTA) was used. The threats below are identified based on the system’s attack surface and known risks for serialization/parsing libraries.

ONNX Core is the reference implementation of the ONNX standard, consisting of the IR specification, model validator (checker.cc), shape inference, protobuf serialization, and Python bindings.

1.1 Key Threats¶

ID	Threat	Impact	Likelihood
T1	Malicious model file causing code execution	Critical	Medium
T2	Model deserialization causing memory corruption	High	Medium
T3	DoS via crafted model (resource exhaustion during parsing)	Medium	High
T4	Supply chain compromise (malicious dependency or build)	Critical	Low
T5	Information disclosure via model inspection	Medium	Medium
T6	Compromised PyPI packages	High	Low

1.2 Trust Boundaries¶

┌─────────────────────────────────────────────────────┐
│  Untrusted Zone                                     │
│  - User-provided ONNX models, third-party deps      │
└────────────────┬────────────────────────────────────┘
                 │ Boundary #1  (validation, schema checks, size limits)
                 ▼
┌─────────────────────────────────────────────────────┐
│  ONNX Core Processing Environment                   │
│  - Model parser/deserializer (protobuf)             │
│  - Model validator (checker.cc), shape inference    │
└────────────────┬────────────────────────────────────┘
                 │ Boundary #2  (RAII, bounds checking)
                 ▼
┌─────────────────────────────────────────────────────┐
│  System Resources (file system, memory)             │
└─────────────────────────────────────────────────────┘

Boundary #3 (Build → Distribution): SLSA provenance, code signing, checksum verification.

2. Secure Design Principles (Saltzer & Schroeder)¶

Principle	Application in ONNX Core
Economy of Mechanism	Protocol Buffers for serialization; validation centralized in checker.cc; minimal dependencies
Fail-Safe Defaults	Validation on by default; must opt out with `check_model=False`; unknown protobuf fields rejected
Complete Mediation	Every model load goes through the validation pipeline; all operator inputs are type- and shape-checked
Least Privilege	No elevated privileges required; no network access; file I/O restricted to explicitly specified paths
Separation of Privilege	External data loading requires both model reference and file system access; releases require SLSA attestation
Least Common Mechanism	No global mutable state; validation is stateless; each API call operates independently
Psychological Acceptability	Secure defaults need no configuration; clear validation error messages; type-annotated Python API

3. Common Weaknesses Mitigated¶

CWE	Mitigation
CWE-787/125 Out-of-bounds R/W	Modern C++ (std::vector, RAII); ASan in CI
CWE-20 Input Validation	Comprehensive model validation on load; protobuf schema enforcement; operator shape/type checking
CWE-416 Use After Free	RAII/smart pointers (unique_ptr, shared_ptr); ASan in CI; code review
CWE-190 Integer Overflow	Checked size arithmetic in tensor allocation; UBSan in CI
CWE-22 Path Traversal	External data paths validated and normalized; no auto-resolution outside model directory
CWE-78 Command Injection	No shell execution in ONNX Core; no system()/exec() usage; enforced by code review and static analysis
OWASP A06 Supply Chain	Dependabot; Sigstore signing; minimal dependency footprint; SBOM generation
CWE-79/89/352/434	Not applicable — ONNX Core is not a web application or database

4. Security Testing¶

Method	Details
Static analysis	CodeQL (GitHub Advanced Security), Clang Static Analyzer, sonarcloud
Dynamic analysis	ASan, MSan, UBSan, TSan in CI build matrix
Fuzzing	not yet
Dependency scanning	Dependabot, OpenSSF Scorecard

5. Security Processes¶

Vulnerability disclosure: Reports via GitHub Security Advisories (preferred) or onnx-security@lists.lfaidata.foundation as a fallback; CVE assignment through Linux Foundation CNA. See SECURITY.md.

Code review: All changes require maintainer review; security-sensitive changes require Architecture SIG review; one approval for dependency updates; automated checks must pass before merge (CODEOWNERS).

Build & distribution: artifacts signed with Sigstore; PyPI Trusted Publishing with 2FA required for maintainers; SHA256 checksums published; actions pinned to SHA in CI.

6. Known Limitations¶

Model encryption: Not provided; users must handle externally
Formal verification: Limited formal verification of checker and shape inference logic
Sandboxing: No built-in sandboxing of model parsing; relies on OS/container isolation

References¶

ONNX Security Policy: https://github.com/onnx/onnx/blob/main/SECURITY.md
ONNX IR Spec: https://github.com/onnx/onnx/blob/main/docs/IR.md
Model Checker: https://github.com/onnx/onnx/blob/main/onnx/checker.cc
OpenSSF Best Practices: https://bestpractices.coreinfrastructure.org/
SLSA Framework: https://slsa.dev/
CWE Top 25: https://cwe.mitre.org/top25/
Saltzer & Schroeder Principles: https://web.mit.edu/Saltzer/www/publications/protection/

Document Maintainer: ONNX Architecture & Infrastructure SIG Last Updated: February 2026 Review Cycle: Annual (or upon significant architectural changes)