Page History

...

• Provide named security contacts per project (at least two contacts)

• Define security issue reporting process in SECURITY.md with reference to Hyperledger reporting process

• Review, respond, and act on reported security vulnerabilities

• Follow security issue disclosure process - see Disclosure task force

• Leverage automated scans, tooling depends on language but usually includes some combination of:

  • linters

  • Software Composition Analysis dependency scans, e.g. Dependabot, Govulncheck 

  • Static Application Security Testing (SAST) aka static analysis scans, e.g. CodeQL, Snyk
    

• Pin dependencies and keep dependencies up to date,  e.g. using Dependabot, although be wary of auto-upgrades and look for malware.

• Engage with Hyperledger staff on possibility of security audits for Graduated project major releases, address audit results and socialize

• Review OpenSSF secure developer guide and OpenSSF overview presentation to TOC (charts, replay)

• Review and obtain OpenSSF Best Practices Badge - criteria

• Sign release artifacts (TBD) - see proposed Security Artifact Signing task force

Documentation - see also Documentation task force and Onboarding task force

• Documentation should minimally target these audiences

  • User guide including Getting Started / Tutorial

  • Project developer guide including coding guidelines, build instructions, test instructions

  • Application developer guide

• Documentation task force will address Common styling guide, Recommended documentation platform?common publishing platform, Document best practices for creating documentation, etc.

Project management

• Maintain a written project roadmap
• Create, clarify, and label issues in Github for contributors, e.g. use label "good first issue" 
• Review, triage, comment on, and close inbound Github issues

Releases

• Follow an established Release taxonomy - either SemVer or CalVer

• Document release strategy, release process, branch strategy (e.g. one branch per major.minor release works well so that it can be maintained in isolation with while delivering major.minor.patch releases)

• Document Long-term support (LTS) release strategy - example https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md

• Use Github actions Actions to automate release process, e.g. publish artifacts and release notes upon drafting a GitHub release

• Release artifacts -

  • binaries attached to GitHub release

  ,

  • docker images

  in

  • - transition from Dockerhub to GitHub Packages? Will there be size limitations on GitHub Packages

  versus Dockerhub

  • ?

Continuous Integration (CI)

• GitHub Actions is the recommended CI platform, although we need to address the limits on number of runners, some ideas:

  • BuildJet
  • Use cancel-in-progress to suppress multiple jobs for multiple pushes to the same pull request
  • Uncheck branch protection rule "Require branches to be up to date before merging" to reduce number of runs (potentially add a scheduled run if you are concerned about incompatible PRs getting merged)
  • Use filters to eliminate unnecessary runs

• Pull request checks

  • DCO - Developer Certificate of Origin

  • Unit tests

  • Integration tests

  • Scans - see Security section, more comprehensive scans can be run nightly insteadconsider running on schedule (e.g. nightly) rather than on each pull request

• Test coverage reporting - run on-demand or nightly

• Keep CI clean and green at all times, address failures and flakes

• See proposed Automated Pipelines task force

...