Search posts, tags, users, and pages
I don't see any link between this sort of thing and open-source - the same thing happens with non-open-source browser plugins, apps in the app store, etc.
One thing that happens is that seemingly harmless plugins/extensions/apps are bought/given to people with bad motives, sometimes they buy them from the original owner for money, and then once the new owners have the ability to push out an update to all existing users with bad code, they do it.
Open-source doesn't need to change anything because the problem is unrelated. What we need to be aware of is how insecure grabbing packages/plugins/apps from a central repositories and accepting any & all updates that come through without any kind of review process can be a security risk.
Fair enough, maybe the problem is bigger than I thought then... you're right this can happen anywhere and in any project. But in the dev industry, our practice revolves quite a lot around blindly using pre-existing packages in order to avoid re-inventing the wheel.... this might not be the only affected industry, but we need to find a way to educate people into thinking about the security involved, don't we?
Sure, here's a great policy you can apply to your life, whether it's open-source, public domain, or proprietary code -> Don't run code you haven't written or reviewed, or that hasn't been reviewed by somebody you trust. As easy as that, you can eliminate most of the risk involved here!
When you're installing apps from an app store, or browser extensions - you don't always have the chance to review the code yourself, that's a situation where you're outsourcing your security to how much you trust another party (like Apple, Google, Amazon, Mozilla, Microsoft, etc) to review the code, either manually or with automated tools…BUT when you're pulling in npm packages as dependencies in your codebase you definitely do have the access you need. There's no excuse for outsourcing your security to nameless strangers, and the results vary wildly.
Another policy you can take to reduce this risk greatly as a developer -> only include in your codebase code that you have either written yourself, or reviewed and imported. Don't allow developers other than yourself to push code into your codebase (through external dependencies). If you want some other code somebody else wrote, review it and take it, but it's yours now and you have to be responsible for it. If you treat your npm packages like that (the code is available, but I am the maintainer if I choose to use it in my own codebase) you can also reduce the risk of malicious people like this.
It all comes down to not outsourcing your agency, and your security to nameless strangers who don't care about at best, and actively want to exploit you at worst.
Right, but how performant can that process be? You're talking about reviewing all the external libraries, either that or writing them yourself. There are modules that are easily reviewed, but others could have thousands of lines of code, and could depend on other modules, how can you make time to review all of that? With all due respect, although in paper it might sound good, in practice it wouldn't work.
Instead of code, let's frame it as land (property) and instead of programmers, let's frame them as guards.
If I am concerned with the safety of my land, I need to actively guard all of it. That makes sense.
If I want to expand my kingdom and add new land to it, does my security depend on the price of the land, or the fact that the land might be given to me at no cost? No, if I want my land to be safe I still need to actively guard all of it.
But suppose I want a large kingdom, with lots of land, and there is lots of free land available for the taking. Can't I just take land guarded by other people and not have to worry about it? They're guarding it, and I should be able to trust any random stranger to guard my free land so I don't have to, right? No. No matter how large your kingdom, either you or somebody you trust has to guard all of your land.
Does that mean that pulling in thousands of dependencies you can't possibly review might mean over-extending your ability to keep your codebase secure? Yes, that's exactly what that means.
Even code you obtained for $0 has a constant cost once it's added to your codebase, and part of that cost is reviewing it and keeping it secure. It's great that you didn't have to write it the first time, but when you pick it and use it, you have to view it as taking it and making it your own now, which means treating it like anything else you have that you want to keep secure.
Unsolicited, but chiming in anyway... I get the analogy, but don't understand it as a response, and so I'll just echo back the point made by Fernando Doglio. Do you comb through every line of every dependency you ever use in your projects, the dependencies' dependencies, and so on? What happens when you need to use x, and x requires y and z? You make the time to stay current with all of all changes made to any project you use, ones they use, etc?
Perhaps I am bad at time management, but the detriment to productivity would be more than just an impediment; it would bring the whole development process to a halt, and not just once... so you are right about the cost, but sounds like a cost of time that you willfully create for yourself. In truth, I care quite a bit about security, but at a certain point I have to put my trust in the open-source community, then straight-up law enforcement if something illegal happens like theft of money or personal data. Weak, but you get it.
And I am not sure I understand your attitude toward the use of third-party OSS... Sometimes I need to use libraries that are totally foundational to my purposes, but also really huge/complex. Sometimes I need code that I'm not able to write myself.
Even if it boils down to not fully understanding some libraries and not just a time issue, would you discourage someone with a very cool and useful project who is simply not able to... guard their own land... from moving forward with their development? I certainly would not. It may be a misinterpretation of your reply, or your tone, on my end, so I apologize if that's not your position.
Do you comb through every line of every dependency you ever use in your projects? the dependencies' dependencies, and so on?
Usually yes, since I'm very picky about what code I bring into my codebase - since I'll be the one fixing it and working with it if there's a bug or an urgent security problem.
I'm also really hesitant to pull in dependencies and code I don't know, so I don't often have dependencies with dependencies with dependencies etc.
What happens when you need to use x, and x requires y and z?
I think really long and hard if I need X at all. I look at Y and Z and think really really long and hard if it's worth pulling in X, Y, and Z just so I can have X.
You make the time to stay current with all of all changes made to any project you use?
If it's in a codebase I'm expected to support it's part of the job.
Perhaps I am bad at time management, but the detriment to productivity would be more than just an impediment; it would bring the whole development process to a halt
Isn't it weird how taking and using pre-made code doesn't sound like it's always such a timesaver after all? All code is liability, whether you've written it yourself or not. Is it really too much to ask to ask a developer to move their eyes across the code they're using, even if they didn't have to sit and write it themselves? I feel like being familiar with the code is a baseline minimum.
I release a lot of open source libraries, I've got 40+ packages on npm, 100+ repositories on Github. But I publish and share a lot more of my code than I pull in or use of others. If you're going to use one of my plugins and pull it in, the way I see it is: Great, here's some code you can read to learn how to implement this in your own codebase, and hey, it's not just code that shows you how you can DIY it, but it also is executable, you can run my code and it will do the thing it shows you how to do. It's fine if you want to pull my code into your codebase instead of reading it and learning from it, but don't mistake yourself thinking that if you use my plugin, somehow I'm on the hook to keep YOUR codebase secure. I don't work for you. If you want to pull it into your codebase be my guest, but it's open-source. It's YOUR code now. Enjoy it, it came at 0 cost to you, but now that you own it and it's in your codebase, that's your code to maintain. Of course I'll update it, and if there's a bug I'll try to fix it, but nobody is entitled to that, and unless you're paying me, you don't get to tell me what work I do and when (if you have an important bugfix or something).
Usually yes, since I'm very picky about what code I bring into my codebase - since I'll be the one fixing it and working with it if there's a bug or an urgent security problem.
Oh... huh. For sure expected a "no" right there, so that sort of puts a dent in my argument. Maybe it just depends on the sorts of projects being worked.
I will concede that it definitely would be feasible (time-wise) for me to get more familiar with a lot of the projects I rely upon in my personal stuff, then maybe even active in the development of a select few, as that has always been the case when bringing third-party code to my employer's code base. Those reviews are extremely thorough for obvious reasons, but I think one reason I am able is the duration of our development cycle (very slow at my job).
But to my mind, at least historically, not all projects I have done seemed to be of appropriate scope to take much interest in the inner workings of a small helper library, or foreign code used within that dependency, because I see them as just that: helpers, or plugins to accomplish things I don't really care to focus on or do "better" than someone else... most stuff I use is stuff that I don't assume I could do better myself if I wanted, so rather focus on the task of interest to me. On the other hand, at any given time in my professional work, they only want me to think about one specific enhancement at a time, so makes it a little easier since the scope changes. Also, would not look awesome if I were the one credited for infecting our code base. Furthermore... they pay me.
Don't know exactly what your last paragraph there was in response to, but yeah... before I archived it, I was always surprised when a person would contact me with requests that turned to demands to add certain new features to some Chrome plugin I used to have. The mindset of entitlement there was bizarre.