Document Security Policy by alamb · Pull Request #9730 · apache/arrow-rs

alamb · 2026-04-15T12:52:32Z

Which issue does this PR close?

Closes Add a security policy for arrow-rs #9727

Rationale for this change

Other arrow subprojects (C++ in particular) has been beset recently by a deluge of low quality bug reports masquerading as security problems.

To reduce this flow and make it easier to direct people to the appropriate bug vs feature venue, we should document our security posture better

What changes are included in this PR?

Add SECURITY.md
Clarify what is a bug vs a security issue
Sprinkle links to SECURITY around

Are these changes tested?

By CI

Are there any user-facing changes?

yes, new policyt

alamb · 2026-04-15T12:54:26Z

FYI @scovich @Jefffrey @etseidl @tustvold @jhorstmann, and @crepererum who may be interested in commenting on this policy

scovich

The doc and associated link sprinkling seem very reasonable and welcome, but I don't think I understand how this will "reduce the flow" of "a deluge of low quality bug reports masquerading as security problems" ?

Or does it just make it easier to summarily close them because they don't follow the official guidelines?

alamb · 2026-04-15T18:29:41Z

The doc and associated link sprinkling seem very reasonable and welcome,

❤️

but I don't think I understand how this will "reduce the flow" of "a deluge of low quality bug reports masquerading as security problems" ?

Or does it just make it easier to summarily close them because they don't follow the official guidelines?

Yes, basically having this documented means that upstream filters (aka the apache security team) can point to these guidelines if they get reports that are bugs. At the moment in Arrow sometimes it is not clear which crash is a security issue and which is just a bug

I think we should define what exploitable means, as it is so important to this section.

Yes that is an excellent idea and I will do so

etseidl

Looks good to me, thanks for doing this @alamb.

etseidl · 2026-04-15T18:42:35Z

 [`simdutf8`]: https://crates.io/crates/simdutf8
 [parquet variant]: https://github.com/apache/parquet-format/blob/master/VariantEncoding.md

-## Parquet Feature Status


Why is this section removed?

🤦 -- not sure -- will revert

Co-authored-by: Ed Seidl <etseidl@users.noreply.github.com>

alamb · 2026-04-22T04:58:52Z

+//! malformed input is considered a **bug**, not a security vulnerability,
+//! unless it is **exploitable** by an attacker to
+//!
+//! * Execute arbitrary code (Remote Code Execution);


I added explicit definition of what exploitable means here. I did not include a "Denial Of Service" per the discussion with @tustvold on https://github.com/apache/arrow/pull/49761/changes#r3087975701

tustvold · 2026-04-22T10:07:18Z

+//! Like many crates, this crate makes use of `unsafe` where prudent. However, it endeavors to be
+//! sound. Specifically, **it should not be possible to trigger undefined behavior using safe APIs.**
+//!
+//! For more information on the use of unsafe, see [here](https://github.com/apache/arrow-rs/tree/main/arrow#safety).


Should a soundness issue be considered a security issue or not? I mainly ask as whilst we want to encourage reporting of soundness issues, they aren't in and of themselves exploitable.

I suggest we treat them as a security "issue" but not treated as a security vulnerability that requires special reporting / alerting unless there is some evidence it can actually be exploited

I tried to clarify this in the "security" part of arrow/README

Unexpected behavior (e.g., panics, crashes, or infinite loops) triggered by
malformed input, and instances of undefined behavior (UB) triggered via safe
APIs are considered bugs rather than security vulnerabilities unless they are exploitable
by an attacker to

I do agree this leaves some interpretation about what "exploitable by an attacker" really means but I think some level of interpretation is unavoidable for undefined behavior in principle (as it is undefined)

I will add a note to the safety section referring to the security section to make this explicit

I added more explanation to SECURITY.md and left links to there

alamb · 2026-04-22T13:19:06Z

+If that exploitation path is unclear, the issue should likely be reported as a
+bug.
+
+## Rust Safety, Soundness, and Undefined Behavior


I added this section to try and help define that not all soundness issues are vulnerabilities. I think it makes our current practice explicit.

wjones127

This is great. I have two non blocking comments.

wjones127 · 2026-04-23T06:46:45Z

+malformed input is generally considered a **bug**, not a security
+vulnerability, unless it is **exploitable** and could allow an attacker to
+
+* Execute arbitrary code (Remote Code Execution);


It might be nice to give an example of past bugs that indicate each, if there are any.

Thankfully (?) I am not aware of any such bugs in arrow-rs so I don't have any to list

