Modern application are often written with help of (too) many third party libraries. Take a look inside of a random node_modules folder for example. These packages contain security vulnerabilities which could lead to serious data breaches, account takeover, money theft and more. Sometimes malicious code is put in third party library by a malicious actor (supply chain attack). Other times they are just mistakes made by developers. As long as you use third party libraries you're always at risk of using one (or more) vulnerable ones. This post is about things you can do to minimize the risk of becoming victim to these kind of vulnerabilities.
Don't use dependencies you don't really need
If it doesn't take much time to write it yourself, do so. Especially if you only need a small part of a big library. You never know if someone has added malicious code to it or if it is using a vulnerable dependency unless you validate all that code. This makes dependency management much easier.
Use dependencies for big and hard things
Don't write your own code to handle hard things like handling authentication tokens. You will probably make mistakes which leave your application vulnerable. Pick a library for these things and take next paragraph into account.
Every time you start using a dependency, take a look at who created it
- If the package is open source and is being maintained by a very small group off people, there is a bigger chance that one of them adds malicious code without anyone noticing.
- Pick packages which are maintained by bigger companies like Microsoft, Oracle or Google. They hire good and professional people who know what they are doing. Don't install packages from RandomDude from RandomCountry and if you do, do some background research on that person so you know if it's a skilled and reliable developer.
- Check if there is no known vulnerability in the version of the package you want to install. You should be able to find this in your package manager like in this example.
- Check if the dependency is actively maintained. If it is marked as deprecated it is not supported anymore and you should not use it. You can also look at the commits on Github or the last time a new version was released.
Scan your projects for vulnerabilities regularly
More development platforms add features to check if the dependencies of your application contain a vulnerable packages. In modern ASP.NET you can use dotnet list package --vulnerable and in NPM you can use npm audit. It's even better to automatically scan your dependencies regularly. You can use tools like snyk or mend.io (formerly Whitesource) to help you with that. Those tools are expensive but have some advanced features.
Validate your package sources
Make sure all you dependencies are downloaded from reliable and legitimate sources like NuGet.org from Microsoft or your own (well secured) private feeds. If you are using multiple feeds a package could be available on both sources so one of them might contain a malicious or version so you could accidentally install the wrong one.
Use lock files
Lock files contain the hash of a package's content so if it changes, you will be able to see it.
Scan Docker images
If you are using Docker images you should use Docker scout to scan for vulnerable images regularly.
What to do if you find a vulnerable package in your project
- If there is a fix for the vulnerability you should update the package and release it as soon as possible.
- If not you should assess if the vulnerability is making your application vulnerable and if so try to find a workaround to fix it. Sometimes workarounds are provided by package authors.
- If the vulnerability has a low severity rating you might chose to do nothing or wait for a fix.
Do you know other best practices for managing software dependencies? I'd love to read them in the comments!
Top comments (0)