While It is straightforward to see the advantages of this approach we need to realise that coupled with them comes a series of risks that need to be handled as well. To use a better known pattern that comes from the cloud computing world there’s a shared responsibility model regarding vulnerabilities and potential attacks as we can see in its different flavours: IaaS, PaaS or SaaS.
With our investigation we want to dive into the mentioned bigger scale dependency issue.
- Find the libraries most depended upon in NPM
- Define the characteristics that would indicate a low maintenance of the codebase
- Analyze the results, obtain insights and provide recommendations that improve the current situation
- Repository that had 5 or less commits in the last year
- Community size of 30 or less contributors
- Participation percentage was low during last year: we compute this participation percentage as the commits performed by contributors other than the owner of the repo over the overall commits
Out of those 250, there are 129 libraries that showed no commit activity (12.9% of our analysis scope) at all in the last year, accumulating more than 330M weekly downloads.
This link has the results of the analysis with more information so that you can verify the results of our investigation for yourselves.
The use of third-party dependencies in software development has many advantages but attached to them come along some risks that need to be identified and managed by software developers, specially at a corporate level, to avoid being surprised by collateral vulnerabilities inside their projects, inherited from their dependency trees.
Even though open source software is a major trend nowadays, its maintenance is a tedious task, since the returns of it are not straightforward or measurable in the short-term. If we combine that with the fact that these projects are open, in theory, to anyone willing to contribute, we can find ourselves with a landscape where the responsibility becomes blurred, making the open source community more prone to attacks like the one described in earlier sections.
Even though our analisis has only covered NPM libraries, we think that the same conclusions might be found inside other programming languages and package managers where we make use of third-party modules.
Next we will go through some essential recommendations to mitigate the risks of using third-party software from the classic paradigm of cybersecurity: prevention, detection and response.
Before we include a new dependency in our code we need to think whether that dependency is really needed, and if we conclude that it is, we need to verify if the library that we will be using has a strong community and activity behind.
We are going to focus in two examples showcased by the BBVA labs in the XII STIC conference of the CCN-CERT in Madrid this december:
- Patton: a project that uses fuzzy matching to find public vulnerabilities in our codebase or dependency tree.
- Deeptracy: a project that automates dependency extraction for multiple programming languages.
Even though anyone who has worked on software development knows about the complexity of the task, is is important to note that an open source community implies a bidirectional flow and that if our software, critical or not, relies on other pieces of open source software we must try to contribute to the community behind it and keep it live and active.