Gaps & Opportunities
- Identify key contact points from each of the project.
- Make this as a mandatory criteria for graduating a project.
- They are responsible for either fixing or delegating the tasks.
- They are available to participate in Hyperledger wide security measure discussions.
- Depend-a-bot alerts shall be addressed in a timely manner.
- Revise standard security reporting template across projects, use the reference from OpenSSF.
- Explore alternatives for using the mailing list to report security issues.
- Differentiate bugs from a critical vulnerability.
- 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.
- Hyperledger has a cross project bug bounty incentive program.
- HackerOne is available for all projects.
- Propose a mechanism where the project team reviews the reported issue and staff has to approve for accepting a reported issue for bounty program.
- Responsible vulnerability disclosure process does not exist. (Reference: https://github.com/ossf/wg-vulnerability-disclosures)
- Have project designated contact points as security mavens, helps in auditing.
- Audits serves as a way to prove that the project took right measures against a potential risk.
- CVEs will be published in open at the end of 90 days, unless requested for an extension explicitly.
- Score cards for the security guarantees of projects.
- Reference from OpenSSF (https://github.com/ossf/scorecard)
- A self attested response form.
- Recommend the scorecard from OpenSSF, keep it open to receive comments/suggestions.
- Security audits for the new projects: It requires an exception from TSC unless otherwise it is a graduated project.
- The process is also an expensive one, and may require governing board's approval in cases. ***
- The LF does not involve in binary distribution. However, Hyperledger projects do have binary releases (jar, rust crates, npm packages etc.).
- 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.
- 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.
- https://github.com/aquasecurity/trivy can scan container images.
- Use depend-a-bot alerts to see if any of the dependencies have CVEs.
- Alternatives to the Working Group:
- Use the available Zoom meeting rooms, any maintainer should be able to use one of these rooms and call for meetings.
- An option of informal working group to use community resources.
- Security Committee: Comprise of representatives from each of the graduated projects. Responsibilities include
- Show upto meetings
- Respond to security concerns and issues
- Refine the security process update
- CVE scoring questions
- Blockchain Halt and/or Slowdown
- Data Integrity
- Chain Split
- Data Privacy Related.
- Does it affect consensus? - most severe.
- Would it halt the blockchain from growing?
- Would it slow down the block creation?
- Chain split issues (objective parameter, exclude the ones that rely on long running chains, depends on the project's threat model)
- Does it break execution engine?
- Cryptography used in the project is broken.
- Is it a smart contract language specific issue? (is important because project supports the language which is used for development).
- Use of randoms
- Does it affect consensus? - most severe.
- Points to note
- Ask the likeliness of the issue occurring in each category.
- Ask for ease of execution of the attach also the cost.
- Can the attacker's identity be revealed?
- Can the attack be identified?
- Certain categories carry more weightage on projects for which they claim security guarantees. For example, the data privacy.
- Introduce tagging system, tag the select list of categories in the reported issue.
- Long term plan
- 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.
- Projects graduating from incubation require a sign-off from the security sub-committee.
- 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.
- Responsible vulnerability disclosure
- 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.
- Identify CVE scoring guidelines for blockchain technology. ~ Action Peter Somogyvari
- Come up with the policies for the responsible vulnerability disclosure/audit.
- Define artefacts signing process and have a mechanism in place for reproducible builds.
- Long term plan: propose a new WG for security process updates.
- Checklist for security audit report for graduating a project.
- Every project to have a security representative. ~~ proposed and approved by the TSC.
- For the purpose of this proposal.
- Encourage to fix high profile/severity vulnerabilities that are trivial and easy to exploit on time.
- Put a policy around responsible disclosure of CVEs under Hyperledger Foundation.
- Whoever found the bug will end up disclosing as per the SLA, disclosure policy. The disclosure policy shall request for creator of the issue to give 90 days for the project team to fix them.
- Policy statement:
- Hyperledger Foundation welcomes all to use the forum available to disclose vulnerabilities. - reference from OpenSSF. - Action item Arun S M
- 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.
- 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."
- Reconsider: 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. This is difficult for projects like Aries.
- Collect the data instead of showcasing the badges, this will allow for better visualization of how good a project is from the security standpoint.
- Mandatory release policy post minimum number of days.
- 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.
We did have a past decision that anything that would be creating output should be a task force and not a working group. If this group is not intended for informational sharing but to generate output, then it should be a task force.
Arun S M
Thanks Tracy, yes, this was brought up in the TSC meeting today. However, I see a need for security mavens from each project to get together at least once a month. This quorum can be a working group bringing in questions, concerns, suggestions and updates on security process regularly. It is towards having a proactive approach to potential security process updates. If creating a new working group is not possible, can we think of another framework to facilitate these meetings?
Can someone create a PR to the incubation exit checklist for this? Maybe add a Security sub-section under "Minimum requirements"
Arun S M
Maybe this should also be a criteria under the above Security sub-section.
This would be a change. In the past, whenever a 1.0 release was made, a security audit was conducted. I think it is fine given we no longer have the "major release". If this is recommended, do we have any additional faults beyond "it is expensive" as to why this recommendation makes sense?
Arun S M
There were questions such as how often these be done, specially that each project have their own release tagging process. I have one more suggestion, it would make sense to have the security maven from the project team itself to be proactive from this point on at least. Hyperledger Foundation is doing so much to get the project of a high quality, it shall be maintained that way by the project team.
In general, it seems like maybe the tasks do not match with all of the items that are being recommended. Is there a reason for this?
Arun S M
No, the tasks should really cover all the opens from the recommendations. It so happened that the list was created live in a task force meeting. It will further be extended with action items on individuals in the next meeting on 20th May 2022.
I am not sure I understand why a project that has never had a CVE would receive a CVE best practices badge. I also do not understand the re-application aspect. Wouldn't you only be able to re-apply when another CVE is found and handled within the 90 day period? Also, where will badges be issued/revoked/displayed? Are these GitHub badges? Or some sort of badging tool that we will create?