DOCUMENT: 2022 Internal Standards, Policies & Templates Updates

[ChristopherA]

We need to update our internal community standards, repo policies, and related templates for 2022. Especially given new Internship projects.

This includes:

• When you want to move a project to BC

  • When? Why? (Why Not?)
  • CLA Requirements
  • README.md Standardization

• Standardize repo issue tag name, descripts, and colors (update all and put in security-template).

• More detail on versioning, releases, git branch strategies:

  • Examples:
  • https://github.com/bitcoindevkit/bdk/blob/master/DEVELOPMENT_CYCLE.md

• Adapt CII Best Practices for our needs, identify key ones to try to document and achieve, and begin practice.

  • Do we want to strive to badge? https://github.com/rsp/cii-best-practices-badge

Some of these might make good intern projects.

[ChristopherA]

Some random links related to software and code security best practices:

Security Software & Code Best Practices

• cii-best-practices-badge/criteria.md at master · rsp/cii-best-practices-badge
• rsp/cii-best-practices-badge: Core Infrastructure Initiative Best Practices Badge
• BadgeApp
• 42/C4 | ZeroMQ RFC
• 10 GitHub Security Best Practices | Snyk
• Security Best Practices for Github - Cycode
• 13 tools for checking the security risk of open-source dependencies
• 10 Java security best practices - DEV
• Auditing package dependencies for security vulnerabilities | npm Docs
• goldbergyoni/nodebestpractices: The Node.js best practices list (December 2020)
• Security Best Practices for C++ | Microsoft Docs
• CERT C++ Secure Coding Guidelines
• C++ FAQ
• Amazon.com: Secure Programming Cookbook for C and C++: Recipes for Cryptography, Authentication, Input Validation & More (9780596003944): John Viega, Matt Messier: Books
• Rules for secure coding in the C++ programming language - Help Net Security
• JSFAV coding standards - Google Search
• JSF Coding Standard for C++ (JSF++) | Perforce
• https://www.stroustrup.com/JSF-AV-rules.pdf
• JSF AV C++ Coding Rules - MATLAB & Simulink
• Use of the LDRA tool suite within the Aerospace and Defence sector
• Introduction to Secure Coding in C and C++ | by Alex Mosso | Level Up Coding
• OWASP Top Ten Web Application Security Risks | OWASP
• Security Code Review 101 — Input Validation | by Paul Ionescu | Medium
• CWE - 2020 CWE Top 25 Most Dangerous Software Weaknesses
• Security Code Review 101 — Parameterized Statements | by Paul Ionescu | Medium
• Security Code Review 101 — Memory | by Paul Ionescu | Medium
• Security Code Review 101 — Protecting Data (Part 1) | by Paul Ionescu | Medium
• Security Code Review 101 — Protecting Personal Data | by Paul Ionescu | Medium
• Security Code Review 101 — Protecting Against Cross-Site Scripting | by Paul Ionescu | Medium
• Security Code Review 101 — Indirect Object Reference | by Paul Ionescu | Medium

[ChristopherA]

Another possible item — add an emerging standard for security.txt files at root of repos. See https://github.com/securitytxt/security-txt that is drafting https://tools.ietf.org/html/draft-foudil-securitytxt-10

[ChristopherA]

https://owasp.org/www-project-mobile-security-testing-guide/

[ChristopherA]

Broke out the labels part of this project in #39

[ChristopherA]

@gorazdko What is complete or needs more work with this project? Should we break it out into more issues and close this one? Are there some that sub-projects that interns could tackle this summer?

[ChristopherA]

https://medium.com/the-andela-way/how-to-build-a-power-up-for-your-github-project-board-for-project-management-344d5b380a68

[shannona]

Made some minor changes, including:

• Moving installation & usage to the top, per GST
• Linking in standards for Release Path
• Changing default release level from Late Alpha to Alpha
• Standardizing Issues tags, largely per GST, but with new color coordination to show many like topics.

Current Issues tags are:

• bug [red] — Something isn't working
• crash [red] — The program crashes
• documentation [varied colors] — Improvements or additions to documentation
• duplicate [green] — This issue or pull request already exists

• enhancement [varied colors] — New feature or request

  • invalid [green] — This doesn't seem right
  • next release [yellow] — Will be in next release
  • not a bug [green] — Behavior is normal and expected
  • question [varied colors] — Further information is requested
  • retest [off yellow] — Probably fixed in new release
  • stretch-goal [yellow] — Do last for this release, only if easy, otherwise move to backlog
  • upstream bug [red] — Bug in dependency (workaround?)
  • ux [varied colors] — User experience or interface
  • won't fix [green] — This will not be worked on

  See https://github.com/BlockchainCommons/secure-template/labels

If we want any other changes to the template, or any changes to colors, grouping, or labels (including additions or subtractions), just let me know. If we're happy with these, I'll move them to the GST and Gordian Server repos, as the ones most likely to need active use of Issues labels at the moment.

[ChristopherA]

There are some concepts of tagging the lifecycle of releases in https://github.com/unprotocols/rfc that we should talk about, in particular the lifecycles page: https://github.com/unprotocols/rfc/blob/master/2/README.md which has raw vs draft (I agree there is a distinction), retired vs deprecated (bech32 is current retired, but it works, but gordian wallet is deprecated), and delete (I don't think we should delete much, but we should archive more.)

[ChristopherA]

Though this is likely too detailed, we should have something that serves the same purpose for out, detailing our own development practices. Then we should talk about our recommendations of secure development practices for others in #130 (which may be less than ours for smaller teams, or more than ours for bigger teams).