Drupal’s use in the Public Sector has really exploded. The US Federal Government is using it, with different levels of success, as are many US States, but the recent uptick in supply chain based infrastructure attacks may be a reason to revisit Drupal’s suitability for use with mission-critical web based applications, or at the very least, how we should think about building them.

Drupal relies heavily on the external, public software library ecosystems Composer and NPM, as do most frameworks these days. Therein lies the potential trouble.

Any external library can be utilized in a Drupal installation, and many Drupal developers do it regularly to save time, not always caring about where the library comes from. (I usually try to extinguish that practice like a coach stomps out a lit cigarette at a Middle School track meet.)

NPM and Composer are used in a similar fashion by developers. When we want to add a new chunk of pre-built code into the application, we run a command that simply goes out and fetches the supporting libraries for us and installs them into the application. Developers are the front line of defense when it comes to these libraries of executable code we download, and most of us (myself included) rarely think about the integrity of the repos we are connecting to.

Code repos are so numerous on the web that vetting the software becomes essentially an exercise in verifying a credible source. The issue is, no grading system exists for the code in these libraries. It’s all gratus.

This persistent process glitch in our existing paradigm can be thought of in another context for more clarity.

Everyday typical web usage requires all of us to be wary of downloading crap that we don’t know the purpose of to our computers and smartphones, unless we trust the source, but Drupal devs do that every time we update our code and upload it to a secure enterprise server.

I hope that last sentence brought everyone’s egos down a notch.

Trusting the sender of a text message and trusting code we put on the production server is the same trust but a different context. The trust in context for the Public Sector is the Public Trust, and to my thinking should be scoped differently.

Modern Drupal development uses a build and deploy strategy that relies on vast supporting external open source software libraries, including the Docker-verse.

Accordingly, Drupal developers working in the Public Sector should be aware and take the following precautions to ensure their Drupal applications are secure.

Avoid hot-linking to that cool jQuery cdn to make tabs or buttons or whatever work right. Download the library, onboard it to your Drupal site, version it and put it behind the application firewall. I know this sounds old-fashioned but it’s appropriate for a web application where security is the main objective and a hard requirement, like a personnel management portal or a monitoring system storing public infrastructure test data.

Not all software repositories contain code that is performant. It’s best to stick to the industry leaders with a high degree of transparency, visibility and credibility. In the rush to deliver on limited timelines, vetting is usually omitted in favor of productivity. When you need jQuery libraries, get them from jQuery. When you need Drupal code, get it from Drupal, etc.

Own the code in the vendor directory. In Drupal, the vendor directory contains the software libraries and executables that are managed by Composer. Go into the vendor directory of your web application and make sure all the stuff in there makes sense. Look at the code and know what it does. For big sites this is an enormous undertaking, which is why the supply chain is such a good target to begin with.

Most of the attacks against web sites that I have helped mitigate in the Public Sector were well coordinated and had significant resource footprints. That usually costs a lot of money. If threat actors can buy blocks of IP addresses and banks of VMs, they could conceivably set up a few software repos as well.

NPM also should be deeply reviewed by every Public Sector security team to establish best use practices and establish trust. Recently, the NPM software package ecosystem experienced a huge breach of security, potentially affecting a great many web applications. It’s chilling in it’s execution as its target is developers, or rather developer resources. It exploits the weakness in these publicly aces sable repos in the same way as bad apps in the app store.

Drupal should come up with a trusted software source list so that Drupal Devs can understand the danger of just putting any library into a Drupal website. Alternatively, they could either vett and certify the existing third party repos or port abandoned or unstable products into the Drupal ecosystem to manage secure releases. It would certianly add to Drupal’s already good credibility and image.

Currently this security hole is greyed out in the Public Sector. Devs don’t vett the software they are uploading to the servers because they implicitly trust it. Using open source software is mandated by Public Sector policies, so although many Public Sector security personel and devs alike are aware of these vulnerabilities, there are no current policies to address the issues, as existing policies are so draconian that if each agency adhered to them, we would not be able to use Drupal at all.

The Drupal Community needs some traction on this looming security issue which I predict will be becoming more prominent. It’s up to us to stop application based security issues before they start in Drupal.

Developers should also work hard to develop and train other stakeholders. It’s imperative to develop awareness and concensus on crafting application security policies in the Public Sector instead of sliding dev-ops under the onus of network security.

Teach all Drupal Devs risk management, if we want Drupal to succeed in the Public Sector.

Thank you!