PyTorch

General Information

Field	Value
Package Name	torch (PyTorch)
Manufacturer / Vendor	PyTorch Foundation / Linux Foundation (Meta AI, Google, Microsoft, Amazon, and contributors)
Software Category	Framework
Primary Documentation	Documentation, GitHub, PyPI, Tutorials
Programming Language(s)	Python, C++, CUDA
License	BSD License
Deployed Version(s)	>=2.0.0, >=2.1.0 (version-locked at 2.9.1)
Most Recent Available Version	2.10.0
Last Review Date	2026-01-26

Overview

PyTorch is an open-source deep learning framework that provides tensor computation with strong GPU acceleration and automatic differentiation for building and training neural networks. Originally developed by Meta AI Research, it is now maintained by the PyTorch Foundation under the Linux Foundation, with contributions from major technology organizations including Google, Microsoft, Amazon, and the broader research community.

Within the medical device software, PyTorch serves as the foundational deep learning framework powering all AI/ML inference capabilities. It is integrated throughout the system architecture:

• Core inference platform: The PytorchModelAdapter abstraction in the legithp-expert framework provides a standardized interface for loading, executing, and managing all neural network models used by the device
• Clinical condition classification: Multi-class skin disease classification with integrated clinical metadata (patient sex, age, body site) using custom neural network architectures built on torch.nn.Module
• Medical image segmentation: Pixel-wise segmentation of skin lesions, hair loss regions, and inflammatory patterns via encoder-decoder architectures (UNet, UNet++, FPN) implemented through segmentation-models-pytorch
• Explainability generation: GradCAM++ saliency maps that highlight image regions influencing AI predictions, implemented using pytorch-grad-cam
• GPU resource management: CUDA device enumeration, memory monitoring, utilization tracking, and thermal management through the torch.cuda module
• Object detection: YOLO-based lesion detection through the Ultralytics library, which uses PyTorch as its backend

PyTorch was selected over alternatives (TensorFlow, JAX, ONNX Runtime) due to:

• Industry-leading adoption in medical imaging and computer vision research
• Flexible imperative programming model enabling rapid prototyping and debugging
• Comprehensive GPU acceleration via CUDA with automatic memory management
• Strong ecosystem of pre-trained models (timm, torchvision) and architectures (segmentation-models-pytorch)
• Active maintenance with regular security updates and long-term support
• BSD license permitting commercial use in medical device software

Functional Requirements

The following functional capabilities of this SOUP are relied upon by the medical device software.

Requirement ID	Description	Source / Reference
FR-001	Define neural network architectures via composable module API	torch.nn.Module base class
FR-002	Execute forward pass inference through neural networks	model(input) or model.forward(input)
FR-003	Disable gradient computation for efficient inference	@torch.no_grad() decorator and context manager
FR-004	Load serialized model weights from state dictionary files	torch.load() with weights_only=True
FR-005	Transfer tensors and models between CPU and GPU devices	.to(device) method, torch.device()
FR-006	Create tensors with specified values, shapes, and device placement	torch.zeros(), torch.ones(), torch.randn()
FR-007	Concatenate and stack tensors along specified dimensions	torch.cat(), torch.stack()
FR-008	Detect and enumerate available CUDA-capable GPU devices	torch.cuda.is_available(), torch.cuda.device_count()
FR-009	Query GPU device properties (memory, compute capability)	torch.cuda.get_device_properties()
FR-010	Monitor GPU memory allocation and utilization	torch.cuda.memory_allocated(), torch.cuda.utilization()
FR-011	Synchronize CUDA operations and release cached memory	torch.cuda.synchronize(), torch.cuda.empty_cache()
FR-012	Provide fully connected, normalization, activation, and dropout layers	nn.Linear, nn.BatchNorm1d, nn.GELU, nn.Dropout
FR-013	Perform tensor interpolation for image resizing	torch.nn.functional.interpolate()
FR-014	Validate tensor values for numerical stability (NaN/Inf detection)	torch.isnan(), torch.isinf()
FR-015	Support adaptive pooling for variable input sizes	nn.AdaptiveAvgPool2d
FR-016	Flatten tensors for transition from convolutional to fully connected layers	torch.flatten()

Performance Requirements

The following performance expectations are relevant to the medical device software.

Requirement ID	Description	Acceptance Criteria
PR-001	Model inference shall complete within acceptable API latency bounds	Single image inference < 5 seconds on target GPU hardware
PR-002	GPU memory usage shall allow concurrent model loading for multi-task pipelines	Multiple expert models fit within allocated GPU memory
PR-003	Tensor operations shall maintain IEEE 754 float32 numerical precision	No loss of precision affecting clinical classification accuracy
PR-004	CUDA synchronization shall not introduce significant inference latency overhead	Synchronization overhead < 5% of total inference time
PR-005	Memory cache clearing shall prevent GPU memory exhaustion during continuous operation	No out-of-memory errors during sustained production workloads

