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 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?
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
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/
Organization and Tracking
We have split our dependencies into two groups:
- devDependencies
- dependencies
Example: https://github.com/Q-Vault/qvault/blob/master/package.json
Because Qvault 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 and electron-notarize are used to package and notarize our application for Mac OS, but 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 who maintains 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
Github: https://github.com/q-vault/qvault
Homepage: https://qvault.io
The post Security in Dependencies appeared first on Qvault.
Top comments (0)