Create a Threat Model and Security Policy for CPython

Describe the enhancement or feature you would like

The Python Security Response Team is receiving higher volumes of reports, many of which are invalid or intensive to triage. We believe many of these reports use LLMs or security researchers not familiar with a programming language threat model, so more context would help in having fewer low-quality reports.

• Create a new top-level "Security Policy and Threat Model" section to Devguide.
• Security Policy
  • Document the expectations of security researchers submitting reports to the PSRT. Basic information, what to include (simple POC, optional fix).
  • Ask reporters to disclose what LLM model used, if any, to find the vulnerability. This informs us about how "public" this vulnerability may already be or whether a vulnerability is likely to be reported as a duplicate.
  • Explicitly note that security reports, even when private, the PSF Code of Conduct still applies for all communications and that this will be prioritized over technical merit of a vulnerability report.
  • Document a policy for using LLMs, such as requiring that prior to reporting all potential findings must be cross-checked against the threat model.
  • Failure to follow the security policy may result in reports not being accepted, regardless of technical merit.
  • Duplicate a general version of the security policy in SECURITY.md and python.org/dev/security.
• Threat Model
  • Document an overall threat model with high-level details about the Python interpreter (envvars, options, trusted code), the Python language features (eval), C API, threading. This threat model will be duplicated in the main CPython repository (.github/THREAT_MODEL.md?) This file will also link out to the "Threat Model" devguide section.
  • For each standard library module of security-relevance, document an individual threat model where appropriate. Many standard library modules that are not intended for "production usage" will not accept security reports.
  • Update warning admonitions in the docs for each standard library module to link to their threat model page.
  • In the "Security Considerations" page for the Python standard library, move this content to the threat model and update links. This page feels like it wants to be both a threat model AND a "secure deployment" page. Maybe a future addition to the Python documentation.

Describe alternatives you have considered

No response

Additional context

Prior art:

• Django security policy: https://docs.djangoproject.com/en/dev/internals/security/
• curl security policy: https://github.com/curl/curl/blob/master/docs/VULN-DISCLOSURE-POLICY.md

Start by reviewing the Devguide structure, the existing Security Considerations page, SECURITY.md, and the linked Django and curl policies. Define the new Security Policy and Threat Model sections, then map the listed interpreter, language, C API, threading, and standard-library topics to documentation updates. Done means the policy, threat-model links, repository copy, and relevant warning links are documented as scoped.