Update security model

### What changes were proposed in this pull request?
This PR adds a new "Threat Model" section to the project's Security documentation (`site/security/index.md`).
The new section outlines:
1. The trusted vs. untrusted data boundaries for the `orc` library.
2. The distinction between robustness issues (e.g., crashes or Out-Of-Bounds reads caused by maliciously fuzzed files) and actual security vulnerabilities.
3. The responsibilities of the low-level parsing library versus the data ingestion layer.

### Why are the changes needed?
This update is needed to align Apache ORC's security threat model with other foundational data format libraries like Apache Arrow.

The community occasionally receives reports from fuzzing tools regarding crashes, OOMs, or memory issues caused by parsing maliciously corrupted files. This documentation clarifies our stance: because `orc` is a low-level format library designed for trusted environments, parsing malformed files that cause a crash (without leading to Remote Code Execution or bypassing a defined security boundary) is considered a normal software bug (a robustness issue) rather than a security vulnerability (CVE).

This will help avoid overwhelming maintainers with non-exploitable CVEs and set clear expectations for security researchers.

### How was this patch tested?
This is a documentation-only change updating the website Markdown. No functional code changes were introduced.

### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Gemini 3.1 Pro

This patch had conflicts when merged, resolved by
Committer: Gang Wu <ustcwg@gmail.com>

Closes #2632 from wgtmac/security_model.

Authored-by: Gang Wu <ustcwg@gmail.com>
Signed-off-by: Gang Wu <ustcwg@gmail.com>

Author: wgtmac

site/security/index.md

@@ -7,6 +7,33 @@ Apache ORC is a library rather than an execution framework and thus
 is less likely to have security vulnerabilities. However, if you have
 discovered one, please follow the process below.
 
+## Threat Model
+
+We align our threat model with other foundational data format libraries like [Apache Arrow](https://arrow.apache.org/docs/dev/format/Security.html). When evaluating potential security vulnerabilities, especially those discovered via fuzzing tools, we apply the following principles to distinguish between normal robustness bugs and actual security vulnerabilities.
+
+### 1. Trusted vs. Untrusted Data Boundaries
+
+Apache ORC is a low-level format library designed to read and write data from trusted storage systems (e.g., internal data lakes, HDFS, S3). The parsing APIs assume that the underlying data originates from a trusted internal source.
+
+If an attacker is able to write arbitrary, maliciously crafted ORC files into your internal storage, the system is already compromised at the infrastructure or access control level (e.g., IAM permissions, API gateways). The `orc` library itself is not the appropriate security boundary to defend against compromised storage infrastructure.
+
+### 2. Robustness Issues vs. Security Vulnerabilities
+
+A crash, Out-Of-Memory (OOM), Out-Of-Bounds (OOB) read, or assertion failure caused by feeding a maliciously fuzzed file directly into the low-level parser is considered a **robustness issue** (a regular software bug), not a security vulnerability.
+
+Such issues are only treated as security vulnerabilities (CVEs) if they:
+* Lead to Remote Code Execution (RCE).
+* Bypass a defined security boundary or cause cross-tenant data leakage.
+* Occur in a server component explicitly designed to process unverified, external data.
+
+Missing bounds checks or crashes during the parsing of malformed files do not typically lead to code execution or break isolation sandboxes. They are treated as regular software defects.
+
+### 3. Responsibilities of the Low-Level Library
+
+The primary goal of a low-level serialization/deserialization library like ORC is high performance. Mandating strict defensive programming and validation on every internal memory operation would severely degrade performance.
+
+Security validation and sanitization of untrusted inputs should occur at the data ingestion layer (e.g., before data is admitted into the data lake). It is outside the scope of the format parser to proactively defend against all possible artificially corrupted bits.
+
 ## Reporting a Vulnerability
 
 We strongly encourage folks to report security vulnerabilities to our