What are the benefits and challenges of open-source? In this blog post, we answer these questions and introduce two new open-source tools (Drupal Dependency Quality Gate Composer Audit plugin and Composer Audit-changes) we use to keep third-party PHP dependencies under control on our projects.
Quality is a key indicator when we deliver developer portals with the help of Drupal and other open-source packages. When we became an ISO-certified company, that was just an acknowledgment of our work in the past years. Building, maintaining, and supporting software for years and keeping the quality above a certain threshold comes with a cost. A critical part of that task is keeping third-party dependencies under control and being more selective with those.
Before diving deep into the technical details, let’s discuss the benefits and challenges of relying on open-source code.
The two faces of open-source
Open source software plays an essential role in software development and digital transformation, especially in the past years’ economic situations. Companies increasingly rely on open-source components because they result in cost and time savings while improving their efficiency. They also consider open-source dependencies as a way out of proprietary software vendor lock-in, which can be both expensive and hindering in the long run.
As the 2020 edition of “The managed open-source survey” by Tidelift highlights, many developers also prefer utilizing an existing open-source package to solve a task instead of writing a new code. The reason behind choosing someone else’s code over their own is that they believe that a package that is used and maintained by a larger community guarantees quality, continued maintenance, and security. However, this is not necessarily a valid assumption because it heavily depends on the health of the community that nurtures a package.
Though is there a community behind all open-source packages? As the survey also reveals, usually no, and almost half of the open-source maintainers are solo players. This means that an external dependency can immediately become a bottleneck in the supply chain if a maintainer becomes unavailable for any reason. But is there a supply chain if we talk about open-source dependencies?
Before that question can be answered, let’s look at the primary motivators of developers who publish an open-source package on the Internet. Based on the recent "State of the open-source maintainer report" by Tidelift, they mainly would like to work on projects that matter to them, and they would like to fulfill their needs for challenging and creative work. However, after they publish their package and it becomes popular, the maintenance and support of the package can become lonely and stressful as they are sometimes asked to work for free for some big enterprise companies with urgency involved.
As Thomas Depierre pointed out in his "I am not a supplier" blog post a supplier agreement would require a business relationship between the provider and the consumer, which is not a given just because someone installed a package with an open-source license.
This unhealthy situation around the unrealistic expectations regarding support and maintenance of free and open-source packages worsens as hackers and malicious actors increasingly target big enterprise companies via supply chain attacks, leveraging popular open-source components in any level of the dependency tree.
“There is a module for that…”
The previously discussed challenges are also affecting the Drupal community. Even if there are more than 50.000 available packages for Drupal, not all of them are actively maintained, supported, or opted-in for coverage by the Drupal Security team.
In addition, even if a major or minor version of the package has fulfilled all these requirements at some point in time, maintainers can decide at any time to mark a branch unsupported and only support the latest version of the package. This usually happens when a new major version of Drupal core is released, and maintainers decide that it is easier to support only the latest major version of Drupal core in a new major version of their package due to API changes.
Measuring the health of a community around Drupal packages could be challenging, but we can still rely on some key indicators publicly available to anyone. These can be the current maintenance- and development status of a package or whether maintainers opted in for coverage by the Drupal Security team for a given release or not. Some of these checks can also be automated and integrated into the continuous integration (CI) pipelines.
Composer audit on Drupal steroids
Does a solution exist for the aforementioned issues? Or more specifically, can we monitor and assess the health and sustainability of an open source project continuously and reliably? Keeping an eye on security releases or abandoned packages is a tedious job without automation. Maintainers of Composer knew that, and since version 2.4.0, a new “audit” command has been added for monitoring security releases for PHP packages.
Unfortunately, Drupal developers could not unlock the full potential of that command until now because security advisories for contrib packages were not available in the advisory database that the composer audit command uses. This is the first thing that the Drupal Dependency Quality Gate Composer Audit tries to address, but it can do even more than that. The current release of that Composer plugin can also flag complete packages or just releases that have become unsupported by maintainers; or not covered by the Drupal Security team. All these checks rely on databases that get updated daily via Github Actions, and they contain a list of insecure and unsupported packages.
Even if there is some collected technical debt around dependencies on a project, feel free to try out this package because it has a (limited) opt-out feature or it can be combined with the composer audit-changes plugin to only check newly added or updated packages.
These two new tools allow us to look far deeper into our open source dependencies and keep tabs on issues without much extra effort, thereby ensuring continued high quality and security of our delivered developer portals. We hope they will be useful to others too. For questions regarding either tool, please refer to their issue queues (1) (2).
If you have further questions, or need experienced help with your developer portal, we invite you to get in touch with us.
