How Hapi’s Dependency Model Simplifies Deployments in Security Sensitive Environments

Introduction

At Big Room Studios, when we build backend services, we tend to use Hapi ( https://hapi.dev/ ) rather than Express ( https://expressjs.com/ ). While both are powerful web application frameworks, they take different approaches to security, code dependency, and features. This article provides a summary of how hapi’s dependency approach helps us release software faster in security focused enterprise environments.

Overview

Express takes a typical javascript open source approach of taking many external dependencies to architect their solutions. It provides the skeleton of a web application framework (advertised as minimalist and unopinionated) that is intended to be extended with a mix of 3rd party extensions to customize the architecture of your final solution. At time of writing, express takes 31 dependencies, each of which have their own dependencies (one package has 12) nevermind the dependencies of dependencies, etc.

Hapi takes a different approach. It intentionally takes no external source dependencies to reduce its security surface, and attempts to be opinionated to create a more “complete” solution to reduce the need for additional dependencies. Its plugin system still provides the flexibility that web application developers need.

The Challenge

With enterprise clients, security at scale is a larger focus than smaller MVP development for startups. Security is important for all clients, but larger organizations usually have existing systems in place that we have to adhere to vs bootstrapping best practice as smaller companies.

As a result, when we work with larger companies, we are under additional and appropriate scrutiny to prove the security of our systems in addition to the traditional management of security that we do with all clients.

One mechanism that we use is to provide Trivy ( https://trivy.dev/ ) scans to our clients to show that our delivered software does not contain known vulnerabilities. Trivy looks at the versions of various libraries you are using and compares it to known vulnerabilities. It then reports on the severity of those vulnerabilities. We won’t ship software with large vulnerabilities from Trivy.

How Hapi Helps

Express (currently) has 16 dependencies, if (on average) those dependencies take 4 dependencies each, then we are managing 64 different software packages for security scans for express alone. That ignores dependency of dependencies, deeper hierarchies, and the third party plugins required to make express a complete solution. Each of those dependencies can take new dependencies at any time. What we are left with is a large Trivy scanning surface that changes frequently. If we are lucky, we would be able to upgrade where there are vulnerabilities but it’s not uncommon for there to be unresolved high impact security events. This could block us completely.

Hapi reduces this security surface. By taking no external dependencies, we reduce our Trivy scan to hapi’s codebase only for our web framework. Plugins can still introduce dependencies, but since Hapi is more complete “out of the box”, it reduces that as well.

Results

The result is we have more confidence in our security scans and are less often blocked by unfixed high severity vulnerabilities. Enterprise clients are confident in the security of our software and we are less beholden to the whims of deep dependency trees.

Previous
Previous

How BRS uses Figma, the industry standard for user experience design

Next
Next

Agile at BRS