Hardware Requirements

The following hardware dependencies or constraints are imposed by this SOUP component.

Requirement ID	Description	Notes / Limitations
HR-001	CUDA-compatible NVIDIA GPU required for production inference	CPU inference supported but not recommended for production latency
HR-002	CUDA Compute Capability 3.5 or higher	Required for PyTorch CUDA operations
HR-003	Sufficient GPU memory for model weights and intermediate tensors	Minimum 4GB VRAM recommended; varies by model architecture
HR-004	x86-64 or ARM64 processor architecture	Pre-built wheels available for common platforms
HR-005	System memory for model loading and data preprocessing	Minimum 16GB RAM recommended for model operations

Software Requirements

The following software dependencies and environmental assumptions are required by this SOUP component.

Requirement ID	Description	Dependency / Version Constraints
SR-001	Python runtime environment	Python >=3.10
SR-002	NVIDIA CUDA Toolkit for GPU acceleration	CUDA 11.8 or 12.x (bundled with PyTorch wheels)
SR-003	cuDNN library for deep learning primitives	Compatible version bundled with PyTorch
SR-004	NumPy for array interoperability	Compatible NumPy version for tensor conversion
SR-005	NVIDIA driver supporting installed CUDA version	Driver version >=525.60.13 for CUDA 12.x

Known Anomalies Assessment

This section evaluates publicly reported issues, defects, or security vulnerabilities associated with this SOUP component and their relevance to the medical device software.

Anomaly Reference	Status	Applicable	Rationale	Reviewed At
CVE-2025-32434 (torch.load RCE with weights_only=True)	Fixed	No	Critical RCE vulnerability (CVSS 9.3) affecting PyTorch <=2.5.1 where torch.load() with weights_only=True could still execute arbitrary code. Fixed in PyTorch 2.6.0; the device uses version-locked PyTorch 2.9.1 which includes the fix	2026-01-26
CVE-2025-2953 (mkldnn_max_pool2d DoS)	Open	No	Denial of service via mkldnn_max_pool2d function with specific tensor shapes; the device does not use MKL-DNN pooling operations and validates input shapes before inference	2026-01-26

In addition to the CVEs listed above, inherent risks in Python's pickle format used by PyTorch model files were considered. These risks are mitigated by using only pre-deployed, internally verified model weights from trusted sources.

PyTorch is actively maintained by the PyTorch Foundation with a robust security response process. The project maintains a security policy and uses GitHub Security Advisories for coordinated disclosure. According to Feedly's vulnerability tracking, the PyTorch team has demonstrated prompt patching of reported vulnerabilities.

The device's usage pattern minimizes attack surface exposure:

• No untrusted model loading: All neural network weights are pre-deployed, internally verified, and shipped with the device; no model files are loaded from user input or external sources at runtime
• Version locking: Requirements lock files pin PyTorch to version 2.9.1, which includes fixes for CVE-2025-32434 and all prior critical vulnerabilities
• Safe deserialization: Model loading uses weights_only=True parameter combined with PyTorch >=2.6.0, providing defense-in-depth against pickle-based attacks
• Input validation: All inference inputs are validated for shape, type, and numerical range before being passed to PyTorch operations
• Isolated execution: Model inference runs in containerized environments with restricted filesystem and network access
• No dynamic code execution: The device uses only forward-pass inference; no training, no torch.compile(), no JIT compilation from untrusted sources

Risk Control Measures

The following risk control measures are implemented to mitigate potential security and operational risks associated with this SOUP component:

• Version locking via requirements_lock.txt ensures reproducible, auditable deployments with known-secure versions
• All model weights are sourced from internal development pipelines with integrity verification
• Model files are cached and cryptographically verified before deployment
• Input validation at API boundaries prevents malformed data from reaching PyTorch operations
• GPU memory management guards prevent resource exhaustion attacks
• Container isolation limits potential impact of any exploitation

Assessment Methodology

The following methodology was used to identify and assess known anomalies:

• Sources consulted:

  • National Vulnerability Database (NVD) search for "pytorch" and "torch"
  • GitHub Security Advisories for pytorch/pytorch
  • PyTorch security policy and disclosure process
  • PyPI package security reports
  • Snyk vulnerability database
  • JFrog security research on pickle-related ML vulnerabilities

• Criteria for determining applicability:

  • Vulnerability must affect deployed versions (2.9.1)
  • Vulnerability must be exploitable in the device's operational context (production inference, no training)
  • Attack vector must be reachable through the device's interfaces (no external model loading, no untrusted user code execution)
  • Input validation and isolation controls must not mitigate the vulnerability

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001