Ultralytics YOLO
General Information
| Field | Value |
|---|---|
| Package Name | ultralytics |
| Manufacturer / Vendor | Ultralytics Inc. |
| Software Category | Library |
| Primary Documentation | Documentation, GitHub, PyPI |
| Programming Language(s) | Python |
| License | AGPL-3.0 (Enterprise license available) |
| Deployed Version(s) | >=8.3.50 |
| Most Recent Available Version | 8.4.7 |
| Last Review Date | 2026-01-26 |
Overview
Ultralytics is a state-of-the-art computer vision library that provides implementations of the YOLO (You Only Look Once) family of object detection models. The library supports multiple vision AI tasks including object detection, instance segmentation, image classification, pose estimation, and oriented bounding box detection, with models optimized for both accuracy and inference speed.
Within the medical device software, ultralytics serves as the foundational object detection framework in the legithp-expert detection module. It powers multiple clinical expert microservices for automated lesion detection in dermatological images:
- Acneiform lesion detection: Identifying pustules, papules, and other acne-related clinical signs
- Hair follicle detection: Counting and localizing hair follicles for alopecia assessment and hair density analysis
- Hive detection: Localizing urticarial wheals in clinical images
- Inflammatory nodular lesion detection: Detecting abscesses, draining tunnels, and nodules using oriented bounding boxes for improved accuracy on irregularly shaped lesions
- Head detection: Auxiliary detection for image preprocessing and region-of-interest extraction
The library was selected for its comprehensive YOLOv8 implementation, support for both axis-aligned and oriented bounding boxes (essential for irregularly shaped dermatological lesions), active maintenance with regular security updates, efficient inference on both CPU and GPU hardware, and extensive model export capabilities for deployment optimization.
Functional Requirements
The following functional capabilities of this SOUP are relied upon by the medical device software.
| Requirement ID | Description | Source / Reference |
|---|---|---|
| FR-001 | Load pre-trained YOLO model weights from .pt checkpoint files | YOLO class constructor |
| FR-002 | Perform object detection inference on RGB image arrays | YOLO.__call__() method |
| FR-003 | Return detection results with bounding box coordinates and confidence scores | Results class |
| FR-004 | Support axis-aligned bounding boxes (xyxy format) for standard detection | Boxes class |
| FR-005 | Support oriented bounding boxes (xyxyxyxy format) for rotated detection | OBB class |
| FR-006 | Provide class label mapping from model vocabulary | Results.names property |
| FR-007 | Support configurable confidence thresholds for detection filtering | conf parameter |
| FR-008 | Support configurable IoU thresholds for non-maximum suppression | iou parameter |
| FR-009 | Support class-agnostic NMS for multi-class detection scenarios | agnostic_nms parameter |
| FR-010 | Enable device placement (CPU/CUDA) for inference optimization | YOLO.to() method |
Performance Requirements
The following performance expectations are relevant to the medical device software.
| Requirement ID | Description | Acceptance Criteria |
|---|---|---|
| PR-001 | Detection inference shall complete within acceptable API latency bounds | Inference completes within the overall request timeout |
| PR-002 | Memory usage shall scale predictably with model size and input resolution | No memory leaks during repeated inference operations |
| PR-003 | GPU utilization shall be efficient for batch-size-1 inference | Single-image processing without unnecessary overhead |
Hardware Requirements
The following hardware dependencies or constraints are imposed by this SOUP component.
| Requirement ID | Description | Notes / Limitations |
|---|---|---|
| HR-001 | CUDA-compatible GPU recommended for optimal performance | CPU execution supported but significantly slower |
| HR-002 | Sufficient GPU memory for model weights and activations | Memory requirements scale with model variant (nano to extra-large) |
| HR-003 | x86-64 or ARM64 processor architecture | Pre-built wheels available for common platforms |
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.8 |
| SR-002 | PyTorch deep learning framework | Compatible with torch >=1.8 |
| SR-003 | NumPy for array operations | Required for image data handling |
| SR-004 | OpenCV for image preprocessing | cv2 module for format conversion |
| SR-005 | torchvision for model operations | Compatible versions with torch |
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 |
|---|---|---|---|---|
| Supply Chain Attack (Dec 2024) | Fixed | No | Affected versions 8.3.41, 8.3.42, 8.3.45, 8.3.46 only; the device uses >=8.3.50 which includes remediation | 2026-01-26 |
| GitHub Actions Injection | Fixed | No | Build infrastructure vulnerability exploited in Dec 2024 attack; Ultralytics implemented security hardening post-incident | 2026-01-26 |
| PyTorch CVE-2025-32434 (torch.load RCE) | Fixed | No | The device does not use torch.load() with untrusted model files; all models are pre-deployed and signed | 2026-01-26 |
| PyTorch CVE-2025-2953 (DoS) | Open | No | Affects mkldnn_max_pool2d function not used by the device's detection pipelines | 2026-01-26 |
The most significant security incident affecting ultralytics was a supply chain compromise in December 2024. Malicious actors exploited a vulnerability in GitHub Actions to inject cryptomining malware into versions 8.3.41, 8.3.42, 8.3.45, and 8.3.46 on PyPI. The attack was detected and remediated within days, with clean versions released starting from 8.3.43 and definitively from 8.3.47 onwards after API token rotation.
The device's minimum version requirement of >=8.3.50 ensures only post-remediation releases are deployed. Additionally, the device implements the following safeguards:
- Pinned dependencies: Version constraints prevent accidental installation of compromised versions
- Internal artifact repository: Production deployments use internally vetted package mirrors rather than direct PyPI access
- Model file verification: YOLO model weights (.pt files) are pre-deployed and integrity-verified, not downloaded at runtime
According to Ultralytics' security policy, the project employs Snyk scanning, GitHub CodeQL analysis, Dependabot alerts, and secret scanning for continuous security monitoring. The project maintains active security practices and responds promptly to reported vulnerabilities.
Risk Control Measures
The following risk control measures are implemented to mitigate potential security and operational risks associated with this SOUP component:
- Version pinning above known-compromised releases (>=8.3.50) ensures only post-remediation versions are deployed
- Internal package repositories (artifact mirrors) are used rather than direct PyPI access in production
- Only pre-vetted model weights (.pt files) are deployed; no runtime model downloading
- Detection services are isolated from external code execution paths
- 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), GitHub Security Advisories, Snyk vulnerability database, vendor security bulletins, and security research publications from Wiz, BleepingComputer, and CSO Online
- Criteria for determining applicability: Vulnerabilities were assessed based on affected version ranges, attack vectors (supply chain vs. runtime), and whether the device's deployment model exposes the vulnerable functionality
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 Design & Development Manager, JD-004 Quality Manager & PRRC
- Approver: JD-001 General Manager