4 ms·

I worry about the exact same risks with things like brew and chocolatey, and even docker. The challenge with a lot of these systems is that there _are_ "offici

by tailspin2019 5y ago

I worry about the exact same risks with things like brew and chocolatey, and even docker. The challenge with a lot of these systems is that there _are_ "official" packages that have some higher level of checks and quality control, and these best case examples are generally talked about on the relevant marketing pages for these tools. But these vetted packages are generally accessible in the same way as unofficial "wild west" packages that would be high risk to use. The line is very blurry and you can easily be sucked into a false sense of security. I'm amazed at how many times I see these systems being used as a matter of course without any consideration at all given to the risks of importing packages of unknown quality from unknown third-parties. And it's very difficult to avoid using these systems too. I use brew, docker, npm, Nuget etc. - it's hard to be productive and to not do so as a developer in 2021. I have a standard process I go through for taking on new development dependancies, of vetting the author of Nuget/NPM packages as best I can. I rarely add a dependancy without having gone through my little (likely very insufficient) "due dilligence" process first, but this doesn't cover downstream/implicit dependancies... I'll also try not to bring in dependancies for simple things. I prefer reinventing the wheel where necessary and writing my own simple string formatter or parser utility as opposed to taking the easy way out and adding another dependancy for the matter of a few lines of code. But I don't know how to solve the wider issue. The first step, I guess, is to make sure that everyone really knows what the risks are, so that at least we're all using these package mangers with our eyes fully open.

thereddaikon 5y ago
Its one thing if these practices are followed when building something with little to no consequence but I've been saying for years, code that handles safety critical tasks or handles sensitive information where there is a lot of liability needs to be treated like civil engineering. There should be licensure, rigorous industry best practices and validation. We don't have that right now and I think systemically its why you see Boeings flying themselves into the ground and Financial firms losing everyone's data day in and out. Some things should be held to a higher standard and with those, tools like NPM that only serve to make the job faster but not make the end product better shouldn't be allowed.
jamesfinlayson 5y ago
I remember viewing the source on my bank's online banking site a few years ago - self-hosted jQuery was their only dependency. I guess the risk for them is high enough to not branch out into npm.

thereddaikon 5y ago

Its one thing if these practices are followed when building something with little to no consequence but I've been saying for years, code that handles safety critical tasks or handles sensitive information where there is a lot of liability needs to be treated like civil engineering. There should be licensure, rigorous industry best practices and validation. We don't have that right now and I think systemically its why you see Boeings flying themselves into the ground and Financial firms losing everyone's data day in and out. Some things should be held to a higher standard and with those, tools like NPM that only serve to make the job faster but not make the end product better shouldn't be allowed.

jamesfinlayson 5y ago

I remember viewing the source on my bank's online banking site a few years ago - self-hosted jQuery was their only dependency. I guess the risk for them is high enough to not branch out into npm.