Third party dependencies are an essential part of every modern software project. It is nearly impossible to build a non-trivial application without depending on third party libraries.
However, by introducing external software dependencies you are also introducing an area of risk to a project. The OWASP top 10 lists “Using Components with Known Vulnerabilities” as the number 9 most critical risk to web applications in the last (2017) list. The linked page provides a lot more detail on the risk and general mitigations, and if you have not came across this list before it really should be required reading for all developers.
There are four key points that need to be considered for the use of libraries by a project:
- only including libraries which are actually required
- ensuring the libraries have a licence which allows their use/distribution in your product
- ensuring libraries are kept up to date
- being aware of Common Vulnerabilities and Exposures (CVEs)
For a small number of dependencies it may be possible to manually keep on top of this, but ideally it should be automated. There are many commercial tools (such as Snyk and Sonatype Lifecycle) which can be used as part of the software delivery supply chain for performing scans and audits on the libraries that a project is using. In this series I will explore some of the options which can be put together using open source solutions.