This document describes the detailed security threat model for Apache Iceberg Python. It is intended for maintainers and automated security triage.
Apache Iceberg Python is primarily a client library and implementation of the Iceberg table format and catalog interactions for Python applications and services. It is commonly embedded in larger systems that provide their own authentication, authorization, and credential management. Because of that deployment model, many bug classes that look security-relevant in the abstract are not actually security vulnerabilities in Iceberg Python itself.
This model is intended to answer:
This model is scoped to the Apache Iceberg Python repository itself:
It is not a general threat model for every Python service that embeds Iceberg Python.
In particular, it does not attempt to define the complete security model for:
Iceberg Python should:
Iceberg Python does not aim to be the primary enforcement point for:
The operator configures the surrounding catalog, application, service, and storage integration around Iceberg Python. This role is trusted to choose endpoints, warehouses, storage integrations, and credentials.
The catalog control plane resolves tables and supplies metadata, locations, configuration, and delegated credentials to Iceberg Python. It may be implemented by a REST catalog server or another catalog implementation. Iceberg Python assumes this control plane is trusted and outside its primary security boundary.
The REST catalog client consumes catalog-provided metadata, configuration, and credentials. Client-side bugs in routing, caching, or reuse may still be security-relevant if they leak credential-bearing state across boundaries that the Iceberg Python client is expected to preserve.
Applications and services embedding Iceberg Python are responsible for their own user-facing authorization boundaries unless Iceberg Python explicitly documents otherwise.
This role may already have legitimate power to write or replace table metadata, write or delete files, choose paths under an allowed warehouse or table location, and invoke destructive maintenance operations. If a report only shows a new way to achieve the same effect this role can already cause legitimately, it is usually not a security issue in Iceberg Python.
The following are generally treated as trusted operator or deployment inputs:
If a report depends on the attacker controlling those values directly, it is usually not a vulnerability in Iceberg Python itself.
Iceberg Python often accepts metadata locations, table properties, namespace properties, and related control-plane information from a catalog. By default, Iceberg Python treats those sources as trusted.
This means a malicious catalog supplying incorrect or malicious metadata is usually not an Iceberg Python vulnerability by itself.
In REST deployments, Iceberg Python may also accept service endpoints, configuration, and delegated storage access from the REST catalog server. By default, those are treated as trusted control-plane inputs unless Iceberg Python explicitly documents a stronger guarantee.
This means a malicious REST catalog server sending dangerous endpoints is usually not an Iceberg Python vulnerability by itself. It also means many credential-selection bugs are often correctness or specification issues rather than security boundary failures.
The major exception is secret exposure. If Iceberg Python surfaces credentials or secrets to a new audience that was not already trusted with them, that is security-relevant.
Object store permissions are enforced by the storage provider and the credentials the surrounding deployment chooses to hand to Iceberg Python. Iceberg Python is not the root authority for bucket- or object-level authorization.
The following categories are generally security-relevant in Iceberg Python when the report is credible and reproducible.
Examples include:
Security issues exist when Iceberg Python itself is expected to separate catalogs, clients, or principals and fails to do so.
Examples include:
These categories may still be real bugs worth fixing, but they are not usually security vulnerabilities in Iceberg Python itself.
Examples include incorrect metadata handling, ambiguous matching semantics, and logic bugs that do not create a new trust-boundary violation.
Malformed-input crashes, runtime exceptions, and memory amplification are usually treated as robustness or hardening work rather than security issues in Iceberg Python itself.
Reports that require a malicious catalog or other external control-plane service are usually outside Iceberg Python's primary security boundary.
If the actor already has a legitimate capability that can cause the same harm, the new path is usually not a security issue.
A scanner targeting Iceberg Python should treat a finding as higher-confidence only if it plausibly shows one of the following:
A finding should be downgraded or rejected by default if it instead depends primarily on: