The benefit of software dependencies is that they allow developers to deliver software faster building on previous code. Dependencies are integral part of the software development cycle and they will be used at different stages i.e. development, execution or testing. Yet dependencies not only may introduce risks that are often overlooked, but their fast resolution and compliance with license types must be taken into consideration. In this extremely fast session we will see some of the advantages of using a mature, robust artifact manager for npm, bower and other package managers.
All About Dependencies

AI Generated Video Summary
Today's presentation discusses the role of dependencies in software development, including different types of dependencies and their impact on development and maintenance. The talk also highlights incidents related to software dependencies, such as naming disputes and compromised credentials, which have led to system failures and security breaches. Efforts are being made to address these issues with tools like X-Ray and scorecards that provide analysis and insights for improvement.
1. Introduction to Software Dependencies
Today's presentation is about dependencies in software development. Dependencies are an integral part of the development cycle, used at different stages. There are different types of dependencies, such as framework libraries, package modules, and resources. Understanding the degree of need for each dependency helps define update canons, migration cost, and cleanup efforts. However, adding a dependency outsources the development and maintenance work to others, exposing our programs to potential failures and flaws.
Thank you very much for being here. My name is Xuxa Ruiz. I'm from Mexico living in Switzerland. I'm a Java Champion. I work for a company, Jfrog.
Today's presentation it's about a key part of our software development process, dependencies. We don't need to reinvent the wheel every time we want to achieve some new level of functionality or deliver software faster. We want and we do reuse software written by others every day, software dependencies. And they are integral part of the software development cycle. They will be used at different stages, development, runtime or execution and testing. But they are not all the same.
So I'm going to present you with two statements and you will tell me if they are true or false. Dependencies are collections containing high-quality tested code that provides functionality that require significant expertise to develop. True. Dependency managers like NPM have made it possible that almost trivial functionality can be packaged and published. True. So these are both sides of the spectrum in terms of how the functionality is provided by dependencies.
So we know that there are different types of dependencies. For this super quick talk, I'm only going to mention them. Framework libraries, package modules, and resources. And we have a very clear example in Angular, which is a platform, and React, which is a library. So they are already telling you the level of integration between different functional components and how pin-united they are. And on the other side, this is a list of NPM micro-packages that are very useful.
So we have discussed that there are different types of dependencies, so with this we can also start thinking about our degree of need, or dependency level. So we can create a map of what of our dependencies are crucial, important, cosmetic, easily changed, or superfluous. And all this will help us to define the canons of update, the migration cost, or cleanup efforts. And these are really important during the development process and under normal circumstances, when the dependencies are okay. But things go wrong and they usually go wrong. So adding a dependency outsources the work of developing that code, designing, writing, testing, debugging, and maintaining to someone else, often their unknown programmer. And using that specific code exposed our programs to all failures and flaws that there will be in our dependency.
2. Software Dependency Incidents
In the world of software dependencies, there have been various incidents that highlight the potential risks. Examples include disputes over naming, compromised credentials, malicious releases, and packages containing encrypted payloads. These incidents have caused system failures, compromised security, and disrupted applications. However, efforts are being made to address these issues, with tools like X-Ray and scorecards providing analysis and insights for improvement.
For example, in NPM, in March 2016, there was a dispute between the naming. It was unpublished three hours later. NPM Registry published it again, and even changed its policies. In February 2018, there was a problem with NPM versions 5.7.0. And in Linux, when you run the sudo npm, it changed the ownership of the system file. So they broke the machine. In July 2018, the NPM credentials of a maintainer of Estlin-Scope were compromised. So there was a malicious release of Estlin-Scope in version 3.7.2. And that copied the NPM credentials of the machine that were running it and upload them. In November 2018, it was discovered that a malicious package had been added as a dependency to version 3.3.6 of EventStream. This was a flat mount string and contained encrypted payloads that stole bitcoins from certain applications. In April 2020, a small package called spromise made a lot of serverless applications go down. In January 2022, I think you all know that the maintainer of colors pushed changes printing garbage text in an infinite loop. And that was a problem. More recently, companies like mine, jfrog, is actually constantly updating and sending information about malicious npm packages that have appeared. So those are some of the most recent ones.
Comments