All About Dependencies

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.

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.