Skip to content

Passing Core Initiative Ranking #51

@devlinjunker

Description

@devlinjunker

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/

Related
#29
#13

Metadata

Metadata

Assignees

No one assigned

    Labels

    docHelp improve the Documentation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions