_SECURITY_README

Security Policy

Supported Versions

✅ Currently Supported
➖ Still Supported with Planned Deprecation
❌ Not Supported

Version	Supported
> 1.0.x	✅
0.12.x	➖
0.11.x	➖
< 0.10	❌

Reporting a Vulnerability

Please submit a "[SECURITY] Bug Report" that details the security concern (and ideally steps to take to fix or mitigate risk). If an issue is not responded to within 1 month, please assume that this repo is stale and will not be updated.

If a suggested fix is accepted and applied, your name will be added to the contributors list in the README. If the suggested fix is declined, we will attempt to provide an explanation on the Github issue created before closing the issue. You may or may not get notified of this via email depending on your notification preferences.

Security Design Principles (from Common Core Initiative)

See Also: Protection of Infomation in Computer Systems

• Economy of mechanism
  keep the design as simple and small as practical, e.g., by adopting sweeping simplifications

• Fail-safe defaults
  access decisions should deny by default, and projects' installation should be secure by default

• Complete mediation
  every access that might be limited must be checked for authority and be non-bypassable

• Open design
  security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords

• Separation of privilege
  ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication

• Least privilege
  processes should operate with the least privilege necessary

• Least common mechanism
  the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files

• Psychological acceptability
  the human interface must be designed for ease of use - designing for "least astonishment" can help

• Limited attack surface
  the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited

• Input validation with allowlists
  inputs should typically be checked to determine if they are valid before they are accepted; this validation should use allowlists (which only accept known-good values), not denylists (which attempt to list known-bad values))