A long time ago, in a standards body far, far away, I was involved in drafting a document about trust and security. That document rejoices in the name ETSI GS NFV-SEC 003: Network Functions Virtualisation (NFV);NFV Security; Security and Trust Guidance[1], and section 5.1.6.3[2] talks about “Transitive trust”. Convoluted and lengthy as the document is, I’m very proud of it[3], and I think it tackles a number of very important issues including (unsurprisingly, given the title), a number of issues around trust. It defines transitive trust thus:
“Transitive trust is the decision by an entity A to trust entity B because entity C trusts it.”
It goes on to disambiguate transitive trust from delegated trust, where C knows about the trust relationship.
At no point in the document does it mention open source software. To be fair, we were trying to be even-handed and show no favour towards any type of software or vendors – many of the companies represented on the standards body were focused on proprietary software – and I wasn’t even working for Red Hat at the time.
My move to Red Hat, and, as it happens, generally away from the world of standards, has led me to think more about open source. It’s also led me to think more about trust, and how people decide whether or not to use open source software in their businesses, organisations and enterprises. I’ve written, in particular, about how, although open source software is not ipso facto more secure than proprietary software, the chances of it being more secure, or made more secure, are higher (in Disbelieving the many eyes hypothesis).
What has this to do with trust, specifically transitive trust? Well, I’ve been doing more thinking about how open source and trust are linked together, and distributed trust is a big part of it. Distributed trust and blockchain are often talked about in the same breath, and I’m glad, because I think that all too often we fall into the trap of ignoring the fact that there definitely trust relationships associated with blockchain – they are just often implicit, rather than well-defined.
What I’m interested in here, though, is the distributed, transitive trust as a way of choosing whether or not to use open source software. This is, I think, true not only when talking about non-functional properties such as the security of open source but also when talking about the software itself. What are we doing when we say “I trust open source software”? We are making a determination that enough of the people who have written and tested it have similar requirements to mine, and that their expertise, combined, is such that the risk to my using the software is acceptable.
There’s actually a lot going on here, some of which is very interesting:
- we are trusting architects and designers to design software to meet our use cases and requirements;
- we are trusting developers to implement code well, to those designs;
- we are trusting developers to review each others’ code;
- we are trusting documentation folks to document the software correctly;
- we are trusting testers to write, run and check tests which are appropriate to my use cases;
- we are trusting those who deploy the code to run in it ways which are similar to my use cases;
- we are trusting those who deploy the code to report bugs;
- we are trusting those who receive bug reports to fix them as expected.
There’s more, of course, but that’s definitely enough to get us going. Of course, when we choose to use proprietary software, we’re trusting people to do that, but in this case, the trust relationship is much clearer, and much tighter: if I don’t get what I expect, I can choose another vendor, or work with the original vendor to get what I want.
In the case of open source software, it’s all more nebulous: I may be able to identify at least some of the entities involved (designers, software engineers and testers, for example), but the amount of power that I as a consumer of the software have over their work is likely to be low. There’s a weird almost-paradox here, though: you can argue that for proprietary software vendors, my power over the direction of the software is higher (I’m paying them or not paying them), but my direct visibility into what actually goes on, and my ability to ensure that I get what I want is reduced when compared to the open source case.
That’s because, for open source, I can be any of the entities outlined above. I – or those in my organisation – can be architect, designer, document writer, tester, and certainly deployer and bug reporter. When you realise that your impact on open source can be equal to that of others, the distributed trust becomes less transitive. You understand that you have equal say in the creation, maintenance, requirements and quality of the software which you are running to all the other entities, and then you become part of a network of trust relationships which are distributed, but at less of a remove to that which you’ll experience when buying proprietary software.
Why, then, would anybody buy or license open source software from a vendor? Because that way, you can address other risks – around support, patching, training, etc. – whilst still enjoying the benefits of the distributed trust network that I’ve outlined above. There’s a place for those who consume directly from the source, but it doesn’t mean the risk appetite of all software consumers – including those who are involved in the open source community themselves.
Trust is a complex issue, and the ways in which we trust other things and other people is complex, too (you’ll find a bit of an introduction in Of different types of trust), but I think it’s desperately important that we examine and try to understand the sorts of decisions we make, and why we make them, in order to allow us to make informed choices around risk.
1 – if you’ve not been involved in standards creation, this may fill you with horror, but if you have so involved, this sort of title probably feels normal. You may need help.
2 – see 1.
3 – I was one of two “rapporteurs”, or editors of the document, and wrote a significant part of it, particularly the sections around trust.
Alice, Eve and Bob - a security blog 
9 thoughts on “Trust & choosing open source”