Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing Core Initiative Ranking #51

Open
8 tasks
devlinjunker opened this issue Oct 7, 2020 · 0 comments
Open
8 tasks

Passing Core Initiative Ranking #51

devlinjunker opened this issue Oct 7, 2020 · 0 comments
Labels
doc Help improve the Documentation

Comments

@devlinjunker
Copy link
Owner

devlinjunker commented Oct 7, 2020

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

@devlinjunker devlinjunker added the doc Help improve the Documentation label Oct 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Help improve the Documentation
Projects
None yet
Development

No branches or pull requests

1 participant