Open Neural Network Exchange, or ONNX, is an open format for representing machine learning models so they can be moved between different frameworks and runtimes. It defines a common model graph and operator set, which helps with portability, deployment and interchange across training and inference tools.
Why ONNX exists and what it standardises
ONNX solves a practical portability problem: machine learning teams often train in one framework and deploy in another. By defining a shared model representation, it reduces rework when moving models across runtimes, inference stacks, and toolchains.
That portability is valuable, but it also means the file or artifact becomes part of the deployment surface. An ONNX model is not just a data blob, it encodes executable model structure, operator expectations, and assumptions that downstream systems must trust.
How ONNX models travel across frameworks and runtimes
ONNX is best understood as an interchange layer. A source framework exports a model graph into a common format, and a target runtime imports that graph for execution or optimisation. This allows organisations to separate model development from model serving more cleanly than tightly coupled framework-specific formats do.
In practice, that separation creates flexibility for performance tuning, hardware acceleration, and platform migration. It can also expose compatibility gaps if the source model depends on operators, custom layers, or preprocessing behaviour that the destination environment does not implement in the same way.
Security implications of portable model formats
Portable model formats are attractive because they are easy to move, but that same portability can amplify supply chain and integrity risks. A model exchanged between teams or vendors may be modified, wrapped, or re-serialised before deployment, so organisations should treat provenance and integrity as first-class concerns rather than assuming the file is safe because it is standardised.
ONNX also matters to defenders because model exchange can widen the trust boundary around inference environments. If a model artifact is sourced from outside the organisation, the surrounding pipeline should verify what was received, where it came from, and whether any supporting assets such as preprocessing code, weights, or metadata were changed in transit.
Where ONNX fits in an AI delivery pipeline
ONNX is most useful where teams need a common handoff point between training, optimisation, and inference. It is not a complete machine learning governance model on its own, but it often sits at a critical junction where portability, reproducibility, and operational control meet.
That makes ONNX especially relevant in environments that standardise model packaging across multiple teams or vendors. For readers assessing deployment risk, the key question is whether the organisation controls the model artifact lifecycle, not just whether the model can technically run somewhere else.
Risk and Threat Considerations
Portable model artifacts can be abused when organisations trust the interchange format more than the provenance of the model itself. A compromised or tampered model can carry integrity issues into downstream runtimes, especially when teams convert models across tools without strong validation or review.
Failure mechanism: Attackers or careless intermediaries can alter a model artifact, substitute a malicious or degraded model, or exploit weak validation in the conversion and deployment chain.
Impact: The organisation may deploy an untrusted model, inherit faulty behaviour in production, or lose confidence in inference results and the systems that depend on them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Software Supply Chain Security | ONNX models move through build and deployment chains that need integrity and provenance. |
| Recommendation — Treat model artifacts as supply-chain outputs and require provenance checks before deployment. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | ONNX is an application artifact that should be protected through secure validation and release practices. |
| Recommendation — Validate imported model artifacts before they are accepted into production workflows. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | ONNX artifacts need integrity verification to detect tampering before execution. |
| Recommendation — Verify the integrity of model files before loading them into training or inference systems. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | ONNX deployment pipelines often fail when runtimes, loaders, or supporting settings are misconfigured. |
| Recommendation — Harden model-serving configurations so imported artifacts cannot exploit unsafe defaults. | ||
Related resources from NHI Mgmt Group
- How should security teams use Integrated Gradients to explain deep neural network predictions in practice?
- What happens when an LLM-generated program runs with open network access?
- How should security teams secure remote privileged access in hybrid and multi-cloud environments without relying on VPNs or open network ports?
- What happens when a container is allowed to run shell scripts, spawn new processes, and open outbound network connections without runtime controls?