Open source software represents a significant proportion of the internet’s infrastructure including server software, data delivery, and specific code libraries. For example:
- 64.4% of web servers run open source software as their essential server infrastructure, running either Nginx or Apache server software
- 43.1% of websites use the open source Wordpress as a content management system
If something is widely adopted, there may be an assumption that it’s secure. But assumptions are very often proven false.
There’s a more logical notion – that the additional scrutiny on open source software compared to proprietary software delivers increased security. In other words, more expert eyes look at a project, which leads to more security.
This is the logic behind the idea that open source is more secure than closed source or proprietary software. But the more watchers on a project doesn’t automatically make an open source project secure.
Most developers aren’t satisfied with just looking at how widely used a project is to check it’s security standing. In fact, we know that security represents a significant and ongoing concern for developers working with open source software.
Security was a clear concern moving forward in the future for developers working on rich text editors. The results from our 2021 State of Rich Text Editor Survey revealed that 173 developers out of the total 475 surveyed ranked security as extremely important to ongoing development in their future projects (36% of the total surveyed).
Since TinyMCE has always been an open source WYSIWYG editor, confronting questions around security represents an important topic to explore. Specifically, let’s explore one key question: how can you know if an open source software dependency you’d like to use is secure (or not)?
Open source software security risk assessment
A Google search on the state of open source security turns up a number of reports, as well as tools for checking open source software for vulnerabilities.
A key one amongst the results, however, is the annual State of Software Supply Chain report from Sonatype. This report provides a thorough exploration of how common security issues are among open source software projects, as well as some useful insights into open source software security. It’s been conducted annually for the last seven years, and provides some valuable guidance when making a security assessment of open source software.
Popularity does not mean security
Popularity as a metric is defined by Sonatype as the number of software projects recorded as actively using a specific open source software dependency.
A key result found in the most recent State of Software Supply Chain report, was that popularity does not mean the open source software is secure.
Speed to update is more significant than popularity
Sonatype has a metric called Mean Time Take to Update (MTTU). They’ve found that open source software that has lower MTTU is more likely to display better security.
Criticality scores impact open source software security
The criticality measurements provided by the Open Source Security Foundation (OSSF) provide a rating called criticality, which is an aggregate score constructed from several metrics. The OSSF reports that a criticality score reflects the importance and influence of an open source project, and provides an insight on security standing. It aggregates the following:
- Project Age
- Recent Releases
- Months Since Last Update
- Dependents Recorded Monthly
Here are the TinyMCE criticality results as an example.
The conclusion that Sonatype drew in their analysis was that open source software with low MTTU and high criticality results are more likely to be secure. These two metrics are therefore the essential sign posts to look for when assessing open source software security.
Open source software security relies on private business adoption
It’s true that more and more private businesses are acquiring open source projects (for instance the Red Hat acquisition, and the GitHub acquisition). Once acquired, the private business may adopt an open source first model, providing freemium tiers alongside enterprise tiers.
In the best case scenario, this means the open source project gains more developer resources without detracting from the community growing around the project. In this scenario, where a large business acquires the open source project, a sign of security is more developer resources directed toward updates and maintenance, not just to new features. The Harvard Business Review explains this sign of security:
“[...]as companies continue their involvement in contributing to FOSS, we suggest they keep the stability of the software they use in mind, that they incentivize their employee contributions to focus on both features useful to the company as well as general security and maintenance[..]”
– Hila Lifshitz-Assaf and Frank Naglem September 02, 2021
Open Source Security: best practices for initial audit
When you’re completing due diligence on an open source project, popularity, and adoption masquerades as an acceptable sign post. Especially when working from the logical position that more eyes, more scrutiny, has to inevitably be a good thing and a source of security. However, it is other metrics that stand out as better guides.
- Consider the Mean Time To Update score. Make use of the OSSF dashboard to check other signs like criticality.
- Look into how private owners are supporting maintenance and updates. This is another essential security sign. A secure project, privately owned, is one supported by a clear policy toward maintaining the open source project.
Check in on TinyMCE’s security
If you’d like to talk about security, you can ask directly at the TinyMCE discussion page on GitHub.
If our open source rich text editor has caught your attention, you can check out our premium plugins as well. If you are a new user to our Cloud, you are able to access a 14-day free trial of all of our premium features for FREE simply register your account.