Investigate the security requirements of using caliper

[davidkel]

Caliper is not just a tool that runs locally on a single machine making calls to blockchains. It can act as a server (using express) to interact with prometheus as well as interact with an mqtt broker to co-ordinate with remote workers and as such remote workers and the caliper manager will be performing bi-directional network communications with the broker.

Given the new world of regulation from both the EU and the US around opensource software for which the hyperledger foundation may place requirements on projects, we should consider the security requirements of caliper.

Some thoughts:

• We cannot do without the remote worker ability due to the nature of caliper, but could we remove the need for the caliper manager to act as a server for prometheus but still retain the prometheus capability ?
• Is there an attack vector via mqtt ?
• Ensure we are at the latest levels of dependencies
• The Caliper code base should perform regular security scans
• Caliper should be in a position to provide continual updates to address any potential security vulnerabilities.

How much this actually has to be done for Caliper is unknown given it is not officially maintained by any software manufacturer (any software manufacturer taking caliper and incorporating it into a product will definitely have obligations to ensure it is secure but I am not aware of this actually being done) and it is not a graduated project. If it is still a concern and given the lack of any committed investment in caliper then maybe moving Caliper to hyperledger-labs is an option to remove the requirement. The final alternative would be to consider moving caliper to Dorment status followed by end of life and leave it as an As-is tool for use at your own risk.

[davidkel]

Some thoughts on this around npm dependencies

1. We should reduce the number of dependencies as best we can to try to reduce the possible attack vector. We should consider removing or changing dependencies that have only a single owner/maintainer or are not managed under a consortium as this increases the risk of unfixed security issues. If this is not possible then we need to make sure that the npm module used is also used by a vast number of uses which would hope to keep the project alive and healthy.
2. We need to make sure we are at the latest dependencies and that npm install reports as few security issues as possible