Create a Threat Model and Security Policy for CPython

Beginnen Sie mit der Durchsicht der Struktur des Devguide, der bestehenden Seite „Security Considerations“, von SECURITY.md und der verlinkten Django- und curl-Richtlinien. Definieren Sie die neuen Abschnitte „Security Policy“ und „Threat Model“ und ordnen Sie anschließend die aufgeführten Themen zu Interpreter, Sprache, C API, Threading und Standardbibliothek den Aktualisierungen der Dokumentation zu. Als abgeschlossen gilt die Aufgabe, wenn die Richtlinie, die Links zum Threat Model, die Kopie im Repository und die relevanten Warnungslinks als abgegrenzt dokumentiert sind.

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