Security Policy
Relevant source files
The following files were used as context for generating this wiki page:
The Security Policy defines the protocols for maintaining bot integrity, handling vulnerabilities, and managing access control. It ensures that the Red Discord Bot environment remains secure for both instance owners and end users through version maintenance and structured reporting.
Supported Versions
The project only provides security updates for active versions. Versions lower than 3.5 are considered End of Life (EOL) and do not receive patches.
| Version | Branch | Security Updates | End of Life |
|---|---|---|---|
| < 2.0 | master | :x: | :white_check_mark: |
| >= 2.0, < 3.0 | develop | :x: | :white_check_mark: |
| >= 3.0, < 3.5 | V3/develop | :x: | :white_check_mark: |
| >= 3.5 | V3/develop | :white_check_mark: | :x: |
Sources: SECURITY.md:5-15
Reporting Vulnerabilities
Maintainers use GitHub's private vulnerability reporting feature to manage security risks. This system limits access to reports to maintainers and key members only.
Submission Process
To report a security issue, you must:
- Navigate to the project security advisory page.
- Complete the reporting form with a summary and technical details.
- Provide a proof of concept to demonstrate the vulnerability.
- Optionally include affected components and perceived severity.
Response Timeline
Maintainers aim to respond to security reports within 7 days. If you receive no response, you should contact members with the "Staff" role on the official Discord server.
Sources: SECURITY.md:20-41
Access Control and Permissions
The bot utilizes a multi-layered permission system to regulate command execution. This system prioritizes global rules over server-specific rules.
Permission Evaluation Order
The bot evaluates permissions in the following hierarchy:
- User-specific rules.
- Voice/Stage channel rules where the user is connected.
- Channel or thread parent rules for the invocation location.
- Role-based rules, utilizing the highest role with an assigned rule.
- Server-wide rules (applicable to global rules only).
Sources: redbot/cogs/permissions/permissions.py:165-175
User Allowlists and Blocklists
Instance owners can restrict bot interactions using the allowlist and blocklist systems.
This diagram illustrates the sequence of identity-based checks performed before a command reaches the functional logic.
Sources: redbot/core/core_commands.py:1601-1850, redbot/core/_diagnoser.py:270-340
Data Privacy and Security
The bot provides tools for managing End User Data (EUD) and complying with data deletion requests.
Data Deletion Requests
The mydata command group allows users and owners to manage stored information. The bot supports different requester types for data removal:
- discord_deleted_user: Triggered when Discord notifies the bot of a deleted account; removes all identifying data.
- user_strict: Triggered by user request; removes all non-operational data including nicknames.
- owner: Triggered by the instance owner to purge user records.
Sources: redbot/core/core_commands.py:530-750, redbot/cogs/permissions/permissions.py:100-140
Internal Security Diagnostics
The diagnoseissues command allows owners to audit why a specific user is failing permission checks. This tool inspects global "call once" checks, disabled command states, and Permissions cog rules.
The diagnoser sequence helps administrators identify if a security restriction is coming from core bot settings or external plugins.
Sources: redbot/core/_diagnoser.py:25-80, redbot/core/core_commands.py:1550-1600
Development Security Standards
Contributors must adhere to specific coding standards to prevent security regressions:
- All new features or bug fixes must include corresponding tests.
- Pull requests undergo core team review and are subject to a veto period by the project owner.
- Documentation builds and style checks (via
tox) are mandatory before merging.
Sources: CONTRIBUTING.md:40-60, CONTRIBUTING.md:200-240
The project maintains security through a combination of strict version support, private vulnerability management, and a robust, tiered permission architecture. Instance owners are responsible for maintaining their local configurations to ensure their specific bot instances remain secure.