You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@iceberg.apache.org by "sungwy (via GitHub)" <gi...@apache.org> on 2026/05/23 03:33:53 UTC

[PR] Docs: Publish Iceberg security model [iceberg]

sungwy opened a new pull request, #16538:
URL: https://github.com/apache/iceberg/pull/16538

   This PR publishes a security model for Iceberg and links it from `AGENTS.md` so there is a single reference for how the project distinguishes security issues from other bugs.
   
   The goal is to make Iceberg’s security boundaries explicit for both human triage and automated scanning, and to reduce false positives in future security reporting.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on PR #16538:
URL: https://github.com/apache/iceberg/pull/16538#issuecomment-4544669150

   I do not believe this is quite what is required for an automated scan. I would take a look at the skill provided here by ASF security team https://gist.github.com/potiuk/da14a826283038ddfe38cc9fe6310573 which I think can generate something a bit more friendly to automated screening tools


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "steveloughran (via GitHub)" <gi...@apache.org>.
steveloughran commented on PR #16538:
URL: https://github.com/apache/iceberg/pull/16538#issuecomment-4579026589

   This is good; I do think the ASF needs some templates here for the security models (file formats, servers/services, databases, cluster workload engines). This is a good example of one.
   
   I'm working on one elsewhere where I've added developers and CI into the model, as supply chain attacks are things we want audits to pick up, and as instructions to agents.
   
   Again, something we really need some ASF-wide templates to get started with.
   
   There is a security-discuss list for these topics, though it's pretty quiet right now. 
   
   ---
   
   ### Development Environment Threat Model
   
   The project is built on developer systems, and in CI systems.
   
   The threat model includes the risk of subverted github actions and build tooling.
   * git checksum references MUST be made to GitHub actions, rather than tags; include the version as a comment so dependabot will track and maintain them.
   * [Zizmor](https://zizmor.sh/) SHALL be used to audit GHAs.
   * GHA triggers on PRs MUST NOT be triggers which provide unrestricted github tokens to the actions.
      For example, there MUST NOT be `pull_request_target`, `workflow_run`, or `issue_comment` triggers. 
   * Github Actions SHALL follow GitHub's [secure use](https://docs.github.com/en/actions/reference/security/secure-use) guidelines, and in particular use [Intermediate Environment Variables](https://docs.github.com/en/actions/reference/security/secure-use#use-an-intermediate-environment-variable) to safely process untrusted inputs.
   * All inputs from pull requests, including titles, comments, authors and code SHALL be considered untrusted.
   
   The CI build output will be publicly visible, so the threat model includes
   - unobfuscated logging of any cloud credentials provided by CI runs.
     


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on PR #16538:
URL: https://github.com/apache/iceberg/pull/16538#issuecomment-4565976144

   Since we are on a bit of a deadline for Glasswing, I would suggest merging this @sungwy and submitting ourselves to the project. We could also wait another few hours but I feel like a followup pr is just as good here if folks have other modifications


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "sungwy (via GitHub)" <gi...@apache.org>.
sungwy commented on PR #16538:
URL: https://github.com/apache/iceberg/pull/16538#issuecomment-4559946620

   > I'm good with this as is, I assume we'll be iterating on this in the future. Could you do a quick analysis of all of the issues we recently raised (check for rdblue's recently created issues) and give us a summary of what the threat model says about each issue?
   
   Thanks @RussellSpitzer 
   
   Yeah, I initially ran Codex/GPT-5 against this model which had a 75-80% accuracy in correctly classifying those reports. Claude Opus 4.7 did even better at around 85%. I've just uploaded the detailed summary of these runs in this [public gist](https://gist.github.com/sungwy/d9ef24d4e9939c1c8c23f81b44450767).
   
   In short, in the Opus run, 7 reports out of 43 required human review. Of these 1 was a valid security report and 2 others were handled in _Private_ first, not as Iceberg security disclosures, but to give catalog maintainers a heads-up before public disclosure. The other 4 reports are, in my opinion, reports that would be best to classify as ambiguous reports that would be more safe to involve human review for now. 
   
   So I agree with iterating on this over time.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "sungwy (via GitHub)" <gi...@apache.org>.
sungwy merged PR #16538:
URL: https://github.com/apache/iceberg/pull/16538


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "sungwy (via GitHub)" <gi...@apache.org>.
sungwy commented on code in PR #16538:
URL: https://github.com/apache/iceberg/pull/16538#discussion_r3314526462


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,260 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Iceberg Security Threat Model
+
+This document describes Apache Iceberg's detailed security threat model for
+maintainers and automated security triage.
+
+It complements the shorter public-facing security model in
+[`site/docs/security.md`](site/docs/security.md) by making Iceberg's trust
+assumptions, security boundaries, and recurring non-security bug classes more
+explicit.
+
+## Purpose
+
+Apache Iceberg is often deployed as a library and integration layer inside
+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 itself.
+
+This model is intended to answer:
+
+- what Iceberg generally treats as a security vulnerability
+- what Iceberg generally treats as correctness, hardening, or deployment work
+- which boundaries are primarily owned by Iceberg versus the surrounding
+  catalog, engine, or service
+- which issue classes should be downgraded by default by scanners
+
+## Scope
+
+This model is scoped to the Apache Iceberg project itself:
+
+- the table format implementation
+- client libraries
+- engine integrations
+- catalog-related components shipped in the Iceberg repository
+
+It is not a general threat model for every deployment that embeds Iceberg.
+
+In particular, it does not attempt to define the complete security model for:
+
+- query engines or applications that embed Iceberg
+- storage-level authorization enforced outside Iceberg
+
+## Security Goals
+
+Iceberg should:
+
+- avoid exposing secrets or delegated credentials to principals that were not
+  already trusted with them
+- avoid creating new unauthorized capabilities in Iceberg-owned components or
+  integrations
+- avoid violating trust boundaries that Iceberg itself owns, such as leaking
+  signer, auth, or credential-bearing state across catalog or session
+  boundaries in the same process
+
+Iceberg does not aim to be the primary enforcement point for:
+
+- user-to-user authorization inside a query engine
+- storage-level authorization
+- service-side credential scoping performed by an external catalog
+
+## Roles
+
+### Operator
+
+The operator deploys and configures the catalog, metastore, REST service,
+engine, and storage integration around Iceberg. This role is trusted to choose
+endpoints, warehouses, and storage integrations, configure credentials, and
+decide which users may create tables, read tables, or invoke maintenance
+actions.
+
+### Catalog control plane
+
+The catalog control plane is responsible for resolving tables and supplying
+metadata, locations, configuration, and delegated credentials to Iceberg. This
+role may be implemented by a REST catalog server, a metastore-backed catalog,
+or another catalog implementation. Regardless of how it is implemented, it
+should not expose secrets to unintended principals or leak credential-bearing
+state across unintended boundaries.
+
+Many reported issues assume a malicious catalog or metastore, which Iceberg

Review Comment:
   agreed - adopted this suggestion



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on code in PR #16538:
URL: https://github.com/apache/iceberg/pull/16538#discussion_r3313393507


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,260 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Iceberg Security Threat Model
+
+This document describes Apache Iceberg's detailed security threat model for
+maintainers and automated security triage.
+
+It complements the shorter public-facing security model in
+[`site/docs/security.md`](site/docs/security.md) by making Iceberg's trust
+assumptions, security boundaries, and recurring non-security bug classes more
+explicit.
+
+## Purpose
+
+Apache Iceberg is often deployed as a library and integration layer inside
+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 itself.
+
+This model is intended to answer:
+
+- what Iceberg generally treats as a security vulnerability
+- what Iceberg generally treats as correctness, hardening, or deployment work
+- which boundaries are primarily owned by Iceberg versus the surrounding
+  catalog, engine, or service
+- which issue classes should be downgraded by default by scanners
+
+## Scope
+
+This model is scoped to the Apache Iceberg project itself:
+
+- the table format implementation
+- client libraries
+- engine integrations
+- catalog-related components shipped in the Iceberg repository
+
+It is not a general threat model for every deployment that embeds Iceberg.
+
+In particular, it does not attempt to define the complete security model for:
+
+- query engines or applications that embed Iceberg
+- storage-level authorization enforced outside Iceberg
+
+## Security Goals
+
+Iceberg should:
+
+- avoid exposing secrets or delegated credentials to principals that were not
+  already trusted with them
+- avoid creating new unauthorized capabilities in Iceberg-owned components or
+  integrations
+- avoid violating trust boundaries that Iceberg itself owns, such as leaking
+  signer, auth, or credential-bearing state across catalog or session
+  boundaries in the same process
+
+Iceberg does not aim to be the primary enforcement point for:
+
+- user-to-user authorization inside a query engine
+- storage-level authorization
+- service-side credential scoping performed by an external catalog
+
+## Roles
+
+### Operator
+
+The operator deploys and configures the catalog, metastore, REST service,
+engine, and storage integration around Iceberg. This role is trusted to choose
+endpoints, warehouses, and storage integrations, configure credentials, and
+decide which users may create tables, read tables, or invoke maintenance
+actions.
+
+### Catalog control plane
+
+The catalog control plane is responsible for resolving tables and supplying
+metadata, locations, configuration, and delegated credentials to Iceberg. This
+role may be implemented by a REST catalog server, a metastore-backed catalog,
+or another catalog implementation. Regardless of how it is implemented, it
+should not expose secrets to unintended principals or leak credential-bearing
+state across unintended boundaries.
+
+Many reported issues assume a malicious catalog or metastore, which Iceberg

Review Comment:
   Not sure we need this line? Could just be 
   
   Iceberg assumes a trusted catalog which is outside its primary security boundary.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] Docs: Publish Iceberg security model [iceberg]

Posted by "sungwy (via GitHub)" <gi...@apache.org>.
sungwy commented on PR #16538:
URL: https://github.com/apache/iceberg/pull/16538#issuecomment-4556682811

   > I do not believe this is quite what is required for an automated scan. I would take a look at the skill provided here by ASF security team https://gist.github.com/potiuk/da14a826283038ddfe38cc9fe6310573 which I think can generate something a bit more friendly to automated screening tools
   
   Thanks for the feedback @RussellSpitzer 
   
   I think that’s a good point. I think it makes sense to separate the shorter human-facing security model from the more detailed model used for automated triage and scanning. I’ve updated the PR to add a more detailed `SECURITY-THREAT-MODEL.md`, and `AGENTS.md` now points to that document.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org