-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Labels
docHelp improve the DocumentationHelp improve the Documentation
Description
Describe the change:
There are a couple of sections in the Core Initiative checklist that seem valuable to include in documentation
- Semantic versioning (Semantic Versioning #13)
- Release Notes
- Vulnerability report response (14 days - last 6 months)
- Tests coverage percentage (80% branches? 90% lines)
- Tests for all feature policy (add formally)
- Warning flags (< 1/100 lines of code)
- Security Notes to SECURITY.md:
- 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)).
- Dynamic code analysis
Additional context/Links:
https://bestpractices.coreinfrastructure.org/en/projects/4288/
Metadata
Metadata
Assignees
Labels
docHelp improve the DocumentationHelp improve the Documentation