Security in Dependencies
Tags: programming, security, tutorial, dependencies
Published: 2019-08-27 17:58:07

---
title: Security in Dependencies
published: true
tags: Programming,Security,Tutorial,dependencies
canonical_url: https://qvault.io/2019/08/21/security-in-dependencies/
---

Choosing the right dependencies is a difficult task. Assuming the developer of an application is the best programmer in the world, the “best” thing to do would be to write the entire codebase alone. This would eliminate the bugs, vulnerabilities, and malicious intrusions of inferior developers.

We at [Qvault](https://qvault.io/) recognize that we **aren’t** the best developers in the world, but we still take appropriate steps to try to reduce our dependencies on external code.

The trouble is that we like to move quickly in order to be able to compete in the market and offer new features. We try to avoid re-inventing the wheel when the wheel in question is widely used, is peer-reviewed, and we consider it stable and trusted.

In this article we want to explain the decision making behind which dependencies we use, and which we avoid.

## Can We Write it?

![](https://qvault.io/wp-content/uploads/2019/08/photo-1501504905252-473c47e087f8-1024x768.jpeg)

This should be the first question asked when a new dependency is being considered. If it fits within the scope of a project it is almost always safest to write and own the code ourselves. Pertinent questions include:

- How long will it take us to write it?
- Do we need the whole package? Can we re-write the section we need?
- Is this something we have domain expertise in?
- Will our implementation be better? (don’t write your own cryptography)
- Does the language’s standard library already have this functionality?

## Review

![](https://qvault.io/wp-content/uploads/2019/08/photo-1516714819001-8ee7a13b71d7-1024x683.jpeg)

If we decide that we shouldn’t write the code ourselves, we find a valid candidate package. We take a look at the code and ensure:

- Does the code have tests? Are they relevant?
- Is the library architected well? Is the code of high quality?
- How many contributors are there?
- How many other projects are dependent on this package?
- Is the project actively maintained? When was the last release?
- Does this project have dependencies? If so, we need to review those as well (best to **try to avoid child dependencies** where possible).

## Locking Versions

For any dependencies that are more security critical, it is important to lock versions. For example, we perhaps have done a solid review of package ‘ **abc** ‘ and determined that **v1.4.4** is stable and secure. We want to ensure that we don’t carelessly update that package without reviewing the changes. A package manager like yarn keeps the digital fingerprints of each dependency so that once v1.4.4 code is brought in, it can’t be maliciously swapped out.

Vulnerabilities in updates aren’t protected by this feature. For this reason we try to use **‘1.4.4’** vs **‘~1.4.4’** or **‘^1.4.4’**. By not including the tilde or the caret, we tell yarn that we don’t want to automatically update this package.

When locking versions in this way we need to be more diligent about regularly reviewing and manually applying updates because many times new updates fix old security holes.

Reference: [https://stackabuse.com/caret-vs-tilde-in-package-json/](https://stackabuse.com/caret-vs-tilde-in-package-json/)

## Organization and Tracking

We have split our dependencies into two groups:

- devDependencies
- dependencies

Example: [https://github.com/Q-Vault/qvault/blob/master/package.json](https://github.com/Q-Vault/qvault/blob/master/package.json)

Because [Qvault](https://qvault.io/) is an Electron app, technically there is no difference between _devDependencies_ and normal _dependencies_. We still organize them in this way to keep track of which dependencies are used to _build_ our app and which are used _by_ our app.

For example, [electron-builder](https://github.com/electron-userland/electron-builder) and [electron-notarize](https://github.com/electron/electron-notarize) are used to package and notarize our application for Mac OS, but [simple-keyboard](https://github.com/hodgef/simple-keyboard) runs within our app and so we consider it a higher potential threat and keep an extra-close eye on it.

## Communication

When we decide that we want to use a dependency, especially if it is a less well known dependency, we often reach out to the developer to ask questions and ensure that it is well maintained. For example I have contacted [hodgef](https://github.com/hodgef) who maintains [simple-keyboard](https://github.com/hodgef/simple-keyboard) multiple times and he has been a fantastic resource.

We hope this quick guide gives some insight into our process for dependency management, and gives you some good tips for building your own projects. Stay safe and have fun building!

By Lane Wagner

Further Reading: [https://research.swtch.com/deps](https://research.swtch.com/deps)

Github: [https://github.com/q-vault/qvault](https://github.com/q-vault/qvault)

Homepage: [https://qvault.io](https://qvault.io)

The post [Security in Dependencies](https://qvault.io/2019/08/21/security-in-dependencies/) appeared first on [Qvault](https://qvault.io).