I had codex find past examples, and the ones it found are as follows, which are mostly old undefined behavior issues

Out of bound reads in chunk iterator #198

Undefined behavior in FFI implementation #322

Soundness: Creating BinaryArray from ArrayData does not perform bound checks on reading values #772

Soundness: CreatingBinaryArray from ArrayData does not perform bound checks on reading offsets #773

Soundness: Creating GenericStringArray from ArrayData does not perform bound checks on reading offsets #776

Soundness: reading parquet with invalid utf8 results in UB #786

Validate arguments to ArrayData::try_new() #817

Tracking issue for safety issues #221

Upgrade regex dependency #1874

Implement full validation for UnionArrays construction from ArrayData #1486

Bitmap Length Validation is Incorrect #1231

Undefined behavior for GenericStringArray::from_iter_values if reported iterator upper bound is incorrect #1144

wjones127 · 2026-04-23T06:47:19Z

+- Reading data from untrusted sources (e.g., over a network or from a file) requires explicit validation.
+- Failure to validate untrusted data before use may lead to security issues.
+
+This implementation provides APIs such as [`ArrayData::validate_full`] to


Is a gap in these kinds of methods a security issue then?

Yes I think any gap in this validation would be a bug. If such a gap that allowed malformed data to be read without error and exposed RCE or information, I would think we should treat it like any other security vulnerability.

Following the same critera for security evaluation , it would only be a security vulnerability if it allows an attacker RCE / information disclosure

alamb · 2026-04-24T22:42:20Z

Ok, I think this is looking good enough to me, so merging it in and we can iterate on it going forward. Thank you all

Add SECURITY model for arrow-rs

d6f3a8f

github-actions Bot added parquet Changes to the parquet crate arrow Changes to the arrow crate arrow-flight Changes to the arrow-flight crate parquet-derive arrow-avro arrow-avro crate labels Apr 15, 2026

alamb changed the title ~~Alamb/security model~~ Document Security Policy Apr 15, 2026

alamb added the documentation Improvements or additions to documentation label Apr 15, 2026

prettier

8d0f20e

alamb marked this pull request as ready for review April 15, 2026 12:53

alamb mentioned this pull request Apr 15, 2026

GH-49760: Document differences between bugs and security vulnerabilities apache/arrow#49761

Closed

scovich reviewed Apr 15, 2026

View reviewed changes

tustvold reviewed Apr 15, 2026

View reviewed changes

Comment thread SECURITY.md Outdated

etseidl approved these changes Apr 15, 2026

View reviewed changes

alamb and others added 3 commits April 15, 2026 16:48

Apply suggestions from code review

6b59892

Co-authored-by: Ed Seidl <etseidl@users.noreply.github.com>

Merge remote-tracking branch 'apache/main' into alamb/security_model

fff1a96

revert inadvertent removal

de727be

etseidl mentioned this pull request Apr 20, 2026

Release arrow-rs / parquet Minor version 58.2.0 (April 2026) #9109

Closed

19 tasks

alamb added 5 commits April 22, 2026 00:26

Merge remote-tracking branch 'apache/main' into alamb/security_model

69b5e99

add definition of vulnerability

316697f

tweak

62d8e14

tweaks

2ab58f3

prettier

ed2c393

alamb commented Apr 22, 2026

View reviewed changes

tustvold reviewed Apr 22, 2026

View reviewed changes

rtyler approved these changes Apr 22, 2026

View reviewed changes

alamb added 2 commits April 22, 2026 08:47

Reiterate bugs vs vulnerabilities in crate docs

399898e

Merge remote-tracking branch 'apache/main' into alamb/security_model

d2274c0

alamb added 2 commits April 22, 2026 09:14

Clarify safe / unsafe

0e09ca6

tighten

1c9f736

alamb commented Apr 22, 2026

View reviewed changes

tustvold approved these changes Apr 22, 2026

View reviewed changes

wjones127 approved these changes Apr 23, 2026

View reviewed changes

alamb mentioned this pull request Apr 23, 2026

[Feature] Add a Security Policy (SECURITY.md) apache/datafusion#21811

Open

alamb merged commit 1a721a4 into apache:main Apr 24, 2026
28 checks passed

alamb mentioned this pull request Apr 28, 2026

Add a security policy for arrow-rs #9727

Closed

Conversation

alamb commented Apr 15, 2026

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

alamb commented Apr 15, 2026

Uh oh!

scovich left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alamb commented Apr 15, 2026

Uh oh!

etseidl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wjones127 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alamb Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alamb commented Apr 24, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

alamb Apr 23, 2026 •

edited

Loading