Pydantic

General Information

Field	Value
Package Name	pydantic
Manufacturer / Vendor	Pydantic Team (Samuel Colvin, Sydney Runkle, and contributors)
Software Category	Library
Primary Documentation	Documentation, GitHub, PyPI, Blog
Programming Language(s)	Python, Rust (pydantic-core)
License	MIT License
Deployed Version(s)	>=2.12.0 (version-locked at 2.12.5 across services; includes email validation extra)
Most Recent Available Version	2.12.5
Last Review Date	2026-01-27

Overview

Pydantic is the most widely used data validation library for Python, leveraging Python's type hints to provide fast, extensible data parsing and validation. The core validation logic is written in Rust (via the pydantic-core package), making it among the fastest data validation libraries available. Pydantic V2 represents a ground-up rewrite offering significant performance improvements and new features compared to earlier versions.

Within the medical device software, Pydantic serves as the foundational data validation and modeling layer across the entire distributed architecture. It is integrated throughout the system in several critical capacities:

• Domain data models: The legithp-interface-models library defines all clinical domain entities using Pydantic, including severity assessments, sign detection results, segmentation outputs, and expert classifications. Custom base models (InmutableBaseModel, HumanUserBaseModel) enforce immutability and strict validation required for regulated medical device software
• API request/response contracts: All REST API endpoints in the API Gateway use Pydantic models for automatic request validation and response serialization, with camelCase aliasing for client compatibility
• Configuration management: The pydantic-settings extension provides type-safe environment variable loading across all 60+ expert microservices, with validation of storage providers, device specifications, and endpoint URLs
• Medical device compliance data: Regulatory compliance tracking including UDI (Unique Device Identifier) validation supporting GS1, HIBCC, and ICCBBA standards, manufacturer information, and device certification records
• Expert orchestration: The expert registry manages 60+ microservice URLs with type-safe validation and dynamic endpoint resolution
• HTTP client integration: The AsyncHttpClient in legithp-essentials uses Pydantic for request serialization and response validation with automatic error handling

Pydantic was selected over alternatives (attrs, marshmallow, cerberus) due to:

• Native integration with Python type hints enabling IDE support and static analysis
• High performance from Rust-based core validation engine
• Seamless integration with FastAPI for automatic API documentation and validation
• Comprehensive validation features including computed fields, discriminated unions, and custom validators
• Support for immutable models (frozen=True) essential for regulated medical device records
• Strict validation mode (extra="forbid") preventing unexpected data fields in clinical outputs
• Active maintenance with regular security updates and a responsive maintainer team
• MIT 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 data models with automatic validation from Python type hints	BaseModel class
FR-002	Configure model behavior including immutability and strict validation	ConfigDict with frozen, extra, populate_by_name
FR-003	Define field constraints with default values and metadata	Field() function with ge, le, min_length, max_length
FR-004	Apply string constraints for text field validation	StringConstraints with length limits
FR-005	Perform post-parsing validation with custom functions	AfterValidator annotation
FR-006	Implement custom parsing logic for complex types	PlainValidator annotation
FR-007	Validate individual fields with access to other field values	@field_validator decorator
FR-008	Perform cross-field validation after model construction	@model_validator decorator with mode="after"
FR-009	Generate derived values from other model fields	@computed_field decorator
FR-010	Serialize models to dictionaries with alias support	model_dump() method with by_alias parameter
FR-011	Validate data against model schema	model_validate() class method
FR-012	Generate JSON Schema for API documentation	model_json_schema() and WithJsonSchema annotation
FR-013	Convert field names between snake_case and camelCase	alias_generator=to_camel in config
FR-014	Validate email addresses with proper format checking	EmailStr type from pydantic[email] extra
FR-015	Validate URLs with protocol and format enforcement	HttpUrl, AnyHttpUrl types
FR-016	Support discriminated unions for polymorphic data	Field(discriminator="type") annotation
FR-017	Serialize enum values instead of enum objects	use_enum_values=True in config
FR-018	Load configuration from environment variables	BaseSettings from pydantic-settings

Performance Requirements

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

Requirement ID	Description	Acceptance Criteria
PR-001	Model validation shall complete within acceptable API latency bounds	Validation overhead < 5ms for typical request/response models
PR-002	Serialization shall not introduce significant latency in response handling	Serialization completes within overall API latency requirements
PR-003	Memory usage shall remain stable under sustained validation workloads	No memory leaks during continuous API operation
PR-004	Regex-based validation shall complete without excessive CPU consumption	No exponential backtracking in validation patterns

Hardware Requirements

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

Requirement ID	Description	Notes / Limitations
HR-001	x86-64 or ARM64 processor architecture	Pre-built wheels available for common platforms
HR-002	Sufficient system memory for model instantiation	Memory scales with model complexity and nesting depth

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.9
SR-002	Pydantic core validation engine	pydantic-core (bundled, written in Rust)
SR-003	Email validation support	email-validator package (via pydantic[email] extra)
SR-004	Typing extensions for advanced type hints	typing-extensions (bundled dependency)
SR-005	Environment variable loading (used by device)	pydantic-settings >=2.12.0

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-2024-3772 (email validation ReDoS)	Fixed	No	Moderate severity (CVSS 5.9) regular expression denial of service via crafted email string in email validation. Fixed in Pydantic 2.4.0; the device uses version-locked 2.12.5 which includes the fix	2026-01-27
GitHub Advisory GHSA-mr82-8j83-vxmv	Fixed	No	Same as CVE-2024-3772; email validation regex could cause exponential backtracking. The device's deployed version includes the patched regex implementation	2026-01-27

Pydantic is actively maintained by the Pydantic team with a responsible security disclosure process. The project maintains a security policy directing reporters to use GitHub's private vulnerability reporting mechanism rather than public issues. According to Snyk's vulnerability database, the deployed version (2.12.5) includes fixes for all known vulnerabilities.

The device's usage pattern minimizes attack surface exposure:

• Controlled input sources: All data validated by Pydantic originates from authenticated API endpoints or internal service-to-service communication; no validation of arbitrary external user-provided regex patterns occurs
• Version locking: Requirements lock files pin Pydantic to version 2.12.5, which includes fixes for CVE-2024-3772 and all prior security issues
• Email validation scope: While the device uses email validation (EmailStr), email addresses are only accepted from authenticated users for contact information purposes, not from arbitrary external input
• Strict validation mode: Models use extra="forbid" preventing injection of unexpected fields that could trigger edge-case parsing behavior
• Immutable records: Clinical result models use frozen=True, preventing post-validation modification that could bypass validation constraints
• Input sanitization: API gateway validates request size limits before Pydantic processing, preventing resource exhaustion from oversized payloads
• Container isolation: Each microservice runs in isolated containers with resource limits, containing any potential impact from validation issues

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
• Request size limits prevent resource exhaustion from oversized validation payloads
• Strict model configuration (extra="forbid") rejects unexpected fields
• Container isolation limits potential impact of any exploitation
• Audit logging with correlation IDs enables forensic analysis of validation failures

Assessment Methodology

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

• Sources consulted:

  • National Vulnerability Database (NVD) search for "pydantic"
  • GitHub Security Advisories for pydantic/pydantic
  • Snyk vulnerability database for Pydantic
  • CVE Details for Pydantic Project
  • Ubuntu Security Notices (USN-7101-1)
  • PyPI package security reports

• Criteria for determining applicability:

  • Vulnerability must affect deployed versions (Pydantic 2.12.5)
  • Vulnerability must be exploitable through the device's operational context (authenticated APIs, controlled data sources)
  • Attack vector must be reachable through the device's interfaces
  • Input validation, authentication, 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