Three Open Source hackers were invited to this meeting with the CSRB and I was one of them.
The board with this name is part of CISA, a US government effort that received a presidential order to work on “Improving the Nation’s Cybersecurity“. Where “the Nation” here is the US.
I’m not in the US and I’m not a US citizen but I felt I should help out when asked and I was able to.
On April 21 2022, I joined the video meeting together with an OpenSSL and a Tomcat contributor and several members of the board. (I am not naming any names of participants in this post because I have not asked for permission nor do I think the names are important here.)
For about an hour we talked to the board how we develop Open Source, how we take on security problems and how we work on making sure we do things as securely as we can. It was striking how similarly the three of us looked at the issues and how we work in our project, despite our projects all being different and having our own specifics.
As projects, we believe we have pretty well-established and working procedures for getting problems reported and we think we fix the issues fairly swiftly. We ship fixes, advisories and updates not long after the issues get known. The CVE system where we register and publish security vulnerabilities in a global registry is working adequately. (I’m not saying things are perfect.)
The main problem
It was pretty clear to me that we agreed that the biggest problem in the Open Source supply chain today is the slow uptake in patching vulnerable software.
Lots of vendors and products have not been made or have any plans for how to handle upgrades when vulnerabilities are found. Many of those that do act, do that with such glacier like speeds that users of such products remain exposed for attackers for a long period after the flaws are already fixed and have become known.
My own analysis of this is that such vendors of course do this because its the cheapest way. Plain capitalistic reasons.
Addressing this is hard
If we had any easy fixes for this, we would already have them in progress. We were also asked by the board what kind of systems that we would not like to see.
Will Software Bill Of Materials (SBOM) fix this? Maybe it can help, by exposing to the world what software and versions are used in products, but it will certainly depend on how it is used and enforced. If done too heavy-handed, it risks causing overhead and added complications but in the other end it might end up too wishy-washy.
Ended there
This was just an hour of conversation with a few follow-up clarifying emails. I hope that we were able to provide insights into how Open Source is made but I have no illusions of us changing anything in drastic ways.
I felt honored to represent “my kind” and help sharing knowledge of Open Source to areas of the world that might not always get informed about it.
It is always a bit of a struggle convince people in non-technical decision-making positions of the necessity of updating things. I think there are a few aspects to this where things could be improved.
On the one hand it would be great if we could make it easier to assemble support lifecycle information of the software we use more easily, especially directly from the upstream sources. A lot of them just have human-readable tables on their websites that are hard to scrape reliably as the site changes.
I imagine some sort of simple machine-readable file format that lists what I am calling “support versions” in my head (not sure if there is a more established term), basically the prefix of the version number that someone promises to support for a specified amount of time, e.g. Apache 2.4 or MariaDB 10.6 or TYPO3 9.5,.. along with the phases of support (full support, security support only,…) and dates or conditions (like next stable release + 1 year) for their start and end. Ideally this would also support encoding a third-party promising to support someone’s software as well as conditions on who gets the support (everyone, just paying customers, just customers paying for extra long-term support,…).
The other issue we need to address is probably education material for decision-makers, both in organizations and in politics, on how the software lifecycle works, who puts in the effort, why it is not realistic that your local hoster takes over support once upstream and distros do not support software any longer, how security issues and critical bugs are tracked and what risks leaving them unpatched poses from both untargeted and targeted attacks and how attacks basically start seconds after you connect a system to the open internet,… This material will also have to be in the local language as many decision-makers are not as immersed in the English international part of the internet as much as technical people are.