Task Force Recommendations

Gaps & Opportunities

1. Identify key contact points from each of the project.
   1. Make this as a mandatory criteria for graduating a project.
   2. They are responsible for either fixing or delegating the tasks.
   3. They are available to participate in Hyperledger wide security measure discussions.
2. Depend-a-bot alerts shall be addressed in a timely manner.
3. Revise standard security reporting template across projects, use the reference from OpenSSF.
4. Explore alternatives for using the mailing list to report security issues.
5. Differentiate bugs from a critical vulnerability.
   1. Proposed to have questions related to blockchain technology in CVE scoring. There is mixed opinion that it may not be sufficient and complete. Because they do not consider the threat modelling specific to each project.
6. Hyperledger has a cross project bug bounty incentive program.
   1. HackerOne is available for all projects.
   2. Propose a mechanism where the project team reviews the reported issue and staff has to approve for accepting a reported issue for bounty program.
7. Responsible vulnerability disclosure process does not exist. (Reference: https://github.com/ossf/wg-vulnerability-disclosures)
   1. Have project designated contact points as security mavens, helps in auditing.
   2. Audits serves as a way to prove that the project took right measures against a potential risk.
   3. CVEs will be published in open at the end of 90 days, unless requested for an extension explicitly.
8. Score cards for the security guarantees of projects.
   1. Reference from OpenSSF (https://github.com/ossf/scorecard)
   2. A self attested response form.
   3. Recommend the scorecard from OpenSSF, keep it open to receive comments/suggestions.
9. Security audits for the new projects: It requires an exception from TSC unless otherwise it is a graduated project.
   1. The process is also an expensive one, and may require governing board's approval in cases. ***
10. The LF does not involve in binary distribution. However, Hyperledger projects do have binary releases (jar, rust crates, npm packages etc.).
    1. Establish a standard process for artefacts signing and reproducible builds. Current mechanism involves specific members in Hyperledger staff to work with release engineers from each project.
    2. Assume that there is a CI pipeline and CD pipeline to do the releases. Make sure there is a process and tool support to push a new image with the necessary fixes.
    3. https://github.com/aquasecurity/trivy can scan container images.
    4. Use depend-a-bot alerts to see if any of the dependencies have CVEs.

Ideas

1. Alternatives to the Working Group:
   1. Use the available Zoom meeting rooms, any maintainer should be able to use one of these rooms and call for meetings.
   2. An option of informal working group to use community resources.
   3. Security Committee: Comprise of representatives from each of the graduated projects. Responsibilities include
      1. Show upto meetings
      2. Respond to security concerns and issues
      3. Refine the security process update
2. CVE scoring questions
   1. Categories 
      1. Blockchain Halt and/or Slowdown
      2. Data Integrity
      3. Chain Split
      4. Data Privacy Related.
   2. Possibilities
      1. Does it affect consensus? - most severe.
         1. Would it halt the blockchain from growing?
         2. Would it slow down the block creation?
         3. Chain split issues (objective parameter, exclude the ones that rely on long running chains, depends on the project's threat model)
      2. Does it break execution engine?
      3. Cryptography used in the project is broken.
      4. Is it a smart contract language specific issue? (is important because project supports the language which is used for development). 
         1. Use of randoms
   3. Points to note
      1. Ask the likeliness of the issue occurring in each category.
      2. Ask for ease of execution of the attach also the cost.
      3. Can the attacker's identity be revealed?
      4. Can the attack be identified?
      5. Certain categories carry more weightage on projects for which they claim security guarantees. For example, the data privacy.
      6. Introduce tagging system, tag the select list of categories in the reported issue.
3. Long term plan
   1. If the TAC/TOC is working towards forming sub-committees and giving the TSC responsibilities to individual projects, then a security process working committee, this will be one of the sub-committees. The members in this committee are per-project nominated representatives.
   2. Projects graduating from incubation require a sign-off from the security sub-committee.
   3. There is a need to call out guidelines for the sub-committee to sign-off/approve for graduation. The checklist can be items such as fixed all the errors, no active vulnerabilities, tool reports etc. The responsibility of creating the security report is on the person representing the project - others in the sub-committee do the review and sign-off.
4. Responsible vulnerability disclosure
   1. In addition the process to be followed, it will be good to have information of any CVEs that are fixed and announced, call it out in the quarterly reports.

Tasks

1. Identify CVE scoring guidelines for blockchain technology. ~ Action Peter Somogyvari
2. Come up with the policies for the responsible vulnerability disclosure/audit.
3. Define artefacts signing process and have a mechanism in place for reproducible builds.
4. Long term plan: propose a new WG for security process updates.
5. Checklist for security audit report for graduating a project.

Concrete Proposals

1. Every project to have a security representative. ~~ proposed and approved by the TSC.
2. For the purpose of this proposal, only the CVEs crossing certain (i.e. score >= 7) threshold are considered. Projects to address CVEs in 90 days of them reported.
   1. Goals:
      1. Avoid high profile/severity vulnerabilities that are trivial and easy to exploit.
   2. Proposal:
      1. Every project will be issued a badge for best practice in CVE addressing when they incubate. The CVE best practices badge is reviewed every quarter, TSC may make a decision to revoke the badge in case if the project is not complying to the requirements.
      2. A question will be introduced in the quarterly reports, that each project shall answer. The question would be to understand if there were high severity CVEs (i.e. score >= 7) is unaddressed beyond 90 days in the previous quarter. "Does your project have any CVEs with score 7 or more reported and unaddressed for 90 days or more in the previous quarter? If yes, please list the CVEs."
      3. The requirement is that a project does not have the high severity CVE (i.e. score >= 7) unaddressed for more than 90 days. If a project fails to do so, maintainers shall give a statement or the reason for such delay and get 30 days extension. There are can 2 such extensions in total. In total if high severity CVEs (with score >= 7) are still unaddressed at the end of 150 days, TSC can vote to revoke the CVE best practices badge.
      4. The revocation period of CVE best practices badge is 6 months. A project shall re-apply through the TSC voting and show that the best practices are followed for the last 6 